Re: Problem with static resources from webjars in a Ring app

497 views
Skip to first unread message

James Reeves

unread,
Apr 6, 2013, 9:11:47 AM4/6/13
to ring-c...@googlegroups.com
Have you tried using the resource path "META-INF/resources"?

In general, Java resource paths do not have a beginning "/".

- James


On 6 April 2013 11:32, Michiel Borkent <michiel...@gmail.com> wrote:
Dear all,

I've added a static resource from webjars to my project.clj:

[org.webjars/bootstrap "2.3.1"]

which also pulls in [org.webjars/jquery "1.9.0"].

To make these available I have added this to my middleware:

(resource/wrap-resource "/META-INF/resources/")

Since I've done this, a GET request to "/" returns an empty page. After some debugging I found out where it probably comes from.

In ring.util.response/resource-response I added a couple of debug println statements. 

See this refheap paste with the adapted version and the corresponding output:

https://www.refheap.com/paste/13318

What happens, I think, is the directory in the jar file jquery-1.9.0.jar gets recognized as a resource. It's protocol is not "file", hence it gets returned as an input-stream, which results in an empty page.

Is this a bug in ring-core? I would be surprised if I was the first one encountering this one.

Kind regards,

Michiel Borkent

--
You received this message because you are subscribed to the Google Groups "Ring" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-clojure...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Michiel Borkent

unread,
Apr 6, 2013, 9:27:58 AM4/6/13
to ring-c...@googlegroups.com, ja...@booleanknot.com
Hi James,

Thank you for responding.
I've tried this and there is no difference.

Op zaterdag 6 april 2013 15:11:47 UTC+2 schreef James Reeves het volgende:

Michiel Borkent

unread,
Apr 6, 2013, 9:40:10 AM4/6/13
to ring-c...@googlegroups.com
Steps to reproduce in a more general setting:

1)
$ lein new compojure reproduction
....
$ cd reproduction

2) edit project.clj and add [org.webjars/bootstrap "2.3.1"] to the dependencies
3) edit src/reproduction/handler.clj and edit 'app':

(def app
  (-> (handler/site app-routes)
      (resource/wrap-resource "META-INF/resources/")))

4) 
$ lein ring server
.. starts at port 3000
.. browser opens localhost:3000 and a blank page appears.

Op zaterdag 6 april 2013 12:32:02 UTC+2 schreef Michiel Borkent het volgende:

Nelson Morris

unread,
Apr 6, 2013, 9:42:11 AM4/6/13
to ring-c...@googlegroups.com
I've had similar issues as well with webjars and wrap-resource. I
eventually wanted to change the url vs the jar path and ended up using
compojure.routes/resources as:

(compojure.route/resources "/foundation/"
{:root "META-INF/resources/webjars/foundation/4.0.4/"})

Just checked my production site, and trying to find the directories
with this setup ends up failing through to my 404 handler.

Nelson Morris

unread,
Apr 6, 2013, 9:45:29 AM4/6/13
to ring-c...@googlegroups.com
Oops. I was wrong. Using this in my production setup Chrome
automatically saved a file for me as it returned an
"application/octet-stream". So looks like I still have the issue, but
it doesn't matter as much since I'm not serving resources on "/".

Michiel Borkent

unread,
Apr 6, 2013, 9:57:27 AM4/6/13
to ring-c...@googlegroups.com
Thank you Nelson. I've added a route like you said:

(route/resources "/bootstrap/" {:root "META-INF/resources/webjars/bootstrap/2.3.1/"})

This is actually a better idea, because then I have only to change the version number in one place when upgrading.

This is going to work out, as long as the issue is not resolved.

Op zaterdag 6 april 2013 15:45:29 UTC+2 schreef Nelson Morris het volgende:

James Reeves

unread,
Apr 6, 2013, 10:11:06 AM4/6/13
to Michiel Borkent, ring-c...@googlegroups.com
It appears as if there's no easy way of telling whether or not a resource from a jar file is a directory or a file. Both seem to count as resources to Java, with directories being zero-length files.

In general, compojure.route/resources is a better bet than using wrap-resource, as it provides more flexibility in terms of route matching. But this does seem like a bug in wrap-resource, though I'm not certain whether it's a resolvable one.

Perhaps the simplest solution is just to assume that no-one would want a zero-length resource, and change the behaviour of wrap-resource so that it only serves non-zero static resources.

- James

Reply all
Reply to author
Forward
0 new messages