Aaron Mulder wrote:
To the original poster:
You actually need *Spring* in your hidden classes element. I believe
everything will work if you just list Spring alone (e.g.
org.springframework) and not Faces, Hibernate, or Commons Logging.
It's possible that you might need commons logging listed as well, but
I think once you're using the right Spring, it will get beyond the
commons logging problem.
So what should my geronimo-web.xml look like? Right now I've got
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0";
configId="MPLCommon">
<hidden-classes><filter>org.springframework</filter></hidden-classes>
<context-root>/mpl</context-root>
<context-priority-classloader>true</context-priority-classloader>
</web-app>
And I'm still getting the commons-logging error?
Thanks,
Rich
To Brill:
It wouldn't break my heart to see Geronimo default to the spec
behavior for class loading. I'm not sure that would solve this
problem (e.g. if the class is already loaded it may not load it
*again* from the web app loader), but I'd have to check the spec to be
sure.
To David J:
I'd still like to see applications on a class loader that has only the
spec classes as a parent and not the Geronimo implementation classes.
That is, we have a CL with all the spec JARs, with one child for the
server code and a separate child for the application code. Previously
I think you've said "it might work but we'd need to try it to be sure"
-- I'll try to experiment with this once the SVN tree stabilizes a
bit.
Thanks,
Aaron
On 3/18/06, Brill Pappin <[EMAIL PROTECTED]> wrote:
Isn't that non-standard?
I mean, Geronimo should be prefering the libs in the WAR over its own
libs. I thought that was part of the spec for webapps.
I've been having the same trouble myself, and its contrary to what I
expect having used a veriety of other app servers. Geronimo should not
be causing my application to blow up because of library conflicts.
I do think its ability to share libs easily is good, but I think the
default should be to isolate the webapp and allow sharing to be turned
on via the geronimo config xml file.
Does anyone know why Geronimo is so loose with its classloaders? Was
this a design choice or an artifact of some other issue?
If it was a design choice, I would *really* like to see the
justification for it... and if an artifact, it needs to be corrected
ASAP.
- Brill Pappin
On 3/17/06, David Jencks <[EMAIL PROTECTED]> wrote:
[...]
My first guess is that a copy of spring included in geronimo is
getting used in your web app instead of the copy you are trying to
use: when our copy tries to load the faces/hibernate classes it can't
find them. If this is the problem you should be able to fix it by
adding spring and hibernate to the hidden classes list in your
geronimo plan for your application.
[...]
