cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "shenoy, nitin" <>
Subject RE: ServletConfig.getRealPath
Date Sun, 20 Jan 2002 17:23:11 GMT
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

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.


-----Original Message-----
From: Sylvain Wallez []
Sent: Sunday, January 20, 2002 4:58 AM
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,
>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
>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)
>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
>of postings on the Cocoon users list and the BEA weblogic list.
The main issue is using WEB-INF to write data.


To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message