On Apr 10, 2006, at 7:15 PM, Mammen wrote:
Guilherme Rios <[EMAIL PROTECTED]> writes:
The way I see it, a "vanilla" J2EE application would be deployed in
Geronimo without problems. The issue is, when you depend on projects
that Geronimo also provides and are not part of standard J2EE but
became
de facto standards, you have to use a vendor-specific deployment
plan.
This is not desirable, but does not differ much from what others
do either.
I would not consider it a J2EE compatibility issue, but given lots of
people - me included =) - will deploy struts/spring/hibernate apps to
Geronimo it would be nice being able to do so without having to deal
with specific application server issues.
This is a known problem. I don't expect this to be fixed in 1.1, but
hopefully soon after 1.1 ships we will have a fix available.
As far as I understood the specs, the webapps jar files in WEB-INF/
lib classes
should be visible to the web application, not servers when there
are different
versions of the same class. This way I can have many different
versions of
classes in seperate web app. This should be default.
Anyway the application that I am deploying has deployed
successfully into Tomcat,
Jetty and Weblogic without any modification in classloader
configuration.
There are two specs that come into play here. The Servlet specs says
the WEB-INF/LIB has precedence over the server classes, and the J2EE
spec says the exact opposite. Since Geronimo is a J2EE server the
default is to follow the J2EE spec. You can change this by setting
the inverse class loading option. Unfortunately, setting this flag
will not solve your problem (it's a long story), and you need the
hidden filters. To truly fix these problems, we need to isolate your
application classes into a separate class loader that can only see
the Servlet spec classes, and doing this requires some fairly
invasive changes to the deployment system.
-dain
