[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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 for maven as it requires many files to get copied. > This is where we made a bit of a tough-love decision to conform to the Servlet spec by essentially requiring server side code to go into WEB-INF/lib and /classes. Output locations of .class files are generally quite configurable, for example in Eclipse projects we just literally set the output folder for source compilation to be WEB-INF/classes, and we add classpath entries to the Eclipse project that target WEB-INF/lib directly. While this may cause some friction with some build tools and configurations, the benefits of standardizing on the Servlet spec and exploded war structure seem to far outweigh the costs. It puts everyone on the same page in terms of tooling, documentation, assumptions, etc. Down the road it will enable features like generation of server-side bytecode. RPC for example could be much more efficient on the server if we generated bytecode instead of using reflection so heavily. That being said, I do want to address specific pain points like this XML validation problem. I repro'd this locally and you can trigger the problem in a straight up hosted mode launch merely by putting Xerces on the classpath. This seems pretty bad. :) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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 other lib) requires to put project classes and gwt-* libs in jetty WEB-INF, that is not the best option for maven as it requires many files to get copied. Take a look at the jetty6 MavenConfiguration to see that jetty guys found an alternate way by building the webapp classpath dynamically from maven dependencies. Cheers, Nicolas On Thu, Feb 26, 2009 at 5:42 PM, John Tamplin wrote: > 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 >> >> 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 intention is that if you need more complex configurations, you setup > your server yourself and run with -noserver. While it may or may not be > feasible to support your desired behavior with the built-in jetty, there are > going to be many unique configurations out there that will not work with it > so -noserver is the escape valve needed for those. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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 > > 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 intention is that if you need more complex configurations, you setup your server yourself and run with -noserver. While it may or may not be feasible to support your desired behavior with the built-in jetty, there are going to be many unique configurations out there that will not work with it so -noserver is the escape valve needed for those. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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
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 > 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
>>>|_ HostedMode
>>> |_ Hosted Browser
>>> |
>>> |_ Jetty Embedded
>>> |_ WebApplicationClassLoader
>>>
>>> How does Jetty access project (service-side classes) ?
>>>
>>> The "maven" way to run Hosted Mode would be :
>>>
>>>
>>> bootClasspath
>>>|_ Maven laucher >> classes and libs)>
>>>|_ HostedMode
>>> |_ Hosted Browser
>>> |
>>> |_ Jetty Embedded
>>> |_ WebApplicationClassLoader >> 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 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 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
>
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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
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 > wrote:
>
>> 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 classes) ?
>>
>> The "maven" way to run Hosted Mode would be :
>>
>>
>> bootClasspath
>>|_ Maven laucher > classes and libs)>
>>|_ HostedMode
>> |_ Hosted Browser
>> |
>> |_ Jetty Embedded
>> |_ WebApplicationClassLoader
>>
>> 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 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 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 lin
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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
wrote:
> 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 classes) ?
>
> The "maven" way to run Hosted Mode would be :
>
>
> bootClasspath
>|_ Maven laucher classes and libs)>
>|_ HostedMode
> |_ Hosted Browser
> |
> |_ Jetty Embedded
> |_ WebApplicationClassLoader
>
> 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 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 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 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
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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 classes) ?
The "maven" way to run Hosted Mode would be :
bootClasspath
|_ Maven laucher
|_ HostedMode
|_ Hosted Browser
|
|_ Jetty Embedded
|_ WebApplicationClassLoader
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
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 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 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 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 (tha
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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 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 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 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 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 ge
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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 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 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.(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
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed 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 from the webapp
2) Jetty should always be able to find an XML parser in the JDK
I'm not sure exactly what's going on in this situation to cause that to not
be true, but it should be fixed.
On Wed, Feb 25, 2009 at 12:04 PM, Scott Blum 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 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.(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
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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
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 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.(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
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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 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.(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
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Classloader issue running Hosted mode from Eclipse with Maven managed dependencies
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
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.(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
-~--~~~~--~~--~--~---
