On Mon, 2002-01-21 at 06:42, Stefano Mazzocchi wrote: <snip/> > > 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! > +1 > 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. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
