Infinispan just went GA. Hibernate 3.5 is at a CR. It's getting to be time to try clustering our app using Infinispan and their cache provider for Hibernate.
We have a few machines in the QA lab just waiting for this. I hope our gb switch is fast enough to run an Infinispan cluster. Our app hauls a lot of content, and I noticed that they used Inifiband interconnects (way faster than any ethernet, widely used in high-performance computing) in their benchmarks.
If anyone has already tried Infinispan with Hibernate let me know how it went for you.
Thursday, February 25, 2010
Upgrading To Spring and SpringSecurity 3.0
Tonight I upgraded our enterprise Java app to both Spring 3.0 and Spring Security 3.0.
Spring 3.0
Upgrading to Spring 3.0 was easy. It works with spring-*-2.5 XML schemas, so I didn't have to change any of my beans files. The only hitch is that we use Jersey and the jersey-spring module.
We build with maven, and this module's pom has versioned dependencies on Spring 2.5.x, so a bunch of <exclusions> were needed.
Spring Security 3.0
Spring Security was much harder to upgrade from 2.0.4 to 3.0.2. The module structures have changed, so it was a bit of trial and error to find the minimal set of spring-security modules that met our app requirements.
The trouble wasn't over once I had a clean build. Lots of the classes have changed packages, so a number of the beans in our spring security XML file needed to be fixed.
Our old Spring Security config had some quirks. It used the security namespace configuration to create the primary beans (it created them all with an underscore ID, like _formLoginFilter) then created two different filter chains using normal bean definitions.
This doesn't work in SS3. No choice but to manually set up all the bean definitions for all the components of SS. This might be good (lots of flexibility, I learned a ton about SS) but it took hours to get it just right.
The app is running smoothly now, using all the latest Spring goodness. Hope this helps someone!
Spring 3.0
Upgrading to Spring 3.0 was easy. It works with spring-*-2.5 XML schemas, so I didn't have to change any of my beans files. The only hitch is that we use Jersey and the jersey-spring module.
We build with maven, and this module's pom has versioned dependencies on Spring 2.5.x, so a bunch of <exclusions> were needed.
Spring Security 3.0
Spring Security was much harder to upgrade from 2.0.4 to 3.0.2. The module structures have changed, so it was a bit of trial and error to find the minimal set of spring-security modules that met our app requirements.
The trouble wasn't over once I had a clean build. Lots of the classes have changed packages, so a number of the beans in our spring security XML file needed to be fixed.
Our old Spring Security config had some quirks. It used the security namespace configuration to create the primary beans (it created them all with an underscore ID, like _formLoginFilter) then created two different filter chains using normal bean definitions.
This doesn't work in SS3. No choice but to manually set up all the bean definitions for all the components of SS. This might be good (lots of flexibility, I learned a ton about SS) but it took hours to get it just right.
The app is running smoothly now, using all the latest Spring goodness. Hope this helps someone!
Subscribe to:
Posts (Atom)