On Oct 27, 2008, at 9:08 AM, Joe Bohn wrote:
David Jencks wrote:
On Oct 24, 2008, at 11:13 AM, Joe Bohn wrote:
I've been playing around with grails and I encountered this exact
same behavior Michael mentioned. Even with Gianny's recommended
hidden classes I received the dom4j InvalidXPathException on the
Tomcat Javaee5 assembly.
I was able to get a grails app working on a tomcat javaee5
assembly by adding just one more filter for the jaxen classes.
So, my geroniom-web.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.2";>
<environment xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2
">
<moduleId>
<groupId>yourGroupId</groupId>
<artifactId>yourArtifactId</artifactId>
<version>yourVersion</version>
<type>war</type>
</moduleId>
<hidden-classes>
<filter>org.jaxen</filter>
<filter>org.springframework</filter>
<filter>org.apache.cxf</filter>
<filter>org.apache.commons</filter>
</hidden-classes>
</environment>
<context-root>/yourContextPath/</context-root>
</web-app>
BTW, it is true that you can deploy a grails app into either
minimal assembly without any hidden-class filters in the
deployment plan. The additional libraries in the javaee5
assemblies make the filters necessary. Apparently there are some
classloader differences between the Jetty and Tomcat assemblies
that make the jaxen addition necessary when deploying to a Tomcat
Javaee5 server.
It would be nice to figure out what the differences are. My first
guess would be myfaces, my second some web services bit. I think
that a ModuleBuilderExtension must be adding more dependencies for
no good reason. It would be even better to fix this.
I think your second guess is the right one. A little more
investigation revealed that the only real hidden-classes entries
needed are as follows:
- springframework - when installing in a javaee5 jetty assembly
- jaxen - when installing in a javaee5 tomcat assembly
That's because our axis2 module includes a dependency on jaxen and
our cxf module includes a dependency on spring.
I'm now experimenting to see if these dependencies are really
necessary. If they are, then the next step is to recall how to
exclude these dependencies from the default-environment when being
processed by the axis2 and cxf builders.
Actually the fix I was hoping for was for the MBEs to only add to the
default environment if they were actually going to install some gbeans
that needed the additions.
IIRC the last time I looked into this I got stuck....
problem:
we add in the MBE default env on the first call into the MBE before we
have enough info to look around and see if the MBE is applicable
By the time we do have enough info, the classloader is already set up
and doesn't seem to be modifiable.
Solution strategies:
1. Construct enough temporary context so we can actually figure out if
the MBE is applicable on the first call
2. Figure out how to reset the classloader in the middle of deployment
to a new one with the MBE dependencies in it, if needed
3. separate the deploy time classloader from the classloader structure
we record in the deployed car file. In other words, the MBE can add
the default env in to the classloader used for deployment, but
postpone the decision whether the default env should be added to the
classloader description in the car file.
3.a. Construct a MBE specific classloader with the default env and
including the regular deployment classloader as a parent. This can be
used for the "addGBeans" step. If we determine that the MBE is
applicable then we can add in the default env to the classloader
description in the car without trying to change the deployment
classloader.
I don't think (1) is practical, if anyone sees how to do it that would
be great. (2) seems conceptually cleanest but I couldn't get it to
work when I tried. I just thought of (3): I think 3.a would cause
less framework disruption and it seems a little cleaner to me.
thanks
david jencks
Joe
michaelg wrote:
I am writing an article for IBM developerWorks on using Grails
and Geronimo
together. However, I am unable to deploy a Grails WAR to
Geronimo. I first tried it with Geronimo 2.1.1 with Jetty. The
error I got was a
NoClassDefFound for
org.apache.commons.fileupload.FileItemFactory. This
class is the Geronimo repository, and is also included with the
Grails war.
It's the same version for both. Next I tried it with Geronimo
2.1.1 with Tomcat. This time I got a dom4j
InvalidXPathException. Next I tried the Little G distribution. It
worked perfectly. I had also
tried standalone Tomcat with success as well, so I guess this
should not
have been too surprising.
Obviously I have to point a finger at Grails or Geronimo, and
since it works
fine on Tomcat or Little G, I am pointing the finger at Geronimo.
The
Geronimo/Jetty error sure smelled like a class loader problem,
but I have no
clue on the Geronimo/Tomcat. Note, in all cases I included a
Geronimo
deployment plan inside the WAR (/WEB-INF/geronimo-web.xml) Any
ideas/advice is greatly appreciated.
