Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <20001215084038.14581.qmail@web6203.mail.yahoo.com>
Date: Fri, 15 Dec 2000 00:40:38 -0800 (PST)
From: Giacomo Pati <pati_giacomo@yahoo.com>
Reply-To: giacomo@apache.org
Subject: Re: [TC4] ClassCastException with HttpServletrequestWrapper
To: cocoon-dev@xml.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


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

Giacomo
> 


=====


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/