Re: Again session...

"Diez B. Roggisch" <[email protected]>
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <[email protected]>
> Just one more question.
> Within Barracuda (but also without it) which is yours preferred method
> on accessing sessions from and object which does not have a direct
> reference (it isn't a servlet), do you pass it as a reference (like a
> method parameter) or... what's your (and of others as well if you like)
> experience ?!

It depends.... generally, I disregard too much "magic" - e.g. code that works 
with a jdbc connection should get one passed, instead looking it up in the 
InitialContext of my EJB Container (where I look it up the very first time I 
need it in that particular request) everytime.

So worker-methods usually get all their parameters passed - this also scales 
better with multithreading and gives you a better understanding of the code, 
as you don't have to have knowledge about the magic - which isn't so much 
magic actually most times....

OTH if you work in such a well known application developement context like a 
webapplication, I think that every developer should at least know that there 
are such things like sessions and request/responses. So she shouldn't wonder 
too much for the outcome of MyMagicDoer.getSession() :) And of course if your 
application is layered, and you want the middle-part not to know too much 
about itself existing in a webapp, or its tedious to pass it always down, 
just because it _might_ be used, magic is ok :)

To be a little bit more specific - in Barracuda generally the EventContext is 
the one hook everything gets associated with. So I pass that down, and when I 
need something more specific get it out of there. I only attached objects to 
the running thread when e.g. the persistence-layer had to know things about 
the tomcat or whatever which my middleware shouldn't be aware of, as other 
persistency framework might only need to know the moons phase. 

Regards,

Diez
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.