I finally found an acceptable solution by : - using a test webapp structure in src/test/webapp so that I can register simplified (mock) GWT-RPC servlet implementations and not require my full webapp to test in hosted mode (can still use noserver for that) - creating the exploded WAR structure for jetty WEB-INF/lib when the plugin generates the launch configurations - configuring my maven project to output compiled classes in jetty WEB-INF/classes (the plugin checks this configuration has been set)
Please let me know if you find a simplier way to integrate maven with Jetty ;-) On Thu, Feb 26, 2009 at 5:09 PM, nicolas de loof <nicolas.del...@gmail.com>wrote: > You may be interested to see how jetty guys integrate with maven : > http://www.mortbay.org/jetty/jetty-6/xref/org/mortbay/jetty/plugin/Jetty6MavenConfiguration.html > > They use a classPathFiles List created by the maven "jetty:run" goal to > setup the jetty webappClassLoader. Maybe some comparable setup could be > integrated into hosted mode ? > > Cheers, > Nicolas > > > On Thu, Feb 26, 2009 at 4:55 PM, nicolas de loof <nicolas.del...@gmail.com > > wrote: > >> I tested the "create exploded webapp structure in maven plugin before >> creating lauch configurations" strategy. >> I can launch the hosted browser but this has serious productivity cost : >> The /lib folder is not supposed to change often, so this is not an issue to >> poulate it from maven dependencies. >> The issue is with the (server-side) classes that I had to copy to >> /WEB-INF/classes. This must be done before every restart of the Hosted >> Browser when any Java file has been changed to sync sources and classes >> executed inside Jetty. As maven (or Eclipse + m2eclipse) compile to >> target/classes I'd prefer to avoid such costy setup. >> >> Nicolas >> >> On Thu, Feb 26, 2009 at 2:38 PM, nicolas de loof < >> nicolas.del...@gmail.com> wrote: >> >>> To make things a little clearer, here is how I understand the way >>> classloader are built by Hosted mode : >>> bootClasspath <gwt-dev> >>> |_ HostedMode >>> |_ Hosted Browser .... >>> | >>> |_ Jetty Embedded >>> |_ WebApplicationClassLoader <WEB-INF/lib/*> >>> >>> How does Jetty access project (service-side classes) ? >>> >>> The "maven" way to run Hosted Mode would be : >>> >>> >>> bootClasspath >>> |_ Maven laucher <UrlClassLoader : full project classpath (sources, >>> classes and libs)> >>> |_ HostedMode >>> |_ Hosted Browser .... >>> | >>> |_ Jetty Embedded >>> |_ WebApplicationClassLoader <WEB-INF/lib/ is >>> empty> >>> >>> As the Maven Laucher can setup any argument / system variable that may be >>> required, is there any way to configure the way Ebedded Jetty search for web >>> application libs & classes ? >>> >>> Another option would be for the plugin to "prepare" the WEB-INF/lib with >>> project libs - code doing this allready exists - but with more impact on >>> Hosted mode launch speed. >>> >>> Cheers, >>> Nicolas >>> >>> >>> >>> >>> On Thu, Feb 26, 2009 at 11:59 AM, nicolas de loof < >>> nicolas.del...@gmail.com> wrote: >>> >>>> I've found an (ugly ?) workaround by adding xercesImpl in the bootstrap >>>> classpath and setting the javax.xml.parsers.SAXParserFactory system >>>> property. >>>> With this config the plugin can assume the SAX parser to be used in >>>> hosted mode - not very pleasant as the user can't configure it's own, but >>>> fixes the hosted mode lauch issue. >>>> >>>> >>>> Another question about configuring jetty : it expects a web.xml to >>>> define the RPC servlets. Many of us will use some more complex server side >>>> setup, for example including Spring and Hibernate, DataSources >>>> configuration, ... etc >>>> >>>> Running such "complex" server side components with hosted mode is easy >>>> with noserver, as we can setup the adequate servlet container. But with >>>> hosted mode jetty I fall into classloaders issues (jetty expect my libs to >>>> be in WEB-INF/lib, but they are set in eclipse launch classpath) >>>> >>>> The simpliest fix could be to have a dedicated web.xml file for jetty >>>> and hosted mode using mock-servlet RPC implementations. This is possible >>>> with 1.5 as the module <servlet> element is >>>> not used after compilation into a webapp. >>>> >>>> Any suggestion of a best-practice ? Any way to configure jetty to use an >>>> alternate web.xml ? >>>> >>>> Cheers, >>>> Nicolas >>>> On Wed, Feb 25, 2009 at 6:21 PM, Sami Jaber <sami.ja...@gmail.com>wrote: >>>> >>>>> This is a very important issue. To resolve it, we had to code a custom >>>>> servlet container launcher, this way : >>>>> >>>>> * **/** >>>>> * Ensures that only Jetty and other server classes can be loaded >>>>> into the >>>>> * {...@link WebAppClassLoader}. This forces the user to put any >>>>> necessary >>>>> * dependencies into WEB-INF/lib. >>>>> */* >>>>> >>>>> *private* *final* ClassLoader parentClassLoader = *new* >>>>> ClassLoader(*null*) { >>>>> *private* *final* ClassLoader delegateTo = Thread.*currentThread >>>>> *().getContextClassLoader(); >>>>> >>>>> @Override >>>>> *protected* Class<?> findClass(String name) *throws* >>>>> ClassNotFoundException >>>>> { >>>>> *if* (webAppClassLoader != *null >>>>> && (webAppClassLoader.isServerPath(name) || >>>>> webAppClassLoader.isSystemPath(name))) { >>>>> return delegateTo.loadClass(name); >>>>> } >>>>> throw new ClassNotFoundException(); >>>>> } >>>>> };* >>>>> Works with -server MyCustomJettyLauncher >>>>> >>>>> This is not very smooth, but that works. >>>>> Scott, maven is widely used by many folks out there, constraining >>>>> ressources to be loaded from WEB-INF/lib doesn't make sense in Dev mode. >>>>> Especially when you have many classes. The hosted mode should be able to >>>>> use >>>>> the classes passed from the command line by the Eclipse Maven plugin (kind >>>>> of -cp %maven_classes%). >>>>> >>>>> Sami >>>>> >>>>> >>>>> >>>>> On Wed, Feb 25, 2009 at 6:04 PM, Scott Blum <sco...@google.com> wrote: >>>>> >>>>>> I take your point. >>>>>> In the general case, server side dependencies need to be copied into >>>>>> WEB-INF/lib. Otherwise, the server code won't be able to access it. I >>>>>> can >>>>>> see how an XML parser might be a special case where the servlet container >>>>>> could be reasonably expected to provide it. >>>>>> >>>>>> Toby, do you have any thoughts on this? I think you're familiar with >>>>>> the pattern we're using of isolating Jetty from the system classpath to >>>>>> enforce the rule that server deps have to go into WEB-INF/lib (as >>>>>> opposed to >>>>>> just being on the system classpath). How are things like XML parsers >>>>>> generally treated? Should we special-case this? >>>>>> >>>>>> Thanks, >>>>>> Scott >>>>>> >>>>>> >>>>>> On Wed, Feb 25, 2009 at 11:52 AM, nicolas de loof < >>>>>> nicolas.del...@gmail.com> wrote: >>>>>> >>>>>>> As I said my application has many other libs, including xerces (and >>>>>>> spring, hibernate, aspectJ ...) so there is MANY reason for me to have >>>>>>> another SAX parser in my classpath. >>>>>>> The issue here is that in my case I can manually put the parser in >>>>>>> web-inf/lib, but the maven plugin is expected to automagically >>>>>>> configure the >>>>>>> project, and has no simple way to detect what is the SAX parser used >>>>>>> when >>>>>>> running the project. >>>>>>> >>>>>>> Another option (that works) is to force use of the default SAX parser >>>>>>> using >>>>>>> -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl >>>>>>> JVM option, but this has the side effect to require the SUN JVM. What >>>>>>> about >>>>>>> Jrockit fans ? >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 25, 2009 at 5:46 PM, Scott Blum <sco...@google.com>wrote: >>>>>>> >>>>>>>> I've seen this before. The workaround is to put a copy of Xerces >>>>>>>> into your WEB-INF/lib. >>>>>>>> What's weird is that on my system, the default SAX parser factory is >>>>>>>> in the com.sun.* namespace, which lives in the bootstrap ClassLoader >>>>>>>> and >>>>>>>> works fine. I wonder why your default SAX parser factory is pointing >>>>>>>> at the >>>>>>>> raw org.apache version, which lives in gwt-dev and isn't on the >>>>>>>> bootstrap >>>>>>>> loader? >>>>>>>> We could always put an explicit pass-through in >>>>>>>> WebAppContextWithReload to allow this package. Can you file an issue >>>>>>>> and >>>>>>>> write back on this thread with a link to it? >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 25, 2009 at 11:24 AM, nicolas de loof < >>>>>>>> nicolas.del...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi >>>>>>>>> I'm testing the Eclipse lauch configuration generated by the >>>>>>>>> gwt-maven-plugin for gwt 1.6. >>>>>>>>> My webapp project has many dependencies managed as an Eclipse >>>>>>>>> classpath-container (thanks to m2eclipse plugin). >>>>>>>>> Running the lauch file I get a classpath issue : >>>>>>>>> >>>>>>>>> 16:57:29,331 ERROR [log.invoke0](?) failed >>>>>>>>> com.google.gwt.dev.shell.jetty.jettylauncher$webappcontextwithrel...@1e2105f >>>>>>>>> {/,D:\projets\bios\bios-relation-client\bios-rc-webapp\target\bios-rc-webapp-1.0.0-SNAPSHOT} >>>>>>>>> javax.xml.parsers.FactoryConfigurationError: Provider >>>>>>>>> org.apache.xerces.jaxp.SAXParserFactoryImpl not found >>>>>>>>> at >>>>>>>>> javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:113) >>>>>>>>> at org.mortbay.xml.XmlParser.setValidating(XmlParser.java:92) >>>>>>>>> at org.mortbay.xml.XmlParser.<init>(XmlParser.java:84) >>>>>>>>> at >>>>>>>>> org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp(TagLibConfiguration.java:199) >>>>>>>>> at >>>>>>>>> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1217) >>>>>>>>> at >>>>>>>>> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:513) >>>>>>>>> at >>>>>>>>> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) >>>>>>>>> at >>>>>>>>> com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:236) >>>>>>>>> at >>>>>>>>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39) >>>>>>>>> at >>>>>>>>> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) >>>>>>>>> at org.mortbay.jetty.Server.doStart(Server.java:222) >>>>>>>>> at >>>>>>>>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39) >>>>>>>>> at >>>>>>>>> com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:286) >>>>>>>>> at >>>>>>>>> com.google.gwt.dev.HostedMode.doStartUpServer(HostedMode.java:367) >>>>>>>>> >>>>>>>>> >>>>>>>>> It seems to be yet another classloader issue, any suggestion ??? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
