> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
