Re: Baffling route/resource behavior: works on some routes but not others

[Fred Daoud]

Apologies for the short answer/wild guess, but perhaps try
(include-css "/css/test-app.css")

Notice the leading / so that the path is always from the
root instead of relative, which might explain why you were
having problems with routes that had a path deeper than 1.

Cheers,
Fred

On Wed, Apr 10, 2013, at 12:11 AM, Matt Anderson wrote:

I'm new here and have appreciated the archived answers as I learn by
working on a compojure application. I apologize if this is a newby
question, but after several hours of experimentation, I can't figure
out why resources are being served with reference to
resources/public on some routes, but not others, when the routes are
being wrapped at the same time.



These are dummy routes for now. I'm trying to make sure I have the
pieces wired up and working before going further.



I've defined two sets of routes, common-routes and group-routes to
understand how compojure routes are handled..



(defroutes common-routes

(GET "/" {:keys [uri request-method] :as req}

(test-page req))

(GET "/profile" {:keys [uri] :as req}

(profile req))

(GET "/profile/:id" {:keys [uri request-method id] :as req}

(profile-form id req)))



(defroutes group-admin-routes

(GET "/admin/groups" [req]

(groups-index req))

(GET "/admin/groups/create" [req]

(groups-create req))

(POST "/admin/groups/create" [m] (""))

(GET "/admin/groups/edit/:id" [id]

(layout [:h1 "Edit Group"])))





The handler functions all call the same layout function.



(defn base-layout [{:keys [title css js] :as attr-map :or {}} & body]

(html5

[:head

[:title "Test App")]

(include-css "css/test-app.css") –

[:body body]))



The routes are referenced in the route stack:



(def app
(-> (routes group-admin-routes
common-routes
(route/resources "/")
(route/not-found "404: Not Found"))
#_(wrap-file "resources/public")
(wrap-reload '(test-app.views.common)
'(test-app.views.groups))
(handler/site)
(wrap-strip-trailing-slash)))



When I run the app (using jetty, ring-serve, or deployed to cloudbees),
some pages pull in the css file, while others do not. Specifically,
given a URI of "/" or "/profile", the request for /css… is rerouted to
resources/public/css and the layout is styled. For all the group routes
and "/profile/:id" in common-routes, the css reference is not rerouted
and browser inspection of the http request shows that it's taken as
relative to the URL. The HTML for css inclusion and the links created
by the layout function are identical for each page. I've tried
"wrap-file", making the root specific with either "public" or
"resources/public" in the route/resources call, and other experiments
without success.



Do you have any idea what the problem might be?



Thanks in advance for your patience and help …


--
You received this message because you are subscribed to the Google
Groups "Compojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to compojure+...@googlegroups.com.
To post to this group, send email to comp...@googlegroups.com.
Visit this group at
[1]http://groups.google.com/group/compojure?hl=en.
For more options, visit [2]https://groups.google.com/groups/opt_out.

References

1. http://groups.google.com/group/compojure?hl=en
2. https://groups.google.com/groups/opt_out

[Matt Anderson]

Fred,

Thank you for the suggestion. I've tried that and it didn't make a difference in the resource requests I'm seeing in my browser developer tools.

This issue has become more baffling. After moving on to a couple of other issues, I returned to this, tried using wrap-files, and it worked, for every page. I was thinking that maybe there was another bug that was somehow interacting with Ring routing.

But then, after updating the layout function to include one more script, every page quit loading resources from "resources/public." Restarting the jetty server I've bene using didn't make a difference. Compiling and deploying to Cloudbees in each instance replicated the behavior on the server on my laptop.

Clearly there's something basic that I'm missing, but I'm at a loss figuring out what it is. Any other wild guesses would be appreciated. Thanks again,

Matt

[Sean Bowman]

Try something like this:

(defroutes my-routes

  (routes group-admin-routes

  common-routes)

  (route/resources "/")

  (route/not-found "404: Not Found"))

(def app 

  (-> #'my-routes

      wrap-reload

      (handler/site)))

[Matt Anderson]

Sean,

Thank you for the helpful suggestion. I tried your solution as written, and while it didn't work, unlike the other attempts I've made, it didn't fail silently. The error message I'm getting in my console is:

2013-04-10 13:52:24.614:WARN::/css/test-app.css

clojure.lang.ArityException: Wrong number of args (2) passed to: head$wrap-head$fn

at clojure.lang.AFn.throwArity(AFn.java:437)

at clojure.lang.AFn.invoke(AFn.java:43)

at ring.middleware.flash$wrap_flash$fn__653.invoke(flash.clj:19)

at ring.middleware.session$wrap_session$fn__646.invoke(session.clj:40)

at ring.middleware.cookies$wrap_cookies$fn__583.invoke(cookies.clj:160)

at noir.util.middleware$wrap_strip_trailing_slash$fn__1116.invoke(middleware.clj:53)

at clojure.lang.Var.invoke(Var.java:415)

at ring.adapter.jetty$proxy_handler$fn__375.invoke(jetty.clj:16)

at ring.adapter.jetty.proxy$org.mortbay.jetty.handler.AbstractHandler$0.handle(Unknown Source)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)

