"shenoy, nitin" wrote:
>
> 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.
Same here.
> 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.
Sounds good to me.
> Please let me know if the proposed solution makes sense.
I think it does.
At the same time, I don't think there should be 'at least' the
possibility to log on the servlet container log stream instead that on
our own output file.
But I don't if LogKit it capable of doing this without serious
performance penalties.
Placing an important file such as the log in the 'work' directory which
is normally considered 'temporary' (catalina used to remove it at
shutdown!) could probably lead to very dangerous and annoying
situations.
At the same time, the servlet log stream was not designed with a huge
servlet operating as a subcontainer, but I do see in some cases the need
for having Cocoon logging into the container so that servlet hosters can
centralize log maintenance.
What do you think?
> 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?
Oh, that is a *very* important question, indeed!
The answer is: no proposal has been made so far (AFAIK) and was left to
the craftmanship of the single user.
I would be in *total* favor of something more industrialized and
architected, even if I don't know who's concer is this, if Cocoon's or
the servlet container's.
> Read only resources
> (such as config files) can be handled easily through getResource or
> getResourceAsStream.
yes. here is the container's concern.
>
> 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.
HSQL should be considered a library used by the cocoon 'samples' and the
files should be removed from /WEB-INF/ since it seems that Cocoon makes
use of HSQL internally (which is NOT and will never be the case!)
For logging, I think that Cocoon should not attempt to provide
centralization of logging, it's not its concern.
This is why I'd like to have the ability to log into the servlet
container directly: if they provide transparent clustering they will
very likely provide transparent log centralization (probably
asynchronously for better system performance).
> 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.
I think this needs deeper thought about webapp componentization... I'll
write my email on that shortly after.
> 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.
Absolutely.
The pattern to follow is simple: if Cocoon acts as a servlet, gets all
the benefits of servlets.
So, for dynamic web operation, let's try to behave as a servlet as much
as possible and delegate to the servlet container all those concerns
that we should not care about (SoC even here where the Servlet API is
our contract!)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
