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
classloaders.
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.
thanks
david jencks
Jarek
On Mon, Oct 27, 2008 at 1:49 PM, Joe Bohn <[EMAIL PROTECTED]>
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
