JiJi, > Unfortunately, the corporate architects do not allow
presentation tier (ie: servlet requests) to be passed all the way down to the persistence tier.
This is a good policy. Your persistence should have nothing to do with your presentation.
The goal is to put the session pull the login id out of the servlet session, on each request, and stick it in an application defined session object instance that is uncoupled from the servlet api's.
Why not pass that application-session object to your "session"-based services, instead of playing tricks with ThreadLocal.
Putting the Session instance into thread local would, I hope, make it available to the persistence tier without adding a method parameter all the way through all method calls top to bottom.
Yes, ThreadLocal will do that, but it's very messy, pretty much impossible to document, and probably just not the right thing to do.
You don't necessarily need to add parameters all the way down the call tree. Did you guys design a persistence layer with methods that take no arguments? That sounds weird... why can you not use the intended methods in your persistence layer?
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
