| Re: [jetty-users] Avoiding file-locking when developing with embedded Jetty |
>
> Actually, you're right - there are enough ways. The approach that I am using
> is the same as the one from the Heroku sample application. It is also the
> way described under "Setting a Web Application Context" under
> https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty. I personally thing
> these are the best ways of using Jetty.
You are referring to old doco, the eclipse wiki is no longer the
canonical repository for jetty documentation. You should look at:
http://www.eclipse.org/jetty/documentation/. If you're looking at the
old wiki because you're using jetty-7 or jetty-8, then they're
end-of-life, and the best way forward is to upgrade to jetty-9 ;)
>OK, so the approach we have taken to integrate jetty with other> I have made an experimental implementation of the above code. In order to
> make it work, I had to fight
> org.eclipse.jetty.server.ResourceCache.getDirectBuffer pretty hard. I can
> fool this code "if (_useFileMappedBuffer && resource.getFile()!=null)" by
> making my resource return null for a file, but it would probably be more
> meaningful to create a new method
> org.eclipse.jetty.util.resource.Resource.isSupportingDirectBuffer.
>
> The resulting code would look something like this:
>
> public class SimpleServer {
> public static void main(String[] args) throws Exception {
> HandlerList handlers = new HandlerList();
> handlers.addHandler(new ShutdownHandler("randomtoken", false,
> true));
> handlers.addHandler(new WebApplication("/app",
> Resource.newProjectResource("/app")));
> Server server = new Server(5000);
> server.setHandler(handlers);
> server.start();
> System.out.println("Started " + server.getURI());
> }
> }
>
> Again: This is the same way of starting the Jetty as Heroku and on the
> Emdedding Jetty documentation pages, with additional ease of use during
> development. So it is not a new method, but an improvement to what I
> personally feel is the current best method. It also addresses the section
> "Setting a Web Application Context" under
> https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty, where there are
> currently two examples. This approach unifies them. (This section seems to
> be missing from the new documentation at
> https://www.eclipse.org/jetty/documentation/current/embedding-jetty.html)
>
> The changes I would contribute are as follows:
>
> ResourceBuffer.getDirectBuffer() would use the new method
> Resource.isSupportingDirectBuffer() instead of checking for
> Resource.getFile() == null
> A new method Resource.newProjectResource would check if the classpath
> resource should be treated as a source resource and return a subclass of
> Resource which does not support direct buffer if so
> A new constructor to WebAppContext would take contextPath and baseResource
>
> In addition, I would like to contribute a subclass of WebAppContext
> (ClasspathWebAppContext) with a new method scanForAnnotations which mimics
> AnnotationConfiguration when you're not dealing with a WAR-file.
>
> Would you be interested in patches to this effect? If so, I can create a bug
> report with the modifications to Resource, WebAppContext and ResourceBuffer.
environments, is to subclass WebInfConfiguration. See the
MavenWebInfConfiguration for an example
(https://github.com/eclipse/jetty.project/blob/master/jetty-maven-plugin/src/main/java/org/eclipse/jetty/maven/plugin/MavenWebInfConfiguration.java).
This class is responsible for unpacking/copying a webapp (if
necessary) and establishing all of the container and webapp
classpaths, resource bases etc. We use this approach not only in
maven, but also ant and osgi where the webapp may be in different
forms (an unpacked war, or unassembled src dirs or bundles etc etc),
and the classpaths may be special (eg osgi). With regard to maven,
once the MavenWebInfConfiguration has done its work, the
AnnotationConfiguration (and all the other XXXConfigurations) is able
to work without modification. Our approach has also been to avoid
sublcassing WebAppContext so that as much of the tooling that we
already have just works and all of the adaptation is done in the
XXXConfiguration classes, which are designed to be pluggable. So
ideally I'd like any solution to follow this pattern.
However, I'd have to say that I'm not sure that doing any of that
would be a great saving ... All you're really wanting to do is to set
2 different variables: 1. the location of the webapp (a packed war or
unassembled dev dir) and 2. turn on or off useFileMappedBuffers. So it
seems an easy solution to me if you don't want to change the main
class code at all to simply pass these in either in a .properties file
or environment variables or on the command line. No?
>
>
> ~Johannes
>
>>
>> > On Fri, Jan 2, 2015 at 6:04 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:
>> >>
>> >> Hi Johannes,
>> >>
>> >> Have you considered using the jetty-runner? Here's the doc:
>> >>
>> >>
>> >> http://www.eclipse.org/jetty/documentation/current/runner.html#jetty-runner
>> >>
>> >> You could point it at your src/main/resources/webapp dir as the webapp
>> >> to deploy. However, as it seems you're running on windows, you'll need
>> >> to use a context xml file instead to set the context param to turn off
>> >> fileMappedBuffers, and to point to your webapp and context path.
>> >>
>> >> OTOH, your main is a pretty simple class ... it could be made more
>> >> generic by using system properties to set the context path, webapp to
>> >> deploy and the fileMappedBuffers property.
>> >>
>> >> cheers
>> >> Jan
>> >>
>> >> On 2 January 2015 at 16:15, Johannes Brodwall <johannes@xxxxxxxxxxxx>
>> >> wrote:
>> >> > Hi
>> >> >
>> >> > I would like to hear if someone could suggest how to scratch this
>> >> > itch I
>> >> > often have when using Jetty embedded in applications.
>> >> >
>> >> > I am often using Jetty during development. I'd like for static files
>> >> > that
>> >> > are normally packaged into a war or jar file to be easy to edit when
>> >> > I
>> >> > am
>> >> > developing (that is, when the files are not packaged). At the same
>> >> > time,
>> >> > I
>> >> > want my code to be as similar as possible during development and in
>> >> > production.
>> >> >
>> >> > My best attempt so far has been to place the static content under
>> >> > src/main/resources/webapp and package it into the Jar-file.
>> >> >
>> >> > In order to avoid locking the files when I'm running the server in
>> >> > the
>> >> > debugger, I've implemented the following:
>> >> >
>> >> > public static WebAppContext createApplicationContext() {
>> >> > WebAppContext webapp = new WebAppContext("/webapp", "/app");
>> >> >
>> >> > if
>> >> >
>> >> >
>> >> > (SimpleServer.class.getResource(webapp.getWar()).getProtocol().equals("file"))
>> >> > {
>> >> > // Avoid locking static content when running exploded
>> >> > webapp.setWar("src/main/resources/webapp");
>> >> >
>> >> >
>> >> >
>> >> > webapp.setInitParameter("org.eclipse.jetty.servlet.Default.useFileMappedBuffer",
>> >> > "false");
>> >> > }
>> >> > return webapp;
>> >> > }
>> >> >
>> >> > This runs in a main method like so:
>> >> >
>> >> > public class SimpleServer {
>> >> >
>> >> > public static void main(String[] args) throws Exception {
>> >> > HandlerList handlers = new HandlerList();
>> >> > handlers.addHandler(new ShutdownHandler("randomtoken", false,
>> >> > true));
>> >> > handlers.addHandler(createApplicationContext());
>> >> >
>> >> > Server server = new Server(5000);
>> >> > server.setHandler(handlers);
>> >> > server.start();
>> >> >
>> >> > System.out.println("Started " + server.getURI());
>> >> > }
>> >> > }
>> >> >
>> >> > As the rest of the code is extremely simple, the magic replacement of
>> >> > the
>> >> > target file with the source file and the setting of the very poorly
>> >> > documented "org.eclipse.jetty.servlet.Default.useFileMappedBuffer"
>> >> > parameter
>> >> > both feel really frustrating. The code is magic enough that I've
>> >> > ended
>> >> > up
>> >> > creating a "framework" to run it which is clearly not what I want.
>> >> >
>> >> >
>> >> > 1. Are there currently better ways of doing this?
>> >> > 2. Is there any way something that accomplishes the same could be
>> >> > added
>> >> > to
>> >> > Jetty itself?
>> >> >
>> >> >
>> >> > ~Johannes
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > jetty-users mailing list
>> >> > jetty-users@xxxxxxxxxxx
>> >> > To change your delivery options, retrieve your password, or
>> >> > unsubscribe
>> >> > from
>> >> > this list, visit
>> >> > https://dev.eclipse.org/mailman/listinfo/jetty-users
>> >>
>> >>
>> >>
>> >> --
>> >> Jan Bartel <janb@xxxxxxxxxxx>
>> >> www.webtide.com
>> >> 'Expert Jetty/CometD developer,production,operations advice'
>> >> _______________________________________________
>> >> jetty-users mailing list
>> >> jetty-users@xxxxxxxxxxx
>> >> To change your delivery options, retrieve your password, or unsubscribe
>> >> from this list, visit
>> >> https://dev.eclipse.org/mailman/listinfo/jetty-users
>> >
>> >
>> >
>> > _______________________________________________
>> > jetty-users mailing list
>> > jetty-users@xxxxxxxxxxx
>> > To change your delivery options, retrieve your password, or unsubscribe
>> > from
>> > this list, visit
>> > https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>>
>> --
>> Jan Bartel <janb@xxxxxxxxxxx>
>> www.webtide.com
>> 'Expert Jetty/CometD developer,production,operations advice'
>> _______________________________________________
>> jetty-users mailing list
>> jetty-users@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel <janb@xxxxxxxxxxx>
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users