Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 15610 invoked from network); 15 Dec 2000 13:51:36 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by locus.apache.org with SMTP; 15 Dec 2000 13:51:36 -0000 Received: (qmail 31548 invoked from network); 15 Dec 2000 13:53:09 -0000 Received: from unknown (HELO johnnybravo) (192.168.0.189) by inet with SMTP; 15 Dec 2000 13:53:09 -0000 Message-ID: <009901c0669d$e1098510$bd00a8c0@infoplanning.com> From: "Berin Loritsch" To: , References: <20001215084038.14581.qmail@web6203.mail.yahoo.com> Subject: Re: [TC4] ClassCastException with HttpServletrequestWrapper Date: Fri, 15 Dec 2000 08:49:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Giacomo Pati" To: Sent: Friday, December 15, 2000 3:40 AM Subject: Re: [TC4] ClassCastException with HttpServletrequestWrapper > > --- Berin Loritsch wrote: > > > > ----- Original Message ----- > > From: "Giacomo Pati" > > To: "Cocoon dev" > > Sent: Wednesday, December 13, 2000 6:07 PM > > Subject: [TC4] ClassCastException with HttpServletrequestWrapper > > > > > > > Hi all > > > > > 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. Actually this is part of normal operations. The ClassLoader tries to load the class internally, if it fails (an exception is caught) then it will load the class from the repository. If that was successful, the next log entry should be the number of bytes loaded from the repository.