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:[EMAIL PROTECTED]] Sent: Sunday, January 20, 2002 4:58 AM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
