Return-Path: Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 69954 invoked from network); 11 May 2000 02:41:38 -0000 Received: from mail.ozonline.com.au (HELO budapest.ozonline.com.au) (203.4.248.45) by locus.apache.org with SMTP; 11 May 2000 02:41:38 -0000 Received: from aegis (melb-pool-158-251.ozonline.com.au [203.23.158.251]) by budapest.ozonline.com.au (8.8.7/8.8.7) with SMTP id MAA01774 for ; Thu, 11 May 2000 12:41:03 +1000 Message-ID: <01a601bfbaf2$db751a80$fb9e17cb@webcybernetics.com> Reply-To: "Rob Parker" From: "Rob Parker" To: References: Subject: Re: 1.7.3 with JRun 2.3.3 Specific Problem Date: Thu, 11 May 2000 12:44:08 +1000 Organization: Web Cybernetics 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N I get a similar problem using resin 1.1 I had to change the resin config file to use a 'webb-app id' just to get cocoon initialised. However once initialised, cocoon broke when trying to process a request. The problem occurs in the Utils.getBaseName(...) method. This method gets called from XSPUtils.relativeFilename(...) method. This method calls 'return relativeFilename(filename, request, null);' Hence a null context is passed to Utils.getBaseName(). This is turn causes a null pointer exception. Now I haven't traced through this area in great detail - but my quick fix was to use the deprecated 2.1 API request.getRealPath(...) rather than context.getRealPath() in the Utils.getBaseName(...) method. regards Rob ----- Original Message ----- From: Paul Lamb To: Sent: Thursday, May 11, 2000 1:33 AM Subject: RE: 1.7.3 with JRun 2.3.3 Specific Problem > As the person who sent in the patches for using getResource() to get the > cocoon.properties file, I had originally done it in a way that didn't break > existing explicit file paths. Stefano simplified and streamlined my approach > resulting in the code in 1.7.3. I highly prefer the way he did it. > > Here's what I suggest, that instead of checking for a 2.1 compatible engine > that we change it to check for a 2.2 compatible engine. That should with > both Tomcat and the latest JRun 3.0 beta. > > Paul Lamb > > > > > > > JRun 2.3.3 does not support ServletContext.getResource(). > > Thus, JRun 2.3.3 > > > users need to modify the Cocoon.java to use file-based > > approach, instead of > > > resource-based, in order for Cocoon-1.7.3 to correctly read in > > > cocoon.properties file. Otherwise, you get "Publishing > > engine could not be > > > initialized." message with exception throwed. > > > > Oh gee, you mean that JRun 2.3.3 indicates itself as a 2.1 compatible > > Servlet Engine and then doesn't support getResource()? > > > > No comment. > > > > > Should we have a choice somehow, without code change? > > > > It's a pain in the ass to maintain a servlet that is portable across > > servlet engines, it's even worse if they "illegally" claim to be > > compliant when they aren't. > > > > What are we supposed to do? check if the servlet engine is JRun and > > disable that? and what about weblogic, servletexec, websphere, > > paperclips and everyone that has servlet hooks? > > > > I'm _really_ frustrated by all this, expecially when we provide Tomcat > > that works on every possible web server, it's stable and, more > > important, it's free and open source. > > > > Anyway, I'm open to suggestions on how to make this work if > > people need > > it. > > > > > While dealing with this problem, another question is why > > "Unable to open > > > resource: ..." message, which is in the inner catch block, > > is not show up? > > > > This is a bug and it was recently fixed in the CVS. > > > > -- > > Stefano Mazzocchi One must still have chaos in oneself to be > > able to give birth to a dancing star. > > Friedrich Nietzsche > > -------------------------------------------------------------------- > > Missed us in Orlando? Make it up with ApacheCON Europe in London! > > ------------------------- http://ApacheCon.Com --------------------- > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org > > For additional commands, e-mail: cocoon-users-help@xml.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org > For additional commands, e-mail: cocoon-users-help@xml.apache.org > >