Hiya again,
and thanks for the prompt answers.
> I think you mix up different things here. The servlet context is
> intended to be local storage for the web app that is guaranteed to be
> shared by all running instances as long as they are in the same VM. It
> has nothing to do as such with any of your tiers (for that matter, the
> same applies to the session, it is mainly intended as a storage that
> holds data that is relevant for one use of the web app; again nothing
> says that it can only be used for presentation stuff).
> Eg. Acegi uses the session instead of ThreadLocal to store
> authorization-related things:
>
http://cvs.sourceforge.net/viewcvs.py/acegisecurity/acegisecurity/core/src/main/java/net/sf/acegisecurity/context/HttpSessionContextIntegrationFilter.java?rev=1.4.4.1&view=markup
uh, maybe I caused some confusion, in the link that you posted, the HttpSession is beeing used in a (Servlet API) Filter and I usually include this stuff into
presentation-tier which is probably not really correct and 'may' be discussed to death if it is or it is not. ;) For this reason I was stating some bla, bla
about design rules und such stuff, however since I am using myself this kind of code, well the statements I made may not be really consistent to what other
people understand under presentation-tier, so sorry for the troubles... :D
Maybe I should say it so: What scares me is thinking at OJB having methods that take Servlet API objects as arguments, this I think is what OJB should avoid to
do, such stuff would create hard links to the Servlet API. Of course you could use reflection to avoid this, but... ouch, this is even more scary and I would
call this a 'dirty hack' ;)
However as said in my previous mails, the patch proposal for the PersistenceBrokerThreadMapping I posted works and may be the easiest solution for this issue,
without needing any separation for web-apps from standalone applications. There is also another problem with the use of Servlet API stuff, think for example to
applications (not web-applications) beeing hot-deployed within a J2EE server that exposes services trough EJB, RMI or wathever services, in this case you will
have no access to any Servlet API objects, however the problem may still be there if the J2EE server pools Thread instances.
> Btw, all I was suggesting is that in OJB we should make this
> pluggable, so that OJB is agnostic to the actual storage mechanism,
> and then we could provide a ThreadLocal version (default) and a
> ServletContext one for webapps.
Again if it is possible to avoid this, it would be great, OJB configuration is already quite complexand adding more levels of configuration and/or 'code paths'
for different deployment environments, may increase the complexity to an 'uncomfortable' level. However this is just my point of view, you are the developers
after all, I am just a user. :D
bye
danilo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
