Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

I am getting two different information.
This forum http://forums.terracotta.org/forums/posts/list/66.page

The answer is yes, it should it work fine -- all of our testing with this use case has shown that. The key point is to use AspectJ at compile time if aspects have any state that should be clustered.

The issue with AspectJ weaving at load time (LTW) and DSO is that DSO instrumentation runs before (as AspectJ uses javaagent and DSO is in the bootjar), meaning that any load time woven-in code won't be instrumented by DSO and hence, won't be clustered.

On the other hand, it is still possible to move all the clusterable state outside of aspects in a Spring application (i.e. inject it using Spring's @Configurable) and then we can cluster that data as usual. However, this works only for Spring and requires the Terracotta for Spring product. There is a good reference at http://static.springframework.org/spring/docs/2.0.x/reference/aop.html#aop-aj-configure.

suggests that it will work together but this documentation http://docs.terracotta.org/confluence/display/docs/DSO+Technical+FAQ#DSOTechnicalFAQ-Q%3ACanImixTerracottaDSOwithAOPframeworks%3F tells otherwise.

Because of collisions that can occur due to both DSO and AOP instrumentation of classes, mixing the two is not an option. However, if instead of DSO the standard Terracotta installation is used, then no collisions can occur and the AOP framework can be used.

I would suggest exactly what the documentation says - use the standard Terracotta express installation, then no collisions can occur and the AOP framework can be used.

We are using spring security to manage our sessions and the spring class SessionRegistryImpl.java throwsNotSerializableException (my previous post http://forums.terracotta.org/forums/posts/list/7015.page)
Due to which we have to use TERRACOTTA DSO to declare this class and its fields as not serializable.

Lets follow this thread in one forum entry. Someone will get back to you regarding the other thread.

SpringSource's tcServer has serialization-based session replication. I am not keeping up to date on this stuff but would be surprised if Spring Security cannot be set into a serialization-friendly mode for Tomcat, tcServer, and Terracotta.

Webflow, MVC, etc. can all be set to store state in session as serializable objects but will not necessarily do so by default. Perhaps something similar is going on with Security? (FWIW, our example Examinator app we used to showcase on the site used Spring Security and had no problems serializing it.)

--Ari

I will try the examinator and find the difference between this and our appl Thank you very much

Oh my no. DOn't try the examinator. It is not up-to-date. But definitely look at the deployment descriptors and config in there and see if there are some flags.

A quick scan of the Javadoc over at Springsource shows almost all of the security framework extends (or what have you) java.io.Serializable interface.

Can you just tell us what exact reference is failing to serialize? You may have to implement the serialization methods since much of security is an interface so there is no concrete serialization impl (as the docs say...for security purposes). If you scanned the source to Examinator that might be what I would look for 1st...a concrete impl.

--Ari

The following class fails to serialize
org.springframework.security.core.session.SessionRegistryImpl.java: spring-security-core-3.1.0.RELEASE.jar

I went on and implemented the SessionRegistry interface and made it serializable. But than comes the next unserializable class and when i made that serializable the next class pops up

org.springframework.security.acls.domain.AclAuthorizationStrategyImpl
org.springframework.security.acls.domain.SidRetrievalStrategyImpl
org.springframework.security.access.hierarchicalroles.NullRoleHierarchy

i will give a look at the Examinator app. Thanks

Hmmm,

Definitely take a look at Examinator for hints as to how to implement SpringSecurity w/ session replication. I think the problem might be you are walking down the dependency graph into your DAO.

Examinator, IIRC, only had username and authentication-level / role as strings inside it under the Spring Security graph when visualized using the Terracotta dev console.

--Ari