Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B146AD0.E7C280AA@apache.org>
Date: Tue, 29 May 2001 23:36:48 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Context:// issue
References: <Pine.LNX.4.33L2.0105290302190.1556-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Donald Ball wrote:
> 
> On Tue, 29 May 2001, giacomo wrote:
> 
> > > > The context and resource protocols should match the semantics for
> > > > file and jar:
> > > >
> > > > context://relative/path/from/context/root
> > > > resource://path/to/packaged/resource
> > >
> > > why don't we go ahead and enumerate all of the extra protocols recognized
> > > by c2 and their semantics, and stick them in a document for reference.
> > > i'll take a stab:
> > >
> > > context urls point to xml resource pipelines relative to the root of the
> > > current sitemap. the same context url in two seperate sitemaps can resolve
> > > to two seperate pipelines. format: context://{path}
> >
> > The context protocol point into the file system and not to resource
> > pipeline. But yes, the same context url in two seperate sitemaps can
> > resolve to two seperate files. format: context://{path}
> 
> and it's always relative to the location of the current sitemap's map
> file?

I could have sworn it was the same as the Servlet spec's definition of
a context relative path.  That way the file in question is easily
predictable.
A well behaved servlet will only serve files in it's context.  All paths
should be relative to the context root.

> 
> > > cocoon urls point to xml resource pipelines relative to the root of the
> > > current webapp. the same cocoon url in two seperate sitemaps always
> > > resolves to the same resource pipeline. format: cocoon://{path}.
> >
> > Not sure here. As your first isn't how you thought which one is relative
> > to the current sitemap and wich one is not. As this protocol is not
> > implemented yet we can model it in the way we like it.
> 
> what is it's intended purpose then? if it's _not_ what i've described,
> i think we need to add something to do what i've described - maybe the
> webapp:// protocol?

I thought the purpose of a Cocoon protocol was to get at sitemap
resources
like the CIncludeSAXConnector did.  I could be wrong though...

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