Thomas Dudziak wrote:

Err, not exactly. The idea is to define some sort of DataStorage
interface against OJB would work in the MetadataManager and the other
places where right now ThreadLocal is used. The default implementation
of this interface would be using ThreadLocal so that
functionality-wise nothing would change. However, an alternative
implementation could use the ServletContext or the Session instead for
web applications (no use using this one for standalone apps) which
would be ok as OJB would be used in a web context anyway.

Ok, now I fiure out your idea...
well this still will create a link from OJB to the Servlet API requiring the 
use of reflection to avoid hard links, but this is a minor issue.
From what I see, the ThreadLocal in PersistenceBrokerThreadMapping is used to avoid borrowing a new PersistenceBroker within the same Thread when using proxies. So I do not currently see how the HttpSession or the ServletContext could replace exactly this behaviour, but well this is not very important...

However, sorry for insisting about this, a solution that will just clean-up the objects that are put into the ThreadLocal will solve everything without having to write different pluggable data-storage implementations for web- and/or standalone-applications.

well, in general we follow the rule of 'useful defaults, fine-grained
configurability' meaning that for the average usage as few things as
possible should have to be changed but if need arises, then the
ability to plug in different implementations should be provided. And
IMO for web apps the servlet context is a more useful storage than
threadlocal.

heh, I was not saying that there is anything bad in this... :)
I love the configurability and flexibility of OJB as it is and we are also using custom plugins specific to our needs, however seeing the number of (similar) requests that users are posting about how to set up OJB in a web-environment, such a kind of configuration parameter will increase the amount of support requests about the subject ;)

bye
danilo

P.S.:
Could you please configure your mail client to avoid posting the e-mail address 
of the person you are answering to?
Since I was so dumb to post my complete signature a couple of times in my mails on this public mailing list that can be accessed over web-interfaces, now I pay this with tons of spam. For me it is too late but it may be helpful to other users if their e-mail adress does not appear in the message body ;)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to