Return-Path: 
 <cocoon-dev-return-18235-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 20248 invoked by uid 500); 31 Oct 2001 09:27:41 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 20224 invoked from network); 31 Oct 2001 09:27:40 -0000
From: "Piroumian, Konstantin" <KPiroumian@flagship.ru>
To: cocoon-dev@xml.apache.org
Message-ID: <005c01c161ee$5522a890$9d0a000a@flagship.ru>
References: <1fc29a202b62.202b621fc29a@i-one.at>
Subject: Re: RE: [C2.0] Source resolution in servlet container
Date: Wed, 31 Oct 2001 12:27:59 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> hi,
> i think there is no official way to scan a directory.
> btw why does cocoon needs to load the jars from
> WEB-INF/lib?
> I think that's the task of the servlet-engine to load
> the jars residing in /WEB-INF/lib, and to load classes
> residing in /WEB-INF/classes (sub)directories.

Yes. Another solution can using a manifest.mf file with Class-Path param in
it, then servlet container will use that class path for the application
(Cocoon).

Regards,
    Konstantin Piroumian

> bye
>
> ----- Originalnachricht -----
> Von: "Carsten Ziegeler" <cziegeler@s-und-n.de>
> Datum: Dienstag, Oktober 30, 2001 3:45 pm
> Betreff: RE: [C2.0] Source resolution in servlet container
>
> > Hi,
> >
> > I just started to remove the getRealPath() calls from at least the
> > CocoonServlet in the 2.1 branch.
> > But we have one problem with this approach: Cocoon scans on
> > startup the WEB-INF/lib directory for jar files and builds
> > the class-path from this. Now I see no possibility to scan
> > the directory if the war file is not unpacked. Or is there
> > any chance?
> >
> > Carsten
> >
> >
> > > -----Original Message-----
> > > From: Piroumian, Konstantin [mailto:KPiroumian@flagship.ru]
> > > Sent: Friday, October 26, 2001 2:10 PM
> > > To: cocoon-dev@xml.apache.org
> > > Subject: [C2.0] Source resolution in servlet container
> > >
> > >
> > > Hi, C2ers!
> > >
> > > According to Servlet 2.2 specification (paragraph 4.4):
> > > <quot>
> > > The ServletContext interface allows direct access to the static
> > document> hierarchy of content
> > > documents, such as HTML, GIF, and JPEG files, that are part of
> > the web
> > > application via the
> > > following methods of the ServletContext interface:
> > > . getResource
> > > . getResourceAsStream
> > > </quot>
> > >
> > > then:
> > > <quot>
> > > It is important to note that these methods give access to static
> > resources> from whatever repository
> > > the server uses. This hierarchy of documents may exist in a file
> > > system, in
> > > a web application archive
> > > file, on a remote server, or some other location.
> > > </quot>
> > >
> > > So, from this I can conclude that any other access to static
> > resources is
> > > not required to be supported. As I can see from the
> > CocoonServlet.java> source, it uses calls like this in many places:
> > >
> > > final FileInputStream fis = new
> > > FileInputStream(this.servletContext.getRealPath("/") +
> > logkitConfig);>
> > > This results in problems with servlet containers (or deployments)
> > > that does
> > > not extract files from WAR-archive and therefore the real path is
> > > undefined
> > > (is 'null') and CocoonServlet dies during initialization with NPE.
> > >
> > > Correct me if I am worng, but to be able to use Cocoon on any
> > > servlet engine
> > > that supports Servlet 2.2 specification several rules must be
> > followed in
> > > Cocoon architecture (this must be adapted for CLI):
> > > . any access to static resources of the Web application, including
> > > xsp/xml/xsl files, must be performed by getResource() and
> > > getResourceAsStream methods
> > > . any calls to other servlets must be performed by
> > > RequestDispatcher.include() methods (e.g. JspServlet)
> > > . use working (temporary) directory for any 'write' operations (e.g.
> > > logging)
> > > something else?
> > >
> > > Are there any comments on this? Will C2.0 be fixed (at least
> > getRealPath()> issue) before releasing?
> > >
> > > Best regards,
> > >
> > > Konstantin Piroumian
> > > Sr. Software engineer
> > >
> > > Protek Flagship LLC
> > > Phone: + 7 095 795 0520 (add. 1288)
> > > Fax: + 7 095 795 0525
> > > E-mail: kpiroumian@flagship.ru
> > > http://www.protek.com
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----------------------------------------------------------------
> > ----
> > > 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

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