Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Piroumian, Konstantin" <KPiroumian@flagship.ru>
To: cocoon-dev@xml.apache.org
Message-ID: <02d001c1a264$67e58950$6150000a@flagship.ru>
References: <AB72DC50CB6AD3119A6A00902798A0220145B1B0@EXCHANGE>
Subject: Re: ServletConfig.getRealPath
Date: Mon, 21 Jan 2002 13:14:26 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: 7bit

The main problem with getRealPath() is its usage in CocoonServlet.java. It's
used there to construct the classpath depending on the /WEB-INF/lib and
classes files. IMO, this is a very wrong approach, cause Servlet
Specification (at least 2.3) describes how a webapp classloader should
behave and how to specify dependent classes in MANIFEST files. Overriding
these rules causes incompatibilities.

We are deploying our EAR application to WebLogic 6.1sp2 with a lot of
dependencies using Manifest files for that and everything (with minor
issues) work as expected.

Regards,
    Konstantin Piroumian

----- Original Message -----
From: "shenoy, nitin" <nshenoy@telegea.com>
To: <cocoon-dev@xml.apache.org>
Sent: Sunday, January 20, 2002 8:23 PM
Subject: RE: ServletConfig.getRealPath


> 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:sylvain.wallez@anyware-tech.com]
> Sent: Sunday, January 20, 2002 4:58 AM
> To: cocoon-dev@xml.apache.org
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org