ThreadLocal considerations. Use in WebSphere 6 and Weblogic 10.

ThreadLocal class enables the sharing of a variable in a statically way across a whole Java process by attaching this variable to a single Thread (p.e. Thread.currentThread()). This is specially useful to make accesible values recovered in filter layer to the other ones.

Think about database logging of HTTP requests or responses. Note that this is the unique point to retrieve, for instance, complete signed requests or responses. All this process (request and response) is executed on a single thread, so ThreadLocal mechanism can be used to share the request content with the DAO layer. By doing a threadLocal.set(request) on Filter class and a threadLocal.get() on DAO class the described functionality is achieved.

And here is where different behaviours arrive. WebSphere 6 doesn’t clean servlet pooled threads after execution while Weblogic 10 does. So, ThreadLocal variable must be cleared in WebSphere for every new request!

Typically is discouraged the use of this tecnique in managed environments, but in many cases the best should be the simpliest.

Reference – IBM – Threading lightly.

Spring Security 2.0 and Spring 2.0.X

Spring Security allows applications to include authentication features in J2EE applications with a very few effort. However, configuration in previous versions, like Acegi Security, was a hard task to perform by a newcomer. Spring people talks about a difference of a hundred of configuration lines between Acegi 1.0 (120 lines for configuration) and Security 2.0 (just only 16 lines). So, it’s highly advisable to use Spring Security 2.0.

These links can help in developing a small sample:

In our case, form based authentication via user/password in a webapp, we’ve include two minor adjustments in web.xml (webapp container configuration) and applicationContext.xml (Spring configuration).




* I’ve replaced – character for _ character in this XML file






* I’ve replaced – character for _ character and : character for __ characters in this XML file to get a suitable visualization

Development of login.jsp page is detailed in several resources, such as here.

It could be wonderful, but there is one important point for us which is poorly documented. Spring Security 2.0 only works with Spring 2.0.8. And we are using BEA Weblogic 10. And BEA Weblogic 10 only certifies the use of Spring 2.0.2. 

So we have now a dangerous decision: shall we use Spring Security 2.0 and Spring 2.0.8 and loose BEA (I mean Oracle) support or shall we use Acegi Security 1.0 and Spring 2.0.2 and write tedious and hard to maintain configuration files?

SAAJ 1.3, Weblogic 10 and Spring WS 1.0

You can find detailed literature regarding this issue, such as

The main problem is that Weblogic 9 and 10 include SAAJ 1.2 interface but SAAJ 1.1 implementation. So, the use of SAAJ 1.2 and SAAJ 1.3 on Weblogic must be set externally.

I decided to include these lines on Spring context in order to get web services working on our system.


Updated!  Spring Web Services JIRA