Forwarding an 1.6RC issue.

I get an error using spring as well when I attempt to extends RemoteServiceServlet:

Caused by: java.lang.LinkageError: Class javax/servlet/http/HttpServletResponse
violates loader constraints

This error didn't occur in 1.6.1 (although I never got everything quite working there
either).  I hope this is related to the above.  

Using Spring 2.5.6, Maven, and GWT 1.6.2.

I attempted to remove HttpServletResponse from the dev library (using osx) as
suggested in the workaround above, but the problem persisted.

(No comment was entered for this change.)

Can someone verify a fix for me?

Take the attached jar and put it on your classpath ahead of gwt-dev-<platform>.jar.  
See if it fixes the "not and instance of Servlet" problem (and doesn't cause other 
problems).

Lemme know if that works, thanks,
Scott

	gwt-dev-patch.jar
	18.6 KB Download

Toby, Bruce-- here's the actual fix (assuming it works).

Basically, the patch is to prioritize the server/system check above loading things 
into the app's classloader.  What was happening is this:

1) User tries to load a class that's not in the WebAppClassLoader, but is in gwt-dev-
windows.jar

2) GWT warns and maps gwt-dev-windows.jar into the WebAppClassLoader.

3) gwt-dev-windows.jar contains javax.servlet.Servlet and lots of other problematic 
classes

4) A subsequent request for javax.servlet.Servlet defines a new copy of the class 
inside the WebAppClassLoader, which is of course unrelated to the one outside of it.

5) Badness ensues.

As far as I can tell, this is fixed by making Jetty ALWAYS load "server" and "system" 
stuff directly from the system classloader and never make copies inside the WebAppClassLoader.  But I'm not 100% confident this patch might not mess something 
else up.

If this round of changes doesn't seem to fix it, we might just want to bail on that 
warning for 1.6 and go back to the very permissive behavior.

	jetty-launcher-1-6.patch
	2.4 KB Download

Actually, here's a slight variation for consideration, that much more closely follows 
the structure of Jetty's WebAppClassLoader.loadClass().  I think I misunderstood 
before what the purpose of "isServerClass" was.

	jetty-launcher-2-1-6.patch
	2.4 KB Download

Scott,

First off, thanks for the really quick turnaround. The patch seems to have solved the
problem, but I think the change you are talking about is still messing with my
configuration.

Not sure if my problem stems from the fact that I am no longer using an eclipse
plugin to manage my launch (both Cypal and gwttooling haven't upgraded to 1.6 yet),
but I get a ton of "[WARN] Server class
'org.springframework.core.NestedRuntimeException' could not be found in the web app,
but was found on the system classpath" - not just for spring classes but my own
libraries as well.  I am also forced to add source paths into my classpath for my
runtime configuration.  Previously, maven took care of it (maven is outputting .java
files as well as .class files into its target directory).

As well, my load-up time in hosted mode is considerably slower, not sure but I hope
this is related.

If you could point me to some documentation as to how to properly configure to avoid
these warnings, that would be great.

Thanks again for the quick patch.

Josh: can you verify you have copies of all your server-side jars in WEB-INF/lib?  
That warning message is supposed to trigger when you're missing necessary server code 
there.

Needing to add source paths is expected, GWT has always worked that way since it 
compiles your code from source.

Scott: Actually, we're using maven, so the libraries are dynamically linked in to the
launch.

In the Launch configuration, classpath tab, there is a entry under "user entry" for
maven dependencies.  Some of these maven dependencies are libraries in our maven
repository while others refer to other open projects in the workspace.  I think this
is a fairly typical setup using maven.  

Unfortunately, I'm no expert at all this setup, and I don't think the gwt-maven code
has been updated for 1.6.  At least I'm up and running now. 

Ah, okay.  Yeah, maven's not going to put those things into WEB-INF/lib like it ought 
to.  However, we did put in an escape valve.  If you set the system property 
"gwt.nowarn.webapp.classpath", those warnings will be suppressed.  I expect an 
updated Maven plugin will set this property.

I don't know if this is related but when I switch from version 1.6.1 to 1.6.2, I get
the following error in hosted mode (compiled mode works fine).

[WARN] Nested in java.lang.ExceptionInInitializerError:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.
 You have more than one version of 'org.apache.commons.logging.Log' visible, which is
not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid
class loader hierarchy.  You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy.
 You have more than one version of 'org.apache.commons.logging.Log' visible, which is
not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid
class loader hierarchy.  You have more than one version of
'org.apache.commons.logging.Log' visible, which is not allowed.))

I'm also using Spring and Maven but I'm not running the hosted mode with the Maven
pluggin, I'm using an Ant script...

Danny: do you get this even when using the gwt-dev-patch.jar from earlier in this 
thread?

Sorry, I hadn't realized that the patch was right there smiling at me (lazy reader) :-)

So yeah it worked but I couldn't find how to tell maven to put the patch "ahead" in
the classpath so I ended up updating the whole gwt-dev jar...

Anyway, thanks for your help.  As I hoped, the new version solved an issue I had :
http://groups.google.ca/group/Google-Web-Toolkit/browse_thread/thread/6ceee6d2308ec8be/a899b76509e30b91

Fixed in r5077 & r5078.

(No comment was entered for this change.)

