> To the solution proposed by Thomas: > Using the session or the servlet context instead of ThreadLocal may be seen > as a bad programming pattern since you will have to expose typical > presentation-tier > objects down into the persistence-tier and get them all carried over trough > the business-tier. OUCH! > And before somebody comes up with the idea... NO!!! For a large and well > designed application, using the PersistenceBroker stuff at JSP level is not a > good > design pattern! ;)
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 and security is a typical orthogonal concern that is relevant to any of your tiers. 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. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
