Hello Peter!
I already feel like getting lost in debris but I will try to climb
out! :-)
PS> IFAIK for EJBs you don't have to release the reference to a stateless
PS> bean after performing a call. I guess if I need to release the referenece
PS> after the call, the code will have to be written using try {} finally
PS> construct which doesn't make code look very clean. Is it the way to go ?
1)
I guess that if you _want_ to release something in your worker
doFoo() method it is the way to go. Agree, not very nice.
2)
Berin, did I get you right that I was wrong in prev. mail and
it's preferrable to grab a reference to another component in service()
and release in dispose() then to do a lookup() in each doSomething()?
This saves us from extra try{}finally{}, but I beleive that not _this_
should drive our desision, but performance and resource consumption
concerns. Berin?
PS> Another question concerns stateful components used in a servlet
PS> container (I use tomcat). The only way to bind a stateful bean to a
PS> specific client is to use HttpSession to store the reference. This
PS> implies that the component needs to be serializable. I am not sure
PS> though that this will do the job. After a servlet context reload,
What is that? You change some of the .jar or .class under WEB-INF
and ask Tomcat to reload or wait for it to reaload automatically?
I beleive that this only happens in development environment and
shouldn't be really worried about. I beleive such an action causes
a second instance of the whole Fortress to be created, doesn't it?
PS> the session data will be deserialized
or are we speaking about a distributed environment, f.e. a BEA cluster
and the session is deserialized on a different host then it was
serialized? e.g. we're speaking about how to make our app be
'distributed'?
If yes, then we really shouldn't store anything obtained via a
lookup() into the session. A good point!
PS> but the component won't be managed anymore.
PS> Is there a way to restore the link between the component and
PS> the component manager ?
What scenario we're in? If distributed, then naturally no!
If we're on the same container same host still I do not think
it is a good idea to serialize a singletone object for example!
So it looks like we should _never_ put an object obtained from
lookup() into the session.
PS> An alternate solution that I see, is to develop
PS> stateful beans as statless and provide a posibility for the HttpSession
PS> to be accessible from inside the component
Looks like this is preferrable. We create some serializable
class to manage our state and use it communicate data between session
and component. Much like C++ struct or
PS> (using thread context perhaps).
I would rather go for passing HttpSession as one of the arguments
to the doFoo() method of your Role interface. More manageable.
Easier to understand and debug.
PS> The bean that needs some stateful data for a client then would
PS> use the HttpSession to store the data for and access it on a subsequent
PS> call. Is it a good idea ?
Looks good to me :-)
PS> If it is then whould it make sens to decouple such components from
PS> HttpSession, perhaps through some sort of wrapper ?
I would consider the following ground for answering this question
(decouple or not decouple):
Is this component going to be used in non-servlet environment?
If yes, we may spend the effort and decouple it.
If not, it won't be worth the effort.
(An XP developer would never
do it intil he badly needs it, I guess ;-)
PS> I am not sure here, you said that there are no suport for Session so
PS> perhaps such components wouldn't be reusable anyway.
I beleive Berin was speaking about some other kind of session.
Internal to an avalon container, so it's a whole different story.
You components will be perfectly usable if code them along
these lines!
WBR, Anton
P.S. Hope some experienced Avalon designer will comment
on this -- I'm just a novice :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
