Jetty runtime classpath in hosted-mode

[Robert Retzbach]

Hello,

After migrating from gwt 1.5.3 to 1.7.0 I encountered severe problems:

I'm starting my gwt shell as follows:
javaw.exe -classpath slf4j-api-1.5.2.jar;slf4j-log4j12-1.5.2.jar;...
com.google.gwt.dev.HostedMode -startupUrl ...

After startup I get a NoClassDefFoundError when my application tries
to load a slf4j class.

As far as I know there are two solutions to this issue:

1. Copy the relevant jar file to war/WEB-INF/lib
2. Use a custom JettyLauncher (via -server arg) and change
JettyLauncher$WebAppContextWithReload
$WebAppClassLoaderExtension#isSystemPath like so:

public boolean isSystemPath(String name) {
name = name.replace('/', '.');
return super.isSystemPath(name)
|| name.startsWith("org.apache.jasper.")
|| name.startsWith("org.slf4j.")
|| name.startsWith("org.apache.xerces.");
}

Both solutions mean a great deal of additional work everytime my
dependencies change and are therefore merely a workaround but no
solution.

Wouldn't it be nice to be able to use all the classes defined by the
classpath at runtime?

This wasn't a problem in gwt 1.5 using tomcat.
What can I do?


Best regards
Robert

[Richard Vowles]

We have had exactly the same problem. Part of the problem appears to
be that in JettyLauncher, they start off with an empty class path and
just start adding stuff as it is requested. This has bitten us badly
as we have been trying to use Spring auto-wiring (which searches the
classpath using findResources).

The easy answer for us is to replace the line where the
bootStrapOnlyClassLoader is set to an empty class, just set it to the
system classpath (which is on the next line of code). If you do this,
then it works no problem (well, it seems to at the moment). I don't
understand why they are slowly added "as needed" but we will have to
create our own variant of the JettyLauncher and use that going forward
if it isn't fixed... :-(

Richard

[Robert Retzbach]

Thanks Richard,

changing my custom JettyLauncher, specifically this line:
private final ClassLoader bootStrapOnlyClassLoader = new ClassLoader
(null) {};

into this line:
private final ClassLoader bootStrapOnlyClassLoader =
Thread.currentThread().getContextClassLoader();

works so far.

Do you have any information whether this problem is already tracked as
an issue in the GWT issue tracker?
Otherwise I'd suggest to open an issue.

Cheers

On 13 Aug., 06:28, Richard Vowles <richard.vow...@gmail.com> wrote:
> We have had exactly the same problem. Part of the problem appears to
> be that in JettyLauncher, they start off with an empty class path and
> just start adding stuff as it is requested. This has bitten us badly

> as we have been trying to use Spring auto-wiring (which searches theclasspathusing findResources).

>
> The easy answer for us is to replace the line where the
> bootStrapOnlyClassLoader is set to an empty class, just set it to the

> systemclasspath(which is on the next line of code). If you do this,

> then it works no problem (well, it seems to at the moment). I don't
> understand why they are slowly added "as needed" but we will have to
> create our own variant of the JettyLauncher and use that going forward
> if it isn't fixed... :-(
>
> Richard
>
> On Aug 13, 3:44 am, Robert Retzbach <rretzb...@googlemail.com> wrote:
>
> > Hello,
>
> > After migrating from gwt 1.5.3 to 1.7.0 I encountered severe problems:
>
> > I'm starting my gwt shell as follows:

> > javaw.exe -classpathslf4j-api-1.5.2.jar;slf4j-log4j12-1.5.2.jar;...

> > com.google.gwt.dev.HostedMode -startupUrl ...
>
> > After startup I get a NoClassDefFoundError when my application tries
> > to load a slf4j class.
>
> > As far as I know there are two solutions to this issue:
>
> > 1. Copy the relevant jar file to war/WEB-INF/lib
> > 2. Use a custom JettyLauncher (via -server arg) and change
> > JettyLauncher$WebAppContextWithReload
> > $WebAppClassLoaderExtension#isSystemPath like so:
>
> >               public boolean isSystemPath(String name) {
> >                 name = name.replace('/', '.');
> >                 return super.isSystemPath(name)
> >                     || name.startsWith("org.apache.jasper.")
> >                     || name.startsWith("org.slf4j.")
> >                     || name.startsWith("org.apache.xerces.");
> >               }
>
> > Both solutions mean a great deal of additional work everytime my
> > dependencies change and are therefore merely a workaround but no
> > solution.
>
> > Wouldn't it be nice to be able to use all the classes defined by the

> >classpathat runtime?