geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: axis2 and cxf dependencies
Date Mon, 27 Oct 2008 19:50:07 GMT

On Oct 27, 2008, at 11:28 AM, Jarek Gawor wrote:

> We use Spring to configure CXF at runtime. As to jaxen, I'm pretty
> sure we can remove it (it is already removed in trunk but would have
> to double check for branches/2.1).
> In my opinion this is a general problem with ClassLoaders in Geronimo.
> Right now the application classloaders can see all the classes but
> they should really only see the public api. I think a lot of people
> keep running into these library conflicts issues and we should address
> it somehow.
> I don't think changing how we manage the default environment settings
> alone will fix this problem - it might minimize it by a bit but not
> solve it. And as far as I remember, we changed how the default
> environment settings were handled in the first place (we used to add
> them when needed) because of annotation processing introduced in 2.0.

That's my recollection also.

I agree that there's a problem with beyond-the-api visibility.  I  
haven't thought through what solution I'd like.

IIUC osgi has imports and exports from each bundle. I don't think we  
can do something like restricting exports to api classes as I think  
that would unduly restrict server extension.  Maybe we could  
automatically add imports just for apis to ee applications.

I think we could do something like this also with our current  

In any case, the default env fix would address a different problem,  
that we are currently adding the e.g. ws dependencies whether or not  
the app has any web services inside.

david jencks

> Jarek
> On Mon, Oct 27, 2008 at 1:49 PM, Joe Bohn <>  
> wrote:
>> Does anybody know why these dependencies are needed?
>> - plugins/cxf/cxf/pom.xml contains a dependency on the spring plugin
>> (org.apache.geronimo.configs/spring//car).
>> - plugins/axis2/axis2/pom.xml conains a dependency on the jaxen jar.
>> These are causing some problems when attempting to deploy Grails
>> applications into Geronimo.  We can bypass the problems by setting
>> springframework and jaxen as hidden-classes in the deployment plan  
>> for the
>> Grails application.  However, I was wondering why these are being  
>> pulled in
>> at all.  I discovered that I can build just fine (including the  
>> integration
>> tests) with these two entries omitted in branches/2.1.
>> There are other issues around this that David mentioned on the user  
>> list
>> (better management of the default environment settings so they are  
>> only
>> pulled in if really needed) ... but it might be more appropriate  
>> fix for
>> this specific problem if the dependencies are really not necessary  
>> at all.
>> Joe

View raw message