You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Colin Britton <cb...@centervilletech.com> on 2001/05/25 17:11:03 UTC
Context:// issue
We are loading our logicsheets in with the context:// uri.
The following error occurs:
If I put <parameter name="href"
value="context://WEB-INF/my-logicsheet.xsl"/> in I get an error as it is
trying to access to file
d:\xml_technology\tomcat-4.0\webapps\cocoonWEB-INF\my-logicsheet.xsl
If I add another slash to the url at the beginning it is ok (for
instance context:///WEB-INF/my-logicsheet.xsl)
Is this correct behavior?
rgds
CB
===============================
Colin Britton
Centerville Technologies
275 Wyman Street, Waltham MA 02451, USA
http://www.centervilletech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Xerces 1.4.0 released
Posted by giacomo <gi...@apache.org>.
On Fri, 25 May 2001, Piroumian, Konstantin wrote:
> Hi!
>
> Did anybody try to run C2 with Xerces 1.4.0?
I've havn't encountered any problems yet. Will commit a version soon.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Xerces 1.4.0 released
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Hi!
Did anybody try to run C2 with Xerces 1.4.0?
Regards,
Konstantin Piroumian.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by giacomo <gi...@apache.org>.
On Wed, 30 May 2001, Donald Ball wrote:
> On Tue, 29 May 2001, Berin Loritsch wrote:
>
> > If it doesn't resolve to to the root of the servlet context, then the
> > protocol shouldn't be called "context". By making things sitemap
> > relative, you are diluting the concepts of the Servlet spec. You are
> > also increasing (IMO unnecessarily) the learning time required to
> > understand Cocoon.
>
> _thank you_. i thought i was the only one confused by this! this
> underscores the need for documentation.
>
> > The "context" protocol _should_ be relative to the servlet _Context_.
> > Any other approach requires a different protocol name. I am not
> > saying that sitemap relative is not a valid approach--I am saying that
> > "context" is not a valid name for that approach.
>
> so how about this - context:// resolves to the root of the webapp,
> sitemap:// resolves to the root of the current sitemap. cocoon:// doesn't
> exist. sound good? or should we leave the confusing context:// behind us
> entirely and use webapp:// and sitemap://?
You're all right. The context:// protocol should resolve to the
environment (servlet mostly) context root. I meant that urls NOT
having a protocol specified were meant to resolve at the current sitemap
root. This was the meaning of the EntityResolver represented by a
concrete Environment implementation.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 29 May 2001, Berin Loritsch wrote:
> If it doesn't resolve to to the root of the servlet context, then the
> protocol shouldn't be called "context". By making things sitemap
> relative, you are diluting the concepts of the Servlet spec. You are
> also increasing (IMO unnecessarily) the learning time required to
> understand Cocoon.
_thank you_. i thought i was the only one confused by this! this
underscores the need for documentation.
> The "context" protocol _should_ be relative to the servlet _Context_.
> Any other approach requires a different protocol name. I am not
> saying that sitemap relative is not a valid approach--I am saying that
> "context" is not a valid name for that approach.
so how about this - context:// resolves to the root of the webapp,
sitemap:// resolves to the root of the current sitemap. cocoon:// doesn't
exist. sound good? or should we leave the confusing context:// behind us
entirely and use webapp:// and sitemap://?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Quoting Donald Ball <ba...@webslingerZ.com>:
>
> > 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?
>
> Sorry, yes, it's how it should be but am not sure if the implementation respects
> this (IIRC it always resolves to the root of the servlet context). The early
> design decision was that the EntityResolver represented by the Environment
> object should take care of this but recent changes has deluted that approach.
> That's why the Environment interface has methods like setPrefix etc. to make it
> able to resolve correctly in case of sub sitemap mounts. I'm unsettle if
> I should fighting for old design decision because I don't remember exactly why
> this or that decision has been taken and it can truly be that I'm wrong today,
> so, do what you think is correct here.
If it doesn't resolve to to the root of the servlet context, then the
protocol
shouldn't be called "context". By making things sitemap relative, you
are
diluting the concepts of the Servlet spec. You are also increasing (IMO
unnecessarily) the learning time required to understand Cocoon.
The "context" protocol _should_ be relative to the servlet _Context_.
Any other
approach requires a different protocol name. I am not saying that
sitemap relative
is not a valid approach--I am saying that "context" is not a valid name
for that
approach.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by Santiago Gala <sg...@hisitech.com>.
Giacomo Pati wrote:
> Quoting Donald Ball <ba...@webslingerZ.com>:
>
>
>>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?
>>
>
> Sorry, yes, it's how it should be but am not sure if the implementation respects
> this (IIRC it always resolves to the root of the servlet context). The early
> design decision was that the EntityResolver represented by the Environment
> object should take care of this but recent changes has deluted that approach.
> That's why the Environment interface has methods like setPrefix etc. to make it
> able to resolve correctly in case of sub sitemap mounts. I'm unsettle if
> I should fighting for old design decision because I don't remember exactly why
> this or that decision has been taken and it can truly be that I'm wrong today,
> so, do what you think is correct here.
>
>
>>>>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?
>>
>
> The main problem is that all custom protocol served by the URLFactory so far
> resolve into a byte stream but the special cocoon:// protocol should resolve
> into a SAX stream for performance reasons. If you find a common interface for
> the URLFactory which combines both worlds your a real smart guy :)
>
XMLByteStream as could be produced by XMLByteStreamCompiler if slightly
modified to deliver a ByteStream could do. On the other side of the url,
of course, a slightly modified XMLByteStreamInterpreter should be used.
While it has a slight performance cost, it would keep ByteStreams in
protocols and allow remote connections (so don't drop the host:port part
yet). I have versions of those classes that do precisely this, and also
correct a very unlikely bug I found there.
Did I earned something? I had to bend myself quite a lot to see it.
> Giacomo
>
> ---------------------------------------------------------------------
> 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
AW: Context:// issue
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
>
> On Tue, 29 May 2001, Carsten Ziegeler wrote:
>
> > > Giacomo Pati wrote:
> > >
> > > Quoting Donald Ball <ba...@webslingerZ.com>:
> > >
> > > > 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?
> > >
> > > Sorry, yes, it's how it should be but am not sure if the
> > > implementation respects
> > > this (IIRC it always resolves to the root of the servlet
> > > context). The early
> > > design decision was that the EntityResolver represented by the
> > > Environment
> > > object should take care of this but recent changes has deluted
> > > that approach.
> > > That's why the Environment interface has methods like setPrefix
> > > etc. to make it
> > > able to resolve correctly in case of sub sitemap mounts. I'm
> unsettle if
> > > I should fighting for old design decision because I don't
> > > remember exactly why
> > > this or that decision has been taken and it can truly be that I'm
> > > wrong today,
> > > so, do what you think is correct here.
> > >
> > > > > > 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?
> > >
> > > The main problem is that all custom protocol served by the
> > > URLFactory so far
> > > resolve into a byte stream but the special cocoon:// protocol
> > > should resolve
> > > into a SAX stream for performance reasons. If you find a common
> > > interface for
> > > the URLFactory which combines both worlds your a real smart guy :)
> > >
> > Hm, I will not stop you from trying to do so, but I think it is nearly
> > impossible without changing the result of the URLFactory.
> > Currently it returns an URL which is not usable for that approach.
>
> That's true. We'll have to subclass the returned URL from the URLFactory
> and extend that URL with methods like setContentHandler or have other
> methods for the URLFactory like
>
> getURL(URL base, String location, XMLConsumer consumer)
>
> but there is still the issue how it gets to a sitemap to handle
> cocoon:// protocol.
>
> > That is one of the reasons for the introduction of the SourceResolver
> > , the URLResolver and the Source class where it is possible to
> > handle those tasks.
> > My thoughts were:
> > - adding a method to the source object which generates sax events
> > from the source and sends them to a specified XMLConsumer
> > - adding logic to the FactoryURLResolver to handle the cocoon: context.
> > The FactoryURLResolver sits between the SourceResolver and the
> > URLFactory and has access to the current sitemap handler. So it
> > should be possible that this object can resolve the cocoon:
> > urls.
>
> Would extending the URLFactory interface like above solve it?
Not necessarily. The question is: What do we want (today)? Do we want
(only) a working cocoon: url or do we really want a URL object for those
urls?
For the first (simple) solution, the URLFactory could be as it is and
the cocoon: url is not handled by the URLFactory but by the
FactoryURLResolver.
This FactoryURLResolver looks if the url starts with cocoon:. If so it
handles it by itself, otherwise the url is passed on to the URLFactory.
If you want the (more sophisticated) solution - a real URL object -
you are right.
For now, I think, the simple solution is enough (for C2.1).
>
> >
> > So this would mean that the cocoon: urls are handled by a
> > combination of the Source and the FactoryURLResolver class but
> > not by the URLFactory.
> >
> > But these are only vague thoughts for an implementation.
> >
> > The easiest solution is of course to forget about the performance
> > (for a first version). The cocoon: url would then generate
> > a real url which is resolved by a byte stream and this byte
> > stream is reparsed. Easy implementation - bad performance....
>
> Forget that last proposal :(
Ok, ok, just kidding...
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
>
> Giacomo
>
>
> ---------------------------------------------------------------------
> 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
Re: AW: Context:// issue
Posted by giacomo <gi...@apache.org>.
On Tue, 29 May 2001, Carsten Ziegeler wrote:
> > Giacomo Pati wrote:
> >
> > Quoting Donald Ball <ba...@webslingerZ.com>:
> >
> > > 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?
> >
> > Sorry, yes, it's how it should be but am not sure if the
> > implementation respects
> > this (IIRC it always resolves to the root of the servlet
> > context). The early
> > design decision was that the EntityResolver represented by the
> > Environment
> > object should take care of this but recent changes has deluted
> > that approach.
> > That's why the Environment interface has methods like setPrefix
> > etc. to make it
> > able to resolve correctly in case of sub sitemap mounts. I'm unsettle if
> > I should fighting for old design decision because I don't
> > remember exactly why
> > this or that decision has been taken and it can truly be that I'm
> > wrong today,
> > so, do what you think is correct here.
> >
> > > > > 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?
> >
> > The main problem is that all custom protocol served by the
> > URLFactory so far
> > resolve into a byte stream but the special cocoon:// protocol
> > should resolve
> > into a SAX stream for performance reasons. If you find a common
> > interface for
> > the URLFactory which combines both worlds your a real smart guy :)
> >
> Hm, I will not stop you from trying to do so, but I think it is nearly
> impossible without changing the result of the URLFactory.
> Currently it returns an URL which is not usable for that approach.
That's true. We'll have to subclass the returned URL from the URLFactory
and extend that URL with methods like setContentHandler or have other
methods for the URLFactory like
getURL(URL base, String location, XMLConsumer consumer)
but there is still the issue how it gets to a sitemap to handle
cocoon:// protocol.
> That is one of the reasons for the introduction of the SourceResolver
> , the URLResolver and the Source class where it is possible to
> handle those tasks.
> My thoughts were:
> - adding a method to the source object which generates sax events
> from the source and sends them to a specified XMLConsumer
> - adding logic to the FactoryURLResolver to handle the cocoon: context.
> The FactoryURLResolver sits between the SourceResolver and the
> URLFactory and has access to the current sitemap handler. So it
> should be possible that this object can resolve the cocoon:
> urls.
Would extending the URLFactory interface like above solve it?
>
> So this would mean that the cocoon: urls are handled by a
> combination of the Source and the FactoryURLResolver class but
> not by the URLFactory.
>
> But these are only vague thoughts for an implementation.
>
> The easiest solution is of course to forget about the performance
> (for a first version). The cocoon: url would then generate
> a real url which is resolved by a byte stream and this byte
> stream is reparsed. Easy implementation - bad performance....
Forget that last proposal :(
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: Context:// issue
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
>
> Quoting Donald Ball <ba...@webslingerZ.com>:
>
> > 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?
>
> Sorry, yes, it's how it should be but am not sure if the
> implementation respects
> this (IIRC it always resolves to the root of the servlet
> context). The early
> design decision was that the EntityResolver represented by the
> Environment
> object should take care of this but recent changes has deluted
> that approach.
> That's why the Environment interface has methods like setPrefix
> etc. to make it
> able to resolve correctly in case of sub sitemap mounts. I'm unsettle if
> I should fighting for old design decision because I don't
> remember exactly why
> this or that decision has been taken and it can truly be that I'm
> wrong today,
> so, do what you think is correct here.
>
> > > > 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?
>
> The main problem is that all custom protocol served by the
> URLFactory so far
> resolve into a byte stream but the special cocoon:// protocol
> should resolve
> into a SAX stream for performance reasons. If you find a common
> interface for
> the URLFactory which combines both worlds your a real smart guy :)
>
Hm, I will not stop you from trying to do so, but I think it is nearly
impossible without changing the result of the URLFactory.
Currently it returns an URL which is not usable for that approach.
That is one of the reasons for the introduction of the SourceResolver
, the URLResolver and the Source class where it is possible to
handle those tasks.
My thoughts were:
- adding a method to the source object which generates sax events
from the source and sends them to a specified XMLConsumer
- adding logic to the FactoryURLResolver to handle the cocoon: context.
The FactoryURLResolver sits between the SourceResolver and the
URLFactory and has access to the current sitemap handler. So it
should be possible that this object can resolve the cocoon:
urls.
So this would mean that the cocoon: urls are handled by a
combination of the Source and the FactoryURLResolver class but
not by the URLFactory.
But these are only vague thoughts for an implementation.
The easiest solution is of course to forget about the performance
(for a first version). The cocoon: url would then generate
a real url which is resolved by a byte stream and this byte
stream is reparsed. Easy implementation - bad performance....
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> Giacomo
>
> ---------------------------------------------------------------------
> 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
Re: Context:// issue
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Donald Ball <ba...@webslingerZ.com>:
> 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?
Sorry, yes, it's how it should be but am not sure if the implementation respects
this (IIRC it always resolves to the root of the servlet context). The early
design decision was that the EntityResolver represented by the Environment
object should take care of this but recent changes has deluted that approach.
That's why the Environment interface has methods like setPrefix etc. to make it
able to resolve correctly in case of sub sitemap mounts. I'm unsettle if
I should fighting for old design decision because I don't remember exactly why
this or that decision has been taken and it can truly be that I'm wrong today,
so, do what you think is correct here.
> > > 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?
The main problem is that all custom protocol served by the URLFactory so far
resolve into a byte stream but the special cocoon:// protocol should resolve
into a SAX stream for performance reasons. If you find a common interface for
the URLFactory which combines both worlds your a real smart guy :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: Context:// issue
Posted by Donald Ball <ba...@webslingerZ.com>.
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?
> > 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?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by giacomo <gi...@apache.org>.
On Tue, 29 May 2001, Donald Ball wrote:
> On Sun, 27 May 2001, Berin Loritsch 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}
> 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.
> resouce urls point to binary resources that are accessible via the jvm
> classloader. typically, these are data files included in a jar file.
> format: resource://{path}.
Yup
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 27 May 2001, Berin Loritsch 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}
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}.
resouce urls point to binary resources that are accessible via the jvm
classloader. typically, these are data files included in a jar file.
format: resource://{path}.
is this correct?
is this as we would like it to be?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Sat, 26 May 2001, Donald Ball wrote:
>
> > On Fri, 25 May 2001, giacomo wrote:
> >
> > > > We are loading our logicsheets in with the context:// uri.
> > > >
> > > > The following error occurs:
> > > >
> > > > If I put <parameter name="href"
> > > > value="context://WEB-INF/my-logicsheet.xsl"/> in I get an error as it is
> > > > trying to access to file
> > > > d:\xml_technology\tomcat-4.0\webapps\cocoonWEB-INF\my-logicsheet.xsl
> > > >
> > > > If I add another slash to the url at the beginning it is ok (for
> > > > instance context:///WEB-INF/my-logicsheet.xsl)
> > > >
> > > > Is this correct behavior?
> > >
> > > I've had the same experience.
> >
> > i have as well. i would venture to say that no, this is not correct
> > behavior. i think it was introduced with the urlresolver cleanup.
>
> Not so sure. I had to use that syntax in the builtin-logicsheets since
> months. Is there anybody familiar with the right URL syntax. AFAIR it's
> protocol://host:port/path where the host:port part may be left and thus
> protocol:///path is for localhost.
The general pattern is "protocol://host:port/path"; however, with the
context and resource protocol, the host:port section is implied (just
like with the file and jar protocols).
The context and resource protocols should match the semantics for
file and jar:
context://relative/path/from/context/root
resource://path/to/packaged/resource
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by giacomo <gi...@apache.org>.
On Sat, 26 May 2001, Donald Ball wrote:
> On Fri, 25 May 2001, giacomo wrote:
>
> > > We are loading our logicsheets in with the context:// uri.
> > >
> > > The following error occurs:
> > >
> > > If I put <parameter name="href"
> > > value="context://WEB-INF/my-logicsheet.xsl"/> in I get an error as it is
> > > trying to access to file
> > > d:\xml_technology\tomcat-4.0\webapps\cocoonWEB-INF\my-logicsheet.xsl
> > >
> > > If I add another slash to the url at the beginning it is ok (for
> > > instance context:///WEB-INF/my-logicsheet.xsl)
> > >
> > > Is this correct behavior?
> >
> > I've had the same experience.
>
> i have as well. i would venture to say that no, this is not correct
> behavior. i think it was introduced with the urlresolver cleanup.
Not so sure. I had to use that syntax in the builtin-logicsheets since
months. Is there anybody familiar with the right URL syntax. AFAIR it's
protocol://host:port/path where the host:port part may be left and thus
protocol:///path is for localhost.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 25 May 2001, giacomo wrote:
> > We are loading our logicsheets in with the context:// uri.
> >
> > The following error occurs:
> >
> > If I put <parameter name="href"
> > value="context://WEB-INF/my-logicsheet.xsl"/> in I get an error as it is
> > trying to access to file
> > d:\xml_technology\tomcat-4.0\webapps\cocoonWEB-INF\my-logicsheet.xsl
> >
> > If I add another slash to the url at the beginning it is ok (for
> > instance context:///WEB-INF/my-logicsheet.xsl)
> >
> > Is this correct behavior?
>
> I've had the same experience.
i have as well. i would venture to say that no, this is not correct
behavior. i think it was introduced with the urlresolver cleanup.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Context:// issue
Posted by giacomo <gi...@apache.org>.
On Fri, 25 May 2001, Colin Britton wrote:
>
> We are loading our logicsheets in with the context:// uri.
>
> The following error occurs:
>
> If I put <parameter name="href"
> value="context://WEB-INF/my-logicsheet.xsl"/> in I get an error as it is
> trying to access to file
> d:\xml_technology\tomcat-4.0\webapps\cocoonWEB-INF\my-logicsheet.xsl
>
> If I add another slash to the url at the beginning it is ok (for
> instance context:///WEB-INF/my-logicsheet.xsl)
>
> Is this correct behavior?
I've had the same experience.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org