Scott, is this fix in the RC2 release, because I get a different problem in RC2 (to do with SLF4J Logger - I'm using 
Spring/Hibernate).  If I apply the dev-patch to the 1.6.3 things work fine.  I'm hoping this fix didn't make it into 
RC2, otherwise it appears there is another issue.

This fix (or a slight variation) is in RC2.  If you're still getting problems in RC2, 
please give me exact details, because what went into RC2 is very slightly different 
from what went into the patch jar.

Scott,

Not sure how detailed I can go.  I'm using Spring+Hibernate.  From what I can tell,
Hibernate requires org/slf4j/LoggerFactory, which is included in my maven
dependencies.  When I run RC2 with the dev patch, things run fine, without the patch,
I get:

Caused by: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
	at org.hibernate.cfg.annotations.Version.<clinit>(Version.java:12)
	at org.hibernate.cfg.AnnotationConfiguration.<clinit>(AnnotationConfiguration.java:78)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

etc...

Let me know if you need more information, thanks again for your help.  I assume this
will be a problem for a lot of other spring/hibernate/maven users.

Josh : I think you need to include on of the implementation libraries for slf4j.  the
slf4j-api dependency includes only the interfaces of the api but you need to
explicitly define wich implementation you want.

For example, if you're using log4j, you may add :

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
</dependency>

Hope that helps...

Hey Scott,

I've actually done that (slf4j-log4j13-1.0.1) which implements Logger.  As I said,
with the dev-patch, things work perfectly.  With RC2 -patch, I get the error,

 

Bruce: what I originally pushed out as gwt-dev-patch.jar was based on version 1 of 
the patch above.  What I actually committed was slightly different, version 2 of the 
patch above.  It looks like for most users RC2 (which has patch2) works just fine, 
but a couple of users are reporting patch1 worked but RC2 doesn't.  That's all I know 
if you guys decide to look at this today.

Little information. I used GWT 1.6.4 and have the same problems when using spring +
hibernate. I integrate the dev-patch to my maven dependencies and now everything
works fine. I hope this bug will be fixed soon.

If 1.6.4 is broken for you, but 1.6.4 + gwt-dev-patch is working for you, I need a 
small sample demonstrating the exact problem you're having.

1_6_RC2 has been released.

hi, I also get this issue. 

I have the same issue as @mlegenhausen. Compilation of application using GWT 1.6.4
and GXT 2.0M1 crashes (java.lang.StackOverflowError) if the gwt-dev-patch.jar is not
present but works fine otherwise.

Is there a why to merge the gwt-dev-patch.jar with the gwt-dev-window.jar in my maven
repository?

Sure, just use any zip or jar tool.  You just want all the files in gwt-dev-patch.jar 
to overwrite the existing ones in gwt-dev-windows.jar.  One way to do that might be 
to unpackage them and repackage them.

Thanks for the answer @scottb. I have done this already and it works fine for me. 

I was looking though for a 'cleaner' solution. I've installed the gwt-dev-patch.jar
in my local m2 repository but I'm not sure how to enforce that the patch jar comes
before the dev-windows.jar on the classpath. Is there a way to configure the maven
dependencies so that the gwt-dev-patch.jar comes in the classpath before the
gwt-dev-windows.jar?

I dunno, but we're going to do a 1.6.5 that will include the fix in not too long.

@christian 
You can get the dev-patch before the gwt jars by using maven 2.0.9 or greater, cause
in this release there determine the classpath order like you have it definied in your
pom.xml.

@scottb
I'm looking forward for the 1.6.5 release. Thx

@mlegenhausen
didn't know that the newt mavens preserve the classpath order. Thanks for the tip

This issue is still present in GWT-1.7.0.  The patch jar fixes it, but I would rather 
not have to include a patch.  This is not fixed!!!!  This error occurs for me when I 
include hibernate in my project along with slf4j-log4j12.  I would get a class not 
found exception for slf4j with hibernate tried to load.

Nevermind comment 33 (deleted).  See comment #23... I need a small exemplary sample to 
debug what's different between the original and final patch.

Here is a sample project.  We use maven for dependency management so our jars are 
linked in -- not copied to the WEB-INF/lib directory.  To simulate this, I created an 
external-libs folder and linked those jars in.  This is the sample GWT project using 
spring to discover the services (gwtrpcspring).  The problem occurs when spring loads 
hibernate and hibernate trys to load slf4j.  Run the project and look at the error 
message in the jetty console.  I confirmed that the patch jar above fixes the issue in 
this project.

	GwtJettyLaunchBug.zip
	8.3 MB Download

Thanks, I'll take a look when I can.

We had a similar problem trying to deploy jpbm on the server side, and tried copying
the slf jars to web-inf/lib by hand - apparently, this fixes the issue at (at least
temporarily).

Any news on a final resolution?

The SLF4J-classes-not-loaded-in-hosted-mode issue is also discussed in this thread on
the forums:
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/481165b48dbbb2c9

It discusses 2 possible workarounds.

Besides affecting Maven, which links files into WEB-INF/lib, it also affects Gradle
(gradle.org) which does the same thing as Maven.

I got slf4j issue too like others : 
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory

Problem tempory fixed if copy past lib in WEB-INF/lib directly... waiting for fix.

GWT version : 1.7.1

Better solution :
http://osdir.com/ml/GoogleWebToolkit/2009-04/msg01034.html