Berin, thank you very much for your insights. > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: den 27 augusti 2001 16:09 > To: Avalon Development > Cc: Cocoon Developer's List > Subject: Re: [Propsal][C2/2.1] Cocoon2 component manager hierarchy (...) > I really don't like static "root" ComponentManagers due to the > security constraints > you have to enforce. I agree completely - this is precisely the situation I want to avoid. > One mechanism that is available to users of J2EE solutions is > JNDI. If you can have your enterprise application create your > root component manager, you can access it from JNDI. Yes. This would solve the problem. > This will even allow you to span webapps--but it is done in a safe > and well tested secure mechanism. If you would be open to J2EE, then I would be > open to allowing Cocoon to use JNDI to get the root ComponentManager. I am open for J2EE/JNDI. Very open, in fact. Now, in a clustered environment, what I would like to do in order to avoid having to force the load order is to have one of my EJB servers start the root CM as a service and bind it to a JNDI name. As this is done non-lazily (all services are started before the EJB server is considered "up") the Tomcat instances and Cocoons in the cluster can then load servlets in any order. The ExcaliburComponentManager can not work as a remote object, as the component references get all messed up if the components travel across the network, and there is no requirement for components to be remote objects. So the CM would have to travel across the wire when it is looked up. However, should one want to run the CM remotely (for whatever reason), the connection must be dropped periodically as the RMI libraries (in my experience) leak memory. This means we need a wrapper around the remote CM. Thus I believe that the factory pattern is applicable here: <init-param> <name>root-component-manager</name> <value>org.apache.my.CMWrapper:org/apache/my/ComponentManager</value> </init-param> Where the part before the ':' is the factory class, and the part after the first ':' is parameters to the factory. This way one can use JNDI or whatever method is applicable, and avoid the load order problem. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
