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
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
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
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
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
On Thu, Feb 26, 2009 at 5:59 AM, nicolas de loof
nicolas.del...@gmail.comwrote:
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
I fully agree about the noserver option when some server-side setup is
required. I myself consider the hosted-mode server only for UI testing with
mock gwt-RPC servlets.
The issue here with maven integration is that even the simpliest server
setup (only RPC RemoteServlet with no dependency on any
On Thu, Feb 26, 2009 at 11:53 AM, nicolas de loof
nicolas.del...@gmail.comwrote:
The issue here with maven integration is that even the simpliest server
setup (only RPC RemoteServlet with no dependency on any other lib) requires
to put project classes and gwt-* libs in jetty WEB-INF, that is
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
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
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
I'm not sure I have all the context here, but as a guiding principle, Jetty
should be able to parse the XML files of web applications (web.xml, tag
libraries, etc...) regardless of whatever XML libraries are or are not
bundled with the webapp. This means:
1) Jetty should never use XML libraries
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
*
13 matches
Mail list logo