at org.mortbay.jetty.Server.handle(Server.java:326)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)

at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)

at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)

at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

… one for each file included.

Because the error message referenced arguments and was new, I tried it again without the sharp quote, and that failed too.

I'm guessing the error message refers to this function in ring (https://github.com/ring-clojure/ring/blob/master/ring-core/src/ring/middleware/head.clj):

(defn wrap-head
  "Middleware that turns any HEAD request into a GET, and then sets the response
  body to nil."
  [handler]
  (fn [request]
    (-> request
        head-request
        handler
        (head-response request))))

I'll keep picking away at it, but I'm having a hard time figuring out what's being passed into it. Any other ideas much appreciated.

Matt

[James Reeves]

There are a few odd things with the code you provide. As Fred Daoud noted, the include-css ref you use is a relative path, and therefore won't work on certain paths. You're passing lists of namespaces to wrap-reload when it expects file paths. You have a route that tries to call a string as a function. Some brackets are mismatched. There are a few other parts of your routes that are correct but somewhat strange.

Would it be possible to provide the whole codebase? It's difficult to tell what might be the issue when there are quite a few things in your example that would prevent the application from working.

- James

              (route/resources "/")

              (route/not-found "404: Not Found"))

    #_(wrap-file "resources/public")

    (wrap-reload '(test-app.views.common)

                 '(test-app.views.groups))

    (handler/site)

    (wrap-strip-trailing-slash)))

When I run the app (using jetty, ring-serve, or deployed to cloudbees), some pages pull in the css file, while others do not. Specifically, given a URI of "/" or "/profile", the request for /css… is rerouted to resources/public/css and the layout is styled. For all the group routes and "/profile/:id" in common-routes, the css reference is not rerouted and browser inspection of the http request shows that it's taken as relative to the URL. The HTML for css inclusion and the links created by the layout function are identical for each page. I've tried "wrap-file", making the root specific with either "public" or "resources/public" in the route/resources call, and other experiments without success.

Do you have any idea what the problem might be?

Thanks in advance for your patience and help …

--
You received this message because you are subscribed to the Google Groups "Compojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to compojure+...@googlegroups.com.
To post to this group, send email to comp...@googlegroups.com.

Visit this group at http://groups.google.com/group/compojure?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matt Anderson]

James,

Thank you. I appreciate your pointing out the strangeness in the snippets I posted. I'm new at this and doing my best. And I've probably compounded it experimenting with "solutions."

If you're willing to look at the whole codebase, how do you suggest I share it? In the meantime, you've given me several things to look at. Much appreciated.

Matt

[Matt Anderson]

Okay, your collective suggestions of problems to investigate solved my problem. The resources are loading again.

1. I added "/" to the front of the file paths in the include statements.

2. I took the routes I was referencing out of the -> macro and listed them inside a defroutes call instead as suggested by Sean. 

3. I cleaned up the wrap-reload calls as suggested by James.

With those three changes, (route/resources "/") still wasn't redirecting, but at least on every test page the HTTP calls were going to the same path. I tried with (wrap-file "resources/public") in the middleware stack and most of the files were successfully loading.

At that point I started to feel really stupid because the main CSS file which wasn't loading was misspelled by one character. I'm baffled I missed that before; what a difference a day makes.

Thanks again for all your kind suggestions and for a library which even a novice, prone to mistakes, can make some headway toward building something useful.

Matt 

[Matt Anderson]

Oh, and one more thing, should anyone reference this again: the strangeness James pointed out (the unneeded keys, redundant references, calling a string as a function) was an artifact of earlier test views. Those have also been cleaned up now, but after the files began to load correctly.