You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2003/06/03 15:28:38 UTC
The end of the infamous endorsed libs problem : ParanoidCocoonServlet
now really paranoid
Hi all,
Short story : once again, I've hit the famous endorsed library problem.
So as usual I copied Cocoon's Xalan and Xerces to
tomcat/common/endorsed, but unfortunately this broke another application
that was running in the same Tomcat.
Damn. How to solve this ? Install another Tomcat ? Yeah, it will work,
but will add yet-another-JVM to the server, which I wanted to avoid. So,
I decided to use ParanoidCocoonServlet, and discovered that it was
actually not paranoid at all because it was not using the
ParanoidClassLoader it was supposed to use :-(
So I refactored a bit all our servlets and now ParanoidCocoonServlet is
_really_ paranoid. This means, that its classloader will _always_ try to
load classes and resources first from WEB-INF/lib and WEB-INF/classes,
ignoring any similar classes existing in the parent classloader. Xalan,
Xerces, etc are now really immune to whatever version of the same
library can exist either in the JDK or in the servlet engine.
Such a strong shielding can have some drawbacks, however : if a class is
given by the servlet engine (e.g. a JNDI context) and the same class
exists in the webapp libs (e.g. in jndi.jar), then you're very likely to
get a ClassCastException. This is likely to happen mostly with standard
APIs, and the solution is then to remove the offending library from your
WEB-INF/lib.
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The end of the infamous endorsed libs problem :
ParanoidCocoonServlet now really paranoid
Posted by Geoff Howard <co...@leverageweb.com>.
At 09:42 AM 6/3/2003, you wrote:
>Sylvain Wallez wrote:
>>Such a strong shielding can have some drawbacks, however : if a class is
>>given by the servlet engine (e.g. a JNDI context) and the same class
>>exists in the webapp libs (e.g. in jndi.jar), then you're very likely to
>>get a ClassCastException. This is likely to happen mostly with standard
>>APIs, and the solution is then to remove the offending library from your
>>WEB-INF/lib.
>
>Good explanation. Any chance it will get into Javadoc and wiki? ;-)
Can you give a little more info on when we could expect this to
happen? Why would I get a class cast exception?
Geoff
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet
now really paranoid
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> Short story : once again, I've hit the famous endorsed library
>> problem. So as usual I copied Cocoon's Xalan and Xerces to
>> tomcat/common/endorsed, but unfortunately this broke another
>> application that was running in the same Tomcat.
>>
>> Damn. How to solve this ? Install another Tomcat ? Yeah, it will work,
>> but will add yet-another-JVM to the server, which I wanted to avoid.
>> So, I decided to use ParanoidCocoonServlet, and discovered that it was
>> actually not paranoid at all because it was not using the
>> ParanoidClassLoader it was supposed to use :-(
>>
>> So I refactored a bit all our servlets and now ParanoidCocoonServlet
>> is _really_ paranoid. This means, that its classloader will _always_
>> try to load classes and resources first from WEB-INF/lib and
>> WEB-INF/classes, ignoring any similar classes existing in the parent
>> classloader. Xalan, Xerces, etc are now really immune to whatever
>> version of the same library can exist either in the JDK or in the
>> servlet engine.
>>
>> Such a strong shielding can have some drawbacks, however : if a class
>> is given by the servlet engine (e.g. a JNDI context) and the same
>> class exists in the webapp libs (e.g. in jndi.jar), then you're very
>> likely to get a ClassCastException. This is likely to happen mostly
>> with standard APIs, and the solution is then to remove the offending
>> library from your WEB-INF/lib.
Oh good. You fixed all the problems I was having.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet now really paranoid
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 3 juin 2003, à 15:42 Europe/Zurich, Vadim Gritsenko a écrit :
> ...
> Good explanation. Any chance it will get into Javadoc and wiki? ;-)
I'm just wikifying it as we speak..
-Bertrand
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet
now really paranoid
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Hi all,
>
> Short story : once again, I've hit the famous endorsed library
> problem. So as usual I copied Cocoon's Xalan and Xerces to
> tomcat/common/endorsed, but unfortunately this broke another
> application that was running in the same Tomcat.
>
> Damn. How to solve this ? Install another Tomcat ? Yeah, it will work,
> but will add yet-another-JVM to the server, which I wanted to avoid.
> So, I decided to use ParanoidCocoonServlet, and discovered that it was
> actually not paranoid at all because it was not using the
> ParanoidClassLoader it was supposed to use :-(
>
> So I refactored a bit all our servlets and now ParanoidCocoonServlet
> is _really_ paranoid. This means, that its classloader will _always_
> try to load classes and resources first from WEB-INF/lib and
> WEB-INF/classes, ignoring any similar classes existing in the parent
> classloader. Xalan, Xerces, etc are now really immune to whatever
> version of the same library can exist either in the JDK or in the
> servlet engine.
>
> Such a strong shielding can have some drawbacks, however : if a class
> is given by the servlet engine (e.g. a JNDI context) and the same
> class exists in the webapp libs (e.g. in jndi.jar), then you're very
> likely to get a ClassCastException. This is likely to happen mostly
> with standard APIs, and the solution is then to remove the offending
> library from your WEB-INF/lib.
Good explanation. Any chance it will get into Javadoc and wiki? ;-)
Vadim
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet
now really paranoid
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bertrand Delacretaz wrote:
> Le Mardi, 3 juin 2003, à 15:28 Europe/Zurich, Sylvain Wallez a écrit :
>
>> ...Damn. How to solve this ? Install another Tomcat ? Yeah, it will
>> work, but will add yet-another-JVM to the server, which I wanted to
>> avoid. So, I decided to use ParanoidCocoonServlet, and discovered
>> that it was actually not paranoid at all because it was not using the
>> ParanoidClassLoader it was supposed to use :-(
>
>
> Great, thanks! More signal, less noise ;-)
> You've been wikified for posterity at
> http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem
Thanks Bertrand "the wikifier" !
However, I do not consider my initial post as some ultimate literature
that should go to posterity, and rewrote the whole thing with much more
details and explanations. I don't know if it's perfect, but at least
it's better ;-)
I also included some explanations for Geoff about the ClassCastException.
Comments & updates welcome !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServlet now really paranoid
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 3 juin 2003, à 15:28 Europe/Zurich, Sylvain Wallez a écrit :
> ...Damn. How to solve this ? Install another Tomcat ? Yeah, it will
> work, but will add yet-another-JVM to the server, which I wanted to
> avoid. So, I decided to use ParanoidCocoonServlet, and discovered that
> it was actually not paranoid at all because it was not using the
> ParanoidClassLoader it was supposed to use :-(
Great, thanks! More signal, less noise ;-)
You've been wikified for posterity at
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem
-Bertrand