incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: CCing wadi-dev for Geronimo commit r366236
Date Sat, 07 Jan 2006 16:58:17 GMT

Greg Wilkins wrote:
> Jeff Genender wrote:
>> This would be a big issue.  This would tie the connector to the container.
>> There is a better solution.  Please move the Spring jar out of the
>> container and place it in the WEB-INF/lib. Same for Axion.
>> Then in your plan...please add the following to your plan:
>> <hidden-classes><filter>org.springframework</filter></hidden-classes>
>> This should force the web app to use the local Spring which has access
>> to the Axion lib in the web app.
> I really think we need to take a step back and look at the whole deployment
> and configuration issue.
> A webapp should be able to be distributed simply by saying <distributable/> in

> its web.xml.   It should not have to include spring jars or any other jars for
> that matter in it's WEB-INF.   Any per web-app configuration for wadi should be
> able to be achieved without any jars - either in a wadi-web.xml file or perhaps
> just as context init-params in the web.xml?

I agree somewhat with you...but not completely.  The <distributable> tag
is only one small component.  We should be able to swap out with any
clustering engine, so I think it goes beyond this.  I do agree, however,
that there should be no need for WADI jars in the WEB-INF/lib.  The
configuration really should come from a WADI configuration car that is
imported into the plan.  This along with a distributable tag can make it
happen.  But I would like to see the imported car in the
geronimo-web.xml or plan file to be the clustering engine of choice.

> Having said that, adding spring to the hidden classes is a good idea.  Actually
> ALL the classes used by Wadi should be hidden, as the servlet specification says
> that container implementation classes should not be visible to a web application.
> It is a bit of a hack to allow them to be seen and manipulated by individual
> web applications.

This is a bigger issue that you think and affects far more than just
WADI.  Yesterday I just helped a friend deploy a simple Spring/Hibernate
application to Geronimo and it failed.  The only way to have it happen
was provide the hidden-classes filter for Spring and Antlr.  The problem
here was that we injected the Spring libs at the container level and via
the J2EE specs, it was using that for certain calls and the WEB-INF/lib
for others, thus offering ClassNotFoundExceptions (sound familiar?).
This goes back to the old commons logging problem that is so common,
even with other app servers and containers.  I don't think this is
avoidable due to the class loading engine and the very large amount of
components that Geronimo uses.  We will be filtering out a lot in the

> I think the idea of having the full clustering solution within WEB-INF was a good
> idea to get Wadi running on multiple containers.... but for real deployments it
> is not sufficient and we need to look at container support for Wadi.

I agree with you 100% on this point.

> cheers

View raw message