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. 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 > >
