On Fri, Jan 16, 2015 at 12:39 PM, Jan Bartel <[email protected]> wrote:
> > > > > 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 ;) > > I'm am luckily using Jetty 9. :-) But the corresponding page in the new documentation doesn't seem to cover this as well. The scenario of the exploded webapp is missing at https://www.eclipse.org/jetty/documentation/current/embedding-jetty.html To be honest, I think that the old documentation with the simple non-commented code examples is more encouraging than the new with lots of embedded comments. > > > 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. > > OK, so the approach we have taken to integrate jetty with other > 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. > > It's an option that I haven't looked into much. Adding it to my study list. :-) > 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? > > Yes, but... My main concern is about the teachability of embedded Jetty, not so much solving my own problem in a specific case. 1. I would like to do the switch automatically - after all, why do we have computers except to find out "the right thing" for us? 2. All the ways of avoiding filemapped buffers are difficult to come by and feel like black magic. I think the location of the web app is a smaller problem. I think that I can find a satisfying way of doing this (especially if the annotation scanning can be made to work). The filemapped buffers is something that I am more concerned about. Again, I'm mainly concerned about teachability. I have several times had people express "wow, this was really easy to get started with" and then a few hours laters start swearing about the locked files, only to throw Jetty away in disgust. To be honest, I think that you got the useFileMappedBuffer wrong. Perhaps the default should have been false? Perhaps the default should have been false if the resource was in the classpath? ~Johannes > > > > > > ~Johannes > > > >> > >> > On Fri, Jan 2, 2015 at 6:04 PM, Jan Bartel <[email protected]> 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 <[email protected] > > > >> >> 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 > >> >> > [email protected] > >> >> > To change your delivery options, retrieve your password, or > >> >> > unsubscribe > >> >> > from > >> >> > this list, visit > >> >> > https://dev.eclipse.org/mailman/listinfo/jetty-users > >> >> > >> >> > >> >> > >> >> -- > >> >> Jan Bartel <[email protected]> > >> >> www.webtide.com > >> >> 'Expert Jetty/CometD developer,production,operations advice' > >> >> _______________________________________________ > >> >> jetty-users mailing list > >> >> [email protected] > >> >> 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 > >> > [email protected] > >> > To change your delivery options, retrieve your password, or > unsubscribe > >> > from > >> > this list, visit > >> > https://dev.eclipse.org/mailman/listinfo/jetty-users > >> > >> > >> > >> -- > >> Jan Bartel <[email protected]> > >> www.webtide.com > >> 'Expert Jetty/CometD developer,production,operations advice' > >> _______________________________________________ > >> jetty-users mailing list > >> [email protected] > >> 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 > > [email protected] > > To change your delivery options, retrieve your password, or unsubscribe > from > > this list, visit > > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > -- > Jan Bartel <[email protected]> > www.webtide.com > 'Expert Jetty/CometD developer,production,operations advice' > _______________________________________________ > jetty-users mailing list > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
