You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Conny Krappatsch <co...@smb-tec.com> on 2001/01/30 17:59:41 UTC
[C2]Getting absolute path of component parameter [was: Proposal: URL Protocols]
Would the proposed solve the problem I'm currently having?
I wrote a Component which provides access to a CMS. The CMS needs to be
initalized with a file name. Configuration in cocoon.xconf currently
looks like this:
<component role="org.infozone.prowler.Prowler"
class="org.infozone.ui.cocoon2.ProwlerComponent">
<parameter name="properties"
value="/absolute/path/to/prowler.xproperties"/>
</component>
This works as long as the location of the properties file isn't changed. A
possibility to use a path relative to the web application would be great.
I spent some time digging through Cocoon sources to find a solution, but
without success (at least I learned a lot about C2 architecture and Avalon
:-).
Is there a solution for my problem (can I access the context object from
the components configure method)?
If not, would the proposal below be the solution? (sounds like that) Then
I vote +1000 for it ;-).
thanks for any help,
Conny Krappatsch
On Tue, 30 Jan 2001 10:53:59 -0500
Berin Loritsch <bl...@apache.org> wrote:
> I want to run something by the list regarding the way
> Cocoon uses URLs to get references to files and such.
>
> This _does_ affect both versions, and it refers to the
> naming of the protocols. The way Servlet 2.2+ specifies
> to get files from the WAR file is the context.getResource()
> method. All resources are relative to the context root.
> This is separate and distinct from Classloader Resources.
>
> My proposal is to specify the following Resource protocols:
>
> "resource:" This gets a ClassLoader resource, loaded by
> the Cocoon ClassLoader. This is what it already
> does.
>
> "context:" This gets a Context resource, pulled by the
> Context.getResource() method.
>
> The reason for this proposal is because it will make a Cocoon
> based WAR file more portable. If someone wants to package
> their Logicsheets inside their WAR file, they can always
> reference them by "context:/Relative/path/to/resource.xsl"
> and won't have to rewrite the cocoon.properties and cocoon.xconf
> files for each installation.
>
> In fact, the Producers/Generators should use the "context:"
> methodology to find the files for input into the system.
> That will ensure that they follow the security and architecture
> mechanisms of the Servlet specification.
>
> The only section that would require any file:// urls is the
> XSP architecture.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
______________________________________________________________________
Conny Krappatsch mailto:conny@smb-tec.com
SMB GmbH http://www.smb-tec.com
Re: [C2]Getting absolute path of component parameter [was: Proposal: URL Protocols]
Posted by Conny Krappatsch <co...@smb-tec.com>.
On Tue, 30 Jan 2001 22:45:49 +0100
Giacomo Pati <gi...@apache.org> wrote:
> > Is there a solution for my problem (can I access the context object
> from
> > the components configure method)?
>
> As a workaround for that I've used the NetUtils class.
>
> Giacomo
Great!
I already tried NetUtils yesterday evening, but didn't find the right
trigger.
After your suggestion I tried it again this morning and now it works.
(Must have been blind yesterday!)
Thanks for your help,
CK
--
______________________________________________________________________
Conny Krappatsch mailto:conny@smb-tec.com
SMB GmbH http://www.smb-tec.com
[C2]: Bug in sitemap creation?
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi,
I am just wondering if the following is a bug or a feature...
The generated code for the "error-handler" ends always like this:
if (true)
return pipeline.process (environment);
return false;
So, if an error occurs inside a pipeline, the "error-handler" is invoked
and returns (if nothing "bad" happens) true.
So a call to Cocoon.process(...) always returns true, regardless if the
processing of the resource was successful or not.
Is this a wanted feature? If yes, how can I detect that the "error-handler" was invoked,
whenn I call Cocoon.process(..)?
Carsten
Re: [C2]Getting absolute path of component parameter [was: Proposal: URL
Protocols]
Posted by Giacomo Pati <gi...@apache.org>.
Conny Krappatsch wrote:
>
> Would the proposed solve the problem I'm currently having?
>
> I wrote a Component which provides access to a CMS. The CMS needs to be
> initalized with a file name. Configuration in cocoon.xconf currently
> looks like this:
>
> <component role="org.infozone.prowler.Prowler"
> class="org.infozone.ui.cocoon2.ProwlerComponent">
> <parameter name="properties"
> value="/absolute/path/to/prowler.xproperties"/>
> </component>
>
> This works as long as the location of the properties file isn't changed. A
> possibility to use a path relative to the web application would be great.
> I spent some time digging through Cocoon sources to find a solution, but
> without success (at least I learned a lot about C2 architecture and Avalon
> :-).
>
> Is there a solution for my problem (can I access the context object from
> the components configure method)?
As a workaround for that I've used the NetUtils class.
Giacomo
Re: [C2]Getting absolute path of component parameter [was: Proposal: URL
Protocols]
Posted by Berin Loritsch <bl...@apache.org>.
Conny Krappatsch wrote:
>
> Would the proposed solve the problem I'm currently having?
>
> I wrote a Component which provides access to a CMS. The CMS needs to be
> initalized with a file name. Configuration in cocoon.xconf currently
> looks like this:
>
> <component role="org.infozone.prowler.Prowler"
> class="org.infozone.ui.cocoon2.ProwlerComponent">
> <parameter name="properties"
> value="/absolute/path/to/prowler.xproperties"/>
> </component>
>
> This works as long as the location of the properties file isn't changed. A
> possibility to use a path relative to the web application would be great.
Basically, yes it would.
> Is there a solution for my problem (can I access the context object from
> the components configure method)?
No.
> If not, would the proposal below be the solution? (sounds like that) Then
> I vote +1000 for it ;-).
I will count that as a +1000 then.
>
> thanks for any help,
> Conny Krappatsch
>
> On Tue, 30 Jan 2001 10:53:59 -0500
> Berin Loritsch <bl...@apache.org> wrote:
> > I want to run something by the list regarding the way
> > Cocoon uses URLs to get references to files and such.
> >
> > This _does_ affect both versions, and it refers to the
> > naming of the protocols. The way Servlet 2.2+ specifies
> > to get files from the WAR file is the context.getResource()
> > method. All resources are relative to the context root.
> > This is separate and distinct from Classloader Resources.
> >
> > My proposal is to specify the following Resource protocols:
> >
> > "resource:" This gets a ClassLoader resource, loaded by
> > the Cocoon ClassLoader. This is what it already
> > does.
> >
> > "context:" This gets a Context resource, pulled by the
> > Context.getResource() method.
> >
> > The reason for this proposal is because it will make a Cocoon
> > based WAR file more portable. If someone wants to package
> > their Logicsheets inside their WAR file, they can always
> > reference them by "context:/Relative/path/to/resource.xsl"
> > and won't have to rewrite the cocoon.properties and cocoon.xconf
> > files for each installation.
> >
> > In fact, the Producers/Generators should use the "context:"
> > methodology to find the files for input into the system.
> > That will ensure that they follow the security and architecture
> > mechanisms of the Servlet specification.
> >
> > The only section that would require any file:// urls is the
> > XSP architecture.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> --
> ______________________________________________________________________
> Conny Krappatsch mailto:conny@smb-tec.com
> SMB GmbH http://www.smb-tec.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org