You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marcus Crafter <cr...@fztig938.bank.dresdner.net> on 2001/11/01 17:33:41 UTC
ParentComponentManager & config files
Hi All!
Hope all is well!
I've just been playing with the ParentComponentManager and
associated classes, and wanted to ask a quick question about
it's usage.
Was it always intended to use JNDI to name Configuration objects
that should be given to a parent ComponentManager ? Or is the
String passed to the constructor via a getParentComponentManager() in
the CocoonServlet class a general string argument that can be
used in any way by the component manager about to be instantiated ?
The reason I ask is because I think I might see a problem with passing
configuration objects to the parent component manager, if one wants
the configuration info to be read from a file.
The problem seems to be that it's difficult to resolve the
correct location of a config file in a parent ComponentManager
class or in a 'Configurator' class like what's written, unless
one specifies an absolute path, as opposed to a (perhaps
context) relative path.
ie. in web.xml
<init-param>
<param-name>parent-component-manager</param-name>
<param-value>MyComponentManager/conf/config.xconf</param-value>
</init-param>
where conf/config.xconf lies under /path/to/webapp/conf/config.xconf.
Even if the above is a misuse of what's intended, there is no
SourceResolver, or ServletContext in the 'Configurator' class to help
out referencing a relative file ?
I'm trying to stay away from having to specify an absolute path
in the param-value setting, or in a 'Configurator' class - any ideas
how to overcome this ? or have I lost the plot entirely! :-)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Managesoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@managesoft.com
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] New element to Excalibur Component Manager config (was: Re: ParentComponentManager & config files)
Posted by Peter Donald <do...@apache.org>.
On Sat, 3 Nov 2001 07:42, Berin Loritsch wrote:
> Greg Weinger wrote:
> > > > I had thought that using cocoon's CM to manage my application's
> > > > components was the wrong thing to do, because it required
> > > > modifying the
> > > > cocoon.xconf and cocoon.roles files - part of cocoon and not our
> > > > application. Was this assumption false ?
> >
> > I agree, from a maintenance perspective. You can keep your roles
> > separate in a user.roles file, referenced from the attribute <coocon
> > user-roles="path/to/user.roles"> but there is no standard way I know of
> > to keep your configurations separate, even if you are just "extending"
> > cocoon.
>
> Hmm. What if I were to provide an include directive.... Avalon
> Framework now has the notion of Namespaces for configuraiton. We
> could allow the ComponentManager to look for an element like this:
>
> <cm:include-roles href="path/to/new.roles"/>
> <cm:include-configuration href="path/to/new.xconf"/>
>
> If it finds those elements, it will load and use those files as well
> in the system. That way we can keep our configurations separated
> neatly--even for Cocoon!
>
> the namespace would be like this:
>
> xmlns:cm="http://apache.org/avalon/manager/1.0"
>
> The prefix is not necessary, but this could be useful in many situations.
+1
--
Cheers,
Pete
---------------------------------
I think not; therefore I ain't...
---------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] New element to Excalibur Component Manager config (was: Re: ParentComponentManager & config files)
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Berin,
> Hmm. What if I were to provide an include directive.... Avalon
> Framework now has the notion of Namespaces for configuraiton. We
> could allow the ComponentManager to look for an element like this:
>
> <cm:include-roles href="path/to/new.roles"/>
> <cm:include-configuration href="path/to/new.xconf"/>
That would be great. :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Managesoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@managesoft.com
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] New element to Excalibur Component Manager config (was:
Re: ParentComponentManager & config files)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Greg Weinger wrote:
> >
> > > > I had thought that using cocoon's CM to manage my application's
> > > > components was the wrong thing to do, because it required
> > > > modifying the
> > > > cocoon.xconf and cocoon.roles files - part of cocoon and not our
> > > > application. Was this assumption false ?
> > >
> >
> > I agree, from a maintenance perspective. You can keep your roles
> > separate in a user.roles file, referenced from the attribute <coocon
> > user-roles="path/to/user.roles"> but there is no standard way I know of
> > to keep your configurations separate, even if you are just "extending"
> > cocoon.
>
> Hmm. What if I were to provide an include directive.... Avalon
> Framework now has the notion of Namespaces for configuraiton. We
> could allow the ComponentManager to look for an element like this:
>
> <cm:include-roles href="path/to/new.roles"/>
> <cm:include-configuration href="path/to/new.xconf"/>
>
> If it finds those elements, it will load and use those files as well
> in the system. That way we can keep our configurations separated
> neatly--even for Cocoon!
>
> the namespace would be like this:
>
> xmlns:cm="http://apache.org/avalon/manager/1.0"
>
> The prefix is not necessary, but this could be useful in many situations.
Don't have a vote here, but it would be +1 :)
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] New element to Excalibur Component Manager config (was: Re: ParentComponentManager & config files)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 2 november 2001 21:42
> To: cocoon-dev@xml.apache.org; avalon-dev@jakarta.apache.org
> Subject: [Proposal] New element to Excalibur Component Manager config
> (was: Re: ParentComponentManager & config files)
>
>
> Greg Weinger wrote:
> >
> > > > I had thought that using cocoon's CM to manage my application's
> > > > components was the wrong thing to do, because it required
> > > > modifying the
> > > > cocoon.xconf and cocoon.roles files - part of cocoon and not our
> > > > application. Was this assumption false ?
> > >
> >
> > I agree, from a maintenance perspective. You can keep your roles
> > separate in a user.roles file, referenced from the attribute <coocon
> > user-roles="path/to/user.roles"> but there is no standard way I know of
> > to keep your configurations separate, even if you are just "extending"
> > cocoon.
>
> Hmm. What if I were to provide an include directive.... Avalon
> Framework now has the notion of Namespaces for configuraiton. We
> could allow the ComponentManager to look for an element like this:
>
> <cm:include-roles href="path/to/new.roles"/>
> <cm:include-configuration href="path/to/new.xconf"/>
>
> If it finds those elements, it will load and use those files as well
> in the system. That way we can keep our configurations separated
> neatly--even for Cocoon!
Sounds fine to me, but how is the path resolved? Should be:
<cm:include-roles href="path/to/new.roles"
resolver="org.apache.avalon.framework.component.WebAppResolver"
contextkey="WEBAPP_CONTEXT"/>
So it can use the contextkey parameter to lookup the webapp context in the
Context map passed to it, and use that to resolve the path and load the
configuration.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] New element to Excalibur Component Manager config (was: Re: ParentComponentManager & config files)
Posted by Greg Weinger <gw...@itmedicine.net>.
> Hmm. What if I were to provide an include directive.... Avalon
> Framework now has the notion of Namespaces for configuraiton. We
> could allow the ComponentManager to look for an element like this:
>
> <cm:include-roles href="path/to/new.roles"/>
> <cm:include-configuration href="path/to/new.xconf"/>
>
That would be great.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[Proposal] New element to Excalibur Component Manager config (was: Re:
ParentComponentManager & config files)
Posted by Berin Loritsch <bl...@apache.org>.
Greg Weinger wrote:
>
> > > I had thought that using cocoon's CM to manage my application's
> > > components was the wrong thing to do, because it required
> > > modifying the
> > > cocoon.xconf and cocoon.roles files - part of cocoon and not our
> > > application. Was this assumption false ?
> >
>
> I agree, from a maintenance perspective. You can keep your roles
> separate in a user.roles file, referenced from the attribute <coocon
> user-roles="path/to/user.roles"> but there is no standard way I know of
> to keep your configurations separate, even if you are just "extending"
> cocoon.
Hmm. What if I were to provide an include directive.... Avalon
Framework now has the notion of Namespaces for configuraiton. We
could allow the ComponentManager to look for an element like this:
<cm:include-roles href="path/to/new.roles"/>
<cm:include-configuration href="path/to/new.xconf"/>
If it finds those elements, it will load and use those files as well
in the system. That way we can keep our configurations separated
neatly--even for Cocoon!
the namespace would be like this:
xmlns:cm="http://apache.org/avalon/manager/1.0"
The prefix is not necessary, but this could be useful in many situations.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[Proposal] New element to Excalibur Component Manager config (was: Re:
ParentComponentManager & config files)
Posted by Berin Loritsch <bl...@apache.org>.
Greg Weinger wrote:
>
> > > I had thought that using cocoon's CM to manage my application's
> > > components was the wrong thing to do, because it required
> > > modifying the
> > > cocoon.xconf and cocoon.roles files - part of cocoon and not our
> > > application. Was this assumption false ?
> >
>
> I agree, from a maintenance perspective. You can keep your roles
> separate in a user.roles file, referenced from the attribute <coocon
> user-roles="path/to/user.roles"> but there is no standard way I know of
> to keep your configurations separate, even if you are just "extending"
> cocoon.
Hmm. What if I were to provide an include directive.... Avalon
Framework now has the notion of Namespaces for configuraiton. We
could allow the ComponentManager to look for an element like this:
<cm:include-roles href="path/to/new.roles"/>
<cm:include-configuration href="path/to/new.xconf"/>
If it finds those elements, it will load and use those files as well
in the system. That way we can keep our configurations separated
neatly--even for Cocoon!
the namespace would be like this:
xmlns:cm="http://apache.org/avalon/manager/1.0"
The prefix is not necessary, but this could be useful in many situations.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ParentComponentManager & config files
Posted by Greg Weinger <gw...@itmedicine.net>.
> > I had thought that using cocoon's CM to manage my application's
> > components was the wrong thing to do, because it required
> > modifying the
> > cocoon.xconf and cocoon.roles files - part of cocoon and not our
> > application. Was this assumption false ?
>
I agree, from a maintenance perspective. You can keep your roles
separate in a user.roles file, referenced from the attribute <coocon
user-roles="path/to/user.roles"> but there is no standard way I know of
to keep your configurations separate, even if you are just "extending"
cocoon.
> Looks fine to me, BUT: I wonder if there is a way to go "all the way",
and
> honor all lifestyle interfaces Avalon has bu hijacking a
ComponentHandler
> from Excalibur or something. I have the feeling that we're currently
> re-implementing a ComponentHandler step by step... Maybe that'd be
easier,
> but then you have to initialize the ComponentHandler, etc... OK, it
looks
> fine to me. Period.
I also was hoping to use the ParentCM so that Cocoon would be "embedded"
by a parent Avalon application.
So far you're talking about Cocoon managing its parent CM. Is there a
way for Coccon to grab a reference to an existing PCM from another
application? JNDI? A singleton? Any other approaches?
Does anyone have any info on the attempt to make an Avalon block out of
Cocoon?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ParentComponentManager & config files
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
> Sent: den 2 november 2001 16:58
> To: cocoon-dev@xml.apache.org
> Subject: Re: ParentComponentManager & config files
>
> I had thought that using cocoon's CM to manage my application's
> components was the wrong thing to do, because it required
> modifying the
> cocoon.xconf and cocoon.roles files - part of cocoon and not our
> application. Was this assumption false ?
Marcus,
I don't know. I see it not as having my own application separate from
Cocoon, but rather to extend Cocoon. I suppose it is a question of whether
you embed Cocoon in your app or the other way around. I have no idea what
the original intentions were.
> > That said, the string being passed *is* a general string
> argument. You can
> > use it as you see fit. As for the resolving of paths relative
> to the webapp
> > context, currently Cocoon will only honor Loggable and Initializable
> > contracts, but this is not an obstacle - it would be relatively
> simple to
> > make it honor another contract as well, maybe Contextualizable
> (?), and pass
> > the servlet context.
>
> Ok. Thanks for the tip mate - How does this patch look ? :-)
Looks fine to me, BUT: I wonder if there is a way to go "all the way", and
honor all lifestyle interfaces Avalon has bu hijacking a ComponentHandler
from Excalibur or something. I have the feeling that we're currently
re-implementing a ComponentHandler step by step... Maybe that'd be easier,
but then you have to initialize the ComponentHandler, etc... OK, it looks
fine to me. Period.
Now to get a committer interested... (I'm not.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ParentComponentManager & config files
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Leo,
Thanks very much for your input. Much appreciated. :-)
On Thu, Nov 01, 2001 at 06:11:58PM +0100, Leo Sutic wrote:
> Marcus,
>
> the ParentCM was intended to be used with JNDI. The rationale is as follows:
> Component settings for the individual servlet is specified in cocoon.xconf.
> Therefore, the per-servlet settings are already addressed and there is no
> need for a ParentCM. However, in order to configure multiple servlets you
> need to break out of the webapp context, and then JNDI is the only safe and
> standard way. (There is, of course, more to the security aspects, but I
> won't pretend to know it. The above was the reasons I implemented it as I
> did.)
*nod*. I understand your rationale.
I had intended to use the parent CM concept to create a second CM that
would manage my application's components, separately from cocoon's CM.
I had thought that using cocoon's CM to manage my application's
components was the wrong thing to do, because it required modifying the
cocoon.xconf and cocoon.roles files - part of cocoon and not our
application. Was this assumption false ?
> That said, the string being passed *is* a general string argument. You can
> use it as you see fit. As for the resolving of paths relative to the webapp
> context, currently Cocoon will only honor Loggable and Initializable
> contracts, but this is not an obstacle - it would be relatively simple to
> make it honor another contract as well, maybe Contextualizable (?), and pass
> the servlet context.
Ok. Thanks for the tip mate - How does this patch look ? :-)
Cheers,
Marcus
Index: src/org/apache/cocoon/servlet/CocoonServlet.java
===================================================================
RCS file: /home/cvspublic/xml-cocoon2/src/org/apache/cocoon/servlet/CocoonServlet.java,v
retrieving revision 1.13.2.28
diff -u -r1.13.2.28 CocoonServlet.java
--- src/org/apache/cocoon/servlet/CocoonServlet.java 2001/10/11 09:11:02 1.13.2.28
+++ src/org/apache/cocoon/servlet/CocoonServlet.java 2001/11/02 15:45:40
@@ -14,6 +14,7 @@
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.DefaultConfigurationBuilder;
import org.apache.avalon.framework.context.DefaultContext;
+import org.apache.avalon.framework.context.Contextualizable;
import org.apache.avalon.framework.logger.Loggable;
import org.apache.cocoon.*;
import org.apache.cocoon.components.classloader.RepositoryClassLoader;
@@ -731,12 +732,17 @@
parentComponentManagerClass = parentComponentManagerClass.substring (0, dividerPos);
}
+ log.debug("Creating parent component manager.");
+
Class pcm = ClassUtils.loadClass(parentComponentManagerClass);
Constructor pcmc = pcm.getConstructor(new Class[]{String.class});
parentComponentManager = (ComponentManager) pcmc.newInstance(new Object[]{initParam});
if (parentComponentManager instanceof Loggable) {
((Loggable) parentComponentManager).setLogger(log);
+ }
+ if (parentComponentManager instanceof Contextualizable) {
+ ((Contextualizable) parentComponentManager).contextualize(this.appContext);
}
if (parentComponentManager instanceof Initializable) {
((Initializable) parentComponentManager).initialize();
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Managesoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@managesoft.com
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ParentComponentManager & config files
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Marcus,
the ParentCM was intended to be used with JNDI. The rationale is as follows:
Component settings for the individual servlet is specified in cocoon.xconf.
Therefore, the per-servlet settings are already addressed and there is no
need for a ParentCM. However, in order to configure multiple servlets you
need to break out of the webapp context, and then JNDI is the only safe and
standard way. (There is, of course, more to the security aspects, but I
won't pretend to know it. The above was the reasons I implemented it as I
did.)
That said, the string being passed *is* a general string argument. You can
use it as you see fit. As for the resolving of paths relative to the webapp
context, currently Cocoon will only honor Loggable and Initializable
contracts, but this is not an obstacle - it would be relatively simple to
make it honor another contract as well, maybe Contextualizable (?), and pass
the servlet context.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org