Stream file from classpath to http response

[Francesco Cina]

Hi all,

I'm currently blocked with an apparently simple task, I have a file in the classpath and I need to send it as response to an http call. The file is a javascript library, but it could be whatever else (e.g.: css, png, svg, etc...).
The vertx.fileSystem() class only handles file from the file system and I'm not able to find an alternative for the classpath.
I'll be very grateful if someone could point me on the right direction.

Cheers
Francesco

[Tim Fox]

On 07/10/14 08:08, Francesco Cina wrote:

Hi all,

I'm currently blocked with an apparently simple task, I have a file in the classpath and I need to send it as response to an http call. The file is a javascript library, but it could be whatever else (e.g.: css, png, svg, etc...).
The vertx.fileSystem() class only handles file from the file system and I'm not able to find an alternative for the classpath.

I'm not really sure what you're asking here. Java doesn't provide any asynchronous method for getting resources from the classpath... Just get it using getResourceAsStream. But bear in mind this might block for some time especially if the resource is large.

I'll be very grateful if someone could point me on the right direction.

Cheers
Francesco

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francesco Cina]

On Tuesday, October 7, 2014 9:24:56 AM UTC+2, Tim Fox wrote:

On 07/10/14 08:08, Francesco Cina wrote:

Hi all,

I'm currently blocked with an apparently simple task, I have a file in the classpath and I need to send it as response to an http call. The file is a javascript library, but it could be whatever else (e.g.: css, png, svg, etc...).
The vertx.fileSystem() class only handles file from the file system and I'm not able to find an alternative for the classpath.

Hi Tim,

thanks for the fast reply!

I would like to reproduce the behaviour of Servlet 3.0 in which every file in the classpath in the "META-INF/resources/" path is automatically available as a web resource.
So it is not possible to read asynchronously from the classpath; however, maybe I'm wrong, but I remember that I read a post of yours in which you explained that even reading from the FileSystem and/or using an InputStream is always a blocking operation. If this is true the HttpServer should have the same blocking problem each time a static file is requested from the web root, am I wrong?
Do you think that using worker verticles to serve the files from the classpath could solve the issue?

[Tim Fox]

On 07/10/14 08:48, Francesco Cina wrote:

On Tuesday, October 7, 2014 9:24:56 AM UTC+2, Tim Fox wrote:

On 07/10/14 08:08, Francesco Cina wrote:

Hi all,

I'm currently blocked with an apparently simple task, I have a file in the classpath and I need to send it as response to an http call. The file is a javascript library, but it could be whatever else (e.g.: css, png, svg, etc...).
The vertx.fileSystem() class only handles file from the file system and I'm not able to find an alternative for the classpath.

Hi Tim,

thanks for the fast reply!

I would like to reproduce the behaviour of Servlet 3.0 in which every file in the classpath in the "META-INF/resources/" path is automatically available as a web resource.

Most probably, servlet engines are just using getResourceAsStream() to implement this behaviour. So, if you want to reproduce the behaviour of Vert.x 3.0 just use that.

So it is not possible to read asynchronously from the classpath; however, maybe I'm wrong, but I remember that I read a post of yours in which you explained that even reading from the FileSystem and/or using an InputStream is always a blocking operation.

Of course, the API is inherently synchronous - you can see that for yourself :)

The question is how long does it block for and is that going to be an issue for your application? If you have a long classpath and/or a large resource then it's probably going to block for longer than if you have a short claspath and/or small resource.

Again, how long is a piece of string? ;)

The only real way you can answer these questions is to experiment yourself.

[Julien Viet]

Webjars has a Java API for locating resources in jars, this can be used to extract files in a dir.

--
Julien Viet
www.julienviet.com

[Francesco Cina]

Thanks for the info. I'll have a look!

[Francesco Cina]

On Tuesday, October 7, 2014 10:12:05 AM UTC+2, Tim Fox wrote:

Most probably, servlet engines are just using getResourceAsStream() to implement this behaviour. So, if you want to reproduce the behaviour of Vert.x 3.0 just use that.

"Behaviour of Vert.x 3.0"?! Did you mean "Servlet 3.0" or there something new in vert.x 3.0 about the classpath?

[Tim Fox]

Yes, I meant servlet 3.0 :)

[Francesco Cina]

Ok, thank you for all the info!!

PS: I've always been attracted by vert.x but never fully convinced by it; however, vert.x 3.0 is unbelievably awesome!! I'm in love with it! So easy to embed, so natural to use! Congratulation Tim!

[Tim Fox]

On 07/10/14 13:29, Francesco Cina wrote:

Ok, thank you for all the info!!

PS: I've always been attracted by vert.x but never fully convinced by it; however, vert.x 3.0 is unbelievably awesome!! I'm in love with it! So easy to embed, so natural to use! Congratulation Tim!

Thanks! But it's not just me doing the work. I'll accept that on behalf of the whole team :)

I'm glad you like Vert.x 3.0. I agree it's going to be big improvement on 2.x - as soon as we can get it out (still lots more to do)

[Alexander Lehmann]

I wonder if it would make sense to load static resources into Buffers at startup and serve them from memory later. Assuming that the number and size of files is not very large and they do not change since we have a jar, that should be possible.

[Francesco Cina]

I'm wondering exactly the same. In addition, this is just a crazy idea (for the moment ate least), but if I pre-load the static resources from the classpath and put them in a hazelcast distributed map, then I can access at runtime resources available in other vertx instances... this is going to become an incredibly interesting way of wasting my free time :)

[Nicholas Whitehead]

Seems like an intresting test suite. One alternative that comes to mind is writing the serve-able content to disk. I have not tested this, but on Linux/Unix, you can take advantage of NIO Zero Copy where the content of the file is transfered directly to the net output channel. It's probably as fast or faster than an in VM copy of data from Hazelcast and comes at no [or less ?] heap cost.

[Alexander Lehmann]

I think Julien suggested that a bit futher up in the thread. Using local files is probably the preferrable solution since it will take advantage of the sendFile operation that keeps the JVM completely out of the operation.

Both ideas are interesting to look at IMHO.