cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@infoplanning.com>
Subject Re: [TC4] ClassCastException with HttpServletrequestWrapper
Date Fri, 15 Dec 2000 13:41:03 GMT
----- Original Message ----- 
From: "Giacomo Pati" <pati_giacomo@yahoo.com>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, December 15, 2000 3:40 AM
Subject: Re: [TC4] ClassCastException with HttpServletrequestWrapper


> 
> --- Berin Loritsch <bloritsch@infoplanning.com> wrote:
> > 
> > ----- Original Message ----- 
> > From: "Giacomo Pati" <giacomo@apache.org>
> > To: "Cocoon dev" <cocoon-dev@xml.apache.org>
> > Sent: Wednesday, December 13, 2000 6:07 PM
> > Subject: [TC4] ClassCastException with HttpServletrequestWrapper
> > 
> > 
> > > Hi all
> > > 
> > > Because of the change in the WildcardURIMatcher to cast the request
> > in
> > > the objectModel to org.apache.cocoon.environment.http.HttpRequest
> > > instead of javax.servlet.http.HttpServletRequest the CLI part isn't
> > > working anymore. I've tried to fix the ClassCastException when
> > running
> > > under Tomcat-4 but with no success. Could it be that the
> > > RepositoryClassloader cause that problem? Is anybody here expert
> > > concerning ClassLoader issues?
> > 
> > I definitely don't consider myself an expert on this.  I do have a
> > question, though.  If we are being Java 2 compliant, why not use
> > a known, tested, and debugged ClassLoader like URLClassLoader.  You
> > can dynamically add jars or paths as URL objects.  It would probably
> > be allot easier to maintain--because someone else is taking care of
> > those details.
> 
> I'm absolutely fine with this.
> 
> > I have been messing with the RepositoryClassLoader adding in logging
> > and such to try and locate where the Sitemap is failing to load on
> > my install of Cocoon on IBM WebSphere.  I found out it is not failing
> > in the RepositoryClassLoader, and it is a mystery where it is
> > failing.
> 
> The fact that the cast from the objectModels request object to the
> servlets request type in the generated code from the
> WildcardURIMatcherFactory *was* working some time ago made me think
> that it can only be a problem with class loading and thus the only
> classloader we have is (IIRC) the RepositoryClassLoader (beside the
> ClassUtils). I'm as you no expert in classloading stuff. I've seen in
> the logs (many thanks again to you, Berin, realizing it) that there are
> many notes that classes couldn't be loaded "normally" and that they are
> loaded from the repository.  I feel that as long as all classes loaded
> by the RepositoryClassloader you are save but as soon as an other
> object steps in (HttpServletRequest in this case) you're in trouble. 
> 
> So, to make CLI working again (an this is IMHO important) we need to
> change something on the class loading strategy. I'm not familiar with
> the code around the RepositoryClassloader but if nobody else can look
> at it and change it using the URLClassLoader I'll step in and see what
> I can do.

Oh yeah!  I almost forgot: if the RepositoryClassManager is not a child
classloader (i.e. has a parent classloader) then objects created by the
RepositoryClassManager cannot resolve against objects created in the
other class manager.  To illustrate:

ClassLoader A is parent of ClassLoader B.
ClassLoader C is standalone.

If ServletRequest is instantiated by ClassLoader A,
then ClassLoader B can do Class Casting against it.
ClassLoader C cannot because Java thinks that they
are different types--even if ClassLoader C has those
classes in it's classpath!

In our world:
If RepositoryClassLoader is all by itself, then it
cannot Cast a HttpServletRequest object created by
the servlet engine--even if it has the interface in
it's classpath.

The proper way for RepositoryClassLoader to operate
is to try to resolve the class in its loaded classes.
If it can't, it checks the ParentClassLoader.  If the
ParentClassLoader can't resolve it, then the
RepositoryClassLoader needs to check the filesystem.

ASCII version of Sequence Diagram:

User            RCL              PCL
 +-------------->|                |
 | Load class    +-|              |
 |               | | Check loaded |
 |               +<| Classes      |
 |               |                |
 |               +--------------->+ Check parent
 |               |                |
 |               +-|              |
 |               | | Check        |
 | Class loaded  +<| Repository   |
 +<--------------|                |

User is the object doing a Class.forName() or equiv.
RCL is the RepositoryClassLoader
PCL is the Parent ClassLoader


Mime
View raw message