Philipp Meier wrote: >>But, what would the gain be compared to using static method in >>ActionContext? It is definitely more code to implement interfaces and >>you can't do it just anywhere (you can only do it in the action class, >>not in classes used inside action). If we compare with J2EE, they took >>the route of the static method access by introducing the "java:comp/env" >> namespace in JNDI (which effectively is the same as a static method). >>It worked there, so why not here? >> > > Yes, that's an interesting and true view. For me though +1 for static > methods and ThreadLocals and all the other ugly stuff ;-))
Excellent! It may be noted that the preferred way to implement the java:comp/env namespace in J2EE is actually not to use threadlocals, but to instead use Thread.currentThread().getContextClassLoader() as the "switch" (but of course at some point the underlying implementation of currentThread() using something like a "threadlocal"). regards, Rickard ps. A little confession: those with good memory will remember my fierce opposition to the "java:comp/env" use and semantics on the EJB-INTEREST list a couple of years ago, which was basically the same argument here (with a minor twist though). Now I'm sucked into the mainstream mantra that "java:comp/env is good for you, yes it is". :-) Ah well. -- Rickard �berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! _______________________________________________ Webwork-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webwork-user
