clojurewerkz / gizmo Goto Github PK

hi

i followed the instructions to create a new app from template

in D:\www\ lein new gizmo-web gizmo
cd gizmo
lein run --config config/development.clj

and i get an error Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <:>

another question i have is why doesn't lein run just work, why do i need to specify the config file?

I have a gizmo-web app, modified only to change the "/templates/layouts/application.html" to /not/ refer to "testapp" but rather to refer to my app's name.

My routes.clj is unchanged at:

(ns orla.routes
    (:use [clojurewerkz.route-one.compojure])
    (:require [compojure.core :as compojure]
              [compojure.route :as route]))

(compojure/defroutes main-routes
  (GET root "/" request (orla.handlers.home/index request))
  (GET favicon "/favicon.ico" _ (fn [_] {:render :nothing}))
  (route/not-found "Page not found"))

When I run the app ( lein run --config config/development.clj ) and hit a page such as http://localhost:8080/this-does-not-exist instead of "Page not found" I get "{}" as the content.

The headers are not informative:

Request URL:http://localhost:8080/this-does-not-exist
Request Method:GET
Status Code:404 Not Found
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:localhost:8080
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36

Response Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Content-Length:2
Content-Type:text/html;charset=UTF-8
Date:Fri, 11 Oct 2013 16:50:18 GMT
Host:localhost:8080
Server:Jetty(7.6.8.v20121106)
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36

The logging doesn't show much either:

lein run --config config/development.clj
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
2013-10-11 18:50:13.429:INFO:oejs.Server:jetty-7.6.8.v20121106
2013-10-11 18:50:13.467:INFO:oejs.AbstractConnector:Started [email protected]:8080
Handling uri:  /this-does-not-exist  Rendering:  nil
Handling uri:  /favicon.ico  Rendering:  :nothing

This very well might be the same issue that #1 seeks to fix, but I /think/ I tried that code too and I /guess/ I didn't use it properly as it seemed that the problem was there too. Apologies if this is the same issue written in a different way.

So @ifesdjeen suggested using either tools.logging or timbre to add proper logging to gizmo. logging.clj seems simple enough so that this shouldn't be to difficult.

I'm just not totally sure about the configuration. That would go into config/development.clj and similar in the apps, right? That would then mean changing gizmo-web-template if I understand the setup correctly.

And testing ... How would you do that? If at all.

I'd like to try Gizmo in a project, but use it with the upgraded set of dependencies as introduced in 7ba52d4. Could you please release a 1.0.0-alpha5?

Thanks!

When I run lein test I get not test failures, but at first I thought I did because of that output:

lein test clojurewerkz.gizmo.config-test

lein test clojurewerkz.gizmo.enlive-test

lein test clojurewerkz.gizmo.responder-test

lein test clojurewerkz.gizmo.service-test
Exception in thread "Thread-4" java.lang.Exception: couldn't start
    at clojurewerkz.gizmo.service_test$fn$reify__2540$fn__2541.invoke(service_test.clj:18)
    at clojurewerkz.gizmo.service$start_thread$fn__2475.invoke(service.clj:26)
    at clojure.lang.AFn.run(AFn.java:24)
    at java.lang.Thread.run(Thread.java:744)

lein test clojurewerkz.gizmo.widget-test

Ran 21 tests containing 35 assertions.
0 failures, 0 errors.

But the stack trace is printed onto stderr and it seems quite complicated to redirect it somewhere else as it doesn't seem to use *err*. At least wrapping the throw call where the exception originates from in a binding that replaces *err* with a string writer didn't change a thing.

Judging from this discussion it might well be that the exception is directly handed over to System/err so we would have to (temporarily) replace that. I'm not sure if that's really worth it.