Thank you guys for your answers. It seems that I am on the good track. Roles generation task is also a usefull idea. I have more questions though. Regarding stateless beans, IFAIK for EJBs you don't have to
release the reference to a stateless bean after performing a call. I guess if I need to release the referenece after the call, the code will have to be written using try {} finally construct which doesn't make code look very clean. Is it the way to go ?
Another question concerns stateful components used in a servlet container (I use tomcat). The only way to bind a stateful bean to a specific client is to use HttpSession to store the reference. This implies that the component needs to be serializable. I am not sure though that this will do the job. After a servlet context reload, the session data will be deserialized but the component won't be managed anymore. Is there a way to restore the link between the component and the component manager ? An alternate solution that I see, is to develop stateful beans as statless and provide a posibility for the HttpSession to be accessible from inside the component (using thread context perhaps). The bean that needs some stateful data for a client then would use the HttpSession to store the data for and access it on a subsequent call. Is it a good idea ? If it is then whould it make sens to decouple such components from HttpSession, perhaps through some sort of wrapper ? I am not sure here, you said that there are no suport for Session so perhaps such components wouldn't be reusable anyway.
Regards, Peter.
Anton Tagunov wrote:
Hello Peter!
PS> Should a release the component after the lookup/call ? What about a PS> stateful component, is it mandatory to release it ?
The contract of a client component that does lookup()-s on ServiceManager is to always release what has been lookup()-ed. The question is when to release. The answer is "as soon as possible". For a stateless component release it right away, as soon as you're done with it. For a statefull component you'll have to release it later. Possibly even in your dispose().
It was a short answer, now the long one :-)
PS> Could somebody explain to me what I need to do in order to configure PS> a component as statless
If you want to make a component to retain its state, then you should 1) have one of the * FactoryComponentHandler (always creates a new component) * PoolableComponentHandler (and make the component Poolable) handlers create the component so that two different lookup() calls won't return the same component to two different clients * PerThreadComponentHandler also might or might not satisfy your needs (it depends on your component usage pattern what is the best handler) 2) after you do a lookup() you shouldn't release the component until you're done with it. Until you release() it it will retain its state. When you release() and lookup() anew you'll get another instance (or the instance from the pool, but by the Poolable's contract it should have reset its state to the intial by this moment)
So, statefull components are about retaining the reference to them as long as you need them. Not, however, that you still need to release() the component at some moment, probably in your dispose().
About the stateless: 1) have any type of handler that best fits your needs create the component. any handler will do. It depends on the component. If you component is really thread-safe and re-enterable then ThreadSafeComponentHandler fits well (this hanlder naturally provides lowest execution overhead). If your usage pattern allowes this, maybe PerThreadComponentHanlder will do. If you component is not really thread-safe, FactoryComponentHandldler or PoolableComponentHandler is what you need 2) in this usage pattern, please release() the component as soon as you're done with. the sooner you release the component, the more chance is that the system will be able to lower memory consumption. besides, some future containers (not the current fortress, but it's best to write components which do not care about what container they run in) may support reloading of component implementation and release()-soon usage pattern is going to make life with those contianers much easier.
Besides, you may consider moving away from roles files (although they're supported okay, but that's for you convinience really) to using @avalon and @x-avalon meta tags. Please see the Component1.java - Component4.java in the fortress/src/test and the <meta-collect> task in the main build.xml file. If you do move along this way you will no longer need to write the full names of the handlers, you will really need only
@x-avalon.lifestyle type=singletone for ThreadSafeComponentHandler @x-avalon.lifestyle type=thread for PerThreadComponentHandler @x-avalon.lifestyle type=pooled for PoolableComponentHandler @x-avalon.lifestyle type=transient for FactoryComponentHandler
WBR, Anton
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
