On Thu, Feb 26, 2009 at 11:53 AM, nicolas de loof
wrote:
> 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 not the best
> option f
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 o
On Thu, Feb 26, 2009 at 5:59 AM, nicolas de loof
wrote:
> 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
>
> Ru
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 st
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 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
To make things a little clearer, here is how I understand the way
classloader are built by Hosted mode :
bootClasspath
|_ HostedMode
|_ Hosted Browser
|
|_ Jetty Embedded
|_ WebApplicationClassLoader
How does Jetty access project (service-side cla
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 t
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
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 fr
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 hav
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 automagi
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 pointin
13 matches
Mail list logo