A ClassNotFoundException was thrown when Hibernate 4 is on the classpath but not Spring Flex Hibernate 4 support (same issue for Hibernate 3). This commit add an additional check against Spring Flex Hibernate 3 and 4 in order to avoid this error.
Repair core tests and completely remove hibernate dependency from itself Move test to uncouple hibernate dependency from core Support hibernate as optional runtime environment Remove unnecessary casting Split hibernate dependency from core legacy refactor Split hibernate dependency from core
- Spring Security 3.0.5.RELEASE -> 3.2.4.RELEASE - Spring Integration 2.0.3.RELEASE -> 2.2.6.RELEASE - ActiveMQ 5.1.0 -> 5.7.0 - Remove local-repo since BlazeDS 126.96.36.19931 and 188.8.131.5207 are available in Spring repository for third party libraries - Update readme
Previous version was compatible with Spring 3.0.x, but not with Spring 3.1.x, 3.2.x or 4.x. HibernateProxyConverter is the main class broken if we try to upgrade Spring. Previous version was using PropertyTypeDescriptor, but this class has been removed since Spring 3.1. The alternative is to use TypeDescriptor#getSource() in order to detect if the target is a field or a property. This is the solution implemented by this commit. Since this API is not available in Spring 3.1.x or Spring 3.2.x, this commit introduces Spring Framework 4.x and Java 6 as minimum requirements for Spring Flex 1.6.x.
…etween a login JSP page and secured destination when using a AMF channel in a LCDS Environment The issue was that the per client authentication interceptor was being added to the interceptor list for servlet type endpoints as well. This resulted in the security context not being present when trying to fetch the data. Fixed the code so that interceptor is added only in case of LCDS NIO based endpoints.
…oup configuration from an external location
…s NIO endpoints It turns out due a change made for FLEX-185, the Security Login Command was changed so that the FlexContext.getHttpRequest() was being used used to set the source on the UserPasswordAuthenticationToken, which results in a silent error when passed a null value or a shell HttpRequest object (as is the case for NIO based endpoints). By ensuring that the code is enclosed in a try/catch block, this can be silently ignored if it happens. When we locally tested the fix, everything works.
… in poms to 1.5.1.BUILD-SNAPSHOT