cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: ServletConfig.getRealPath
Date Mon, 21 Jan 2002 13:56:26 GMT
On Mon, 2002-01-21 at 06:42, Stefano Mazzocchi wrote:

> 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.
yes.  NO log in the work directory.

> 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.

+1 - At the places I typically contract this is one of the reasons they
often use "WebSphere" (which I can do, but its not my favorite). 
Anything that ties you down to one spot on one server should be avoided.

> > 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 I'm not mistaking I think getRealPath is deprecated everywhere
anyhow.  Or at least significantly frowned upon and scorned by all.

> > 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.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:
-- - port of Excel format to java 
			- fix java generics!

The avalanche has already started. It is too late for the pebbles to
-Ambassador Kosh

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

View raw message