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
-~----------~----~----~----~------~----~------~--~---
