Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <AB72DC50CB6AD3119A6A00902798A0220145B1B1@EXCHANGE>
From: "shenoy, nitin" <nshenoy@telegea.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: ServletConfig.getRealPath
Date: Sun, 20 Jan 2002 12:30:37 -0500
MIME-Version: 1.0
Content-Type: text/plain

I read my own email and seems like I used the word "propose" quite a few
times :) 

-----Original Message-----
From: shenoy, nitin [mailto:nshenoy@telegea.com]
Sent: Sunday, January 20, 2002 12:23 PM
To: 'cocoon-dev@xml.apache.org'
Subject: RE: ServletConfig.getRealPath


Thanks for the inputs and the explanations make sense to me. So heres my
first pass at trying to come up with solution.

Sylvain put classes that use getRealPath in 4 buckets 

1 - classes that *need* a File,
2 - classes that could do equally well with getResource() and need some 
polishing :)
3 - classes that prefer a File, but fall back to a raw URL,
4 - wrappers, that just forward calls.

and pointed out that the main issue is writing to WEB-INF. I agree with all
of the above. I propose making the paths that are currently relative to the
context root of the servlet to use the work directory in the web.xml. I
propose using getResource instead of getRealPath and will send out the
proposed code change snippets for approval too.

Please let me know if the proposed solution makes sense.

I wanna bring up one more design issue and it may be irrelevant in the
context of Cocoon.

How does Cocoon propose to handle Clustered deployments and Read-Write usage
of resources from within an archive in such scenarios? Read only resources
(such as config files) can be handled easily through getResource or
getResourceAsStream.

Read-Write resources IMO fall into two categories

1) Centralized R/W resources
2) Distributed R/W resources

I am unsure whether the Logger and HSQL fall under category 1 or 2 above.

If most of Cocoon's R/W resources fall in Category 2 there will be no
changes required. Even if those resources fall into the 1st category, simple
resources like Loggers can be adapted by adding a remote logger in the
logkit.conf and changing the log target. With HSQL, I am not sure of how and
why its being used. But, the solution could be a simple addition of a few
configuration settings in the web.xml for HSQL.

Please educate me on the above and let me know if I am off base in my
thinking. In most commercial deployments that I have been involved in,
clustering was a pre-requisite and usually, small and seeming innocuous
design decisions could end up breaking an otherwise stable system.

Regards,
Nitin


-----Original Message-----
From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
Sent: Sunday, January 20, 2002 4:58 AM
To: cocoon-dev@xml.apache.org
Subject: Re: ServletConfig.getRealPath


shenoy, nitin wrote:

>Hi Folks,
>
>I think Cocoon is a very powerful framework and I respect all the hard work
>and effort that has gone into the making of Cocoon.
>
>Now for my question :)
>
>Is the decision to use ServletConfig.getRealPath in cocoon a good design
>decision? From the Servlet 2.2 spec ..... "when the web application is
>executed from an archive, on a remote file system not accessible locally,
or
>in a database, these methods must return null."
>
>BEA Weblogic returns null in a War file format (as most of you folks are
>probably aware already) and a ton of Cocoon users are screaming all over
the
>place about not being able to deploy Cocoon in a war format.
>
>I wanna volunteer to try and fix (or is adapt the right word?) Cocoon so
>that it works in war format (only 13 files use the getRealPath method)
under
>weblogic but I also think I can do a better job if I understand the
>perspective correctly.
>
Cool ! Here are some inputs, then. There are 4 categories of classes 
that call getRealPath :
1 - classes that *need* a File,
2 - classes that could do equally well with getResource() and need some 
polishing :)
3 - classes that prefer a File, but fall back to a raw URL,
4 - wrappers, that just forward calls.

Only categories 1 & 2 should need some work.

In category 1, you'll mainly find HSQL and LogKit log targets, which 
write some data on disk. For these, the only portable solution I see is 
to use the work directory rather than WEB-INF.

Category 2 has been considered and corrected a few months ago, but some 
new classes added since then may need that polishing.

>
>Please do bear with me if the above topic is a non issue, but I do see a
lot
>of postings on the Cocoon users list and the BEA weblogic list.
>
The main issue is using WEB-INF to write data.

Sylvain


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org