> > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
