Spring-Blaze 1.5.0 M2 - Still get Lazy Init Error.

[cwiese@documationcorp.com]

Jeremy-

I am using BlazeDS 4, Spring 3.0, and the new "spring-flex-core-1.5.0.M2.jar"...........with JPA.

I still get the LazyInitializationException...when using the JpaConfigProcessor.

[BlazeDS]Exception occurred during serialization: org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: org.trinityhealth.resource.domain.Resources.resourceses, no session or session was closed
	at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:383)
	at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:375)
	at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:122)
	at org.hibernate.collection.PersistentSet.size(PersistentSet.java:162)
	at org.springframework.core.style.DefaultValueStyler.style(DefaultValueStyler.java:104)
	at org.springframework.core.style.DefaultValueStyler.style(DefaultValueStyler.java:72)
	at org.springframework.core.style.StylerUtils.style(StylerUtils.java:47)
	at org.springframework.core.convert.support.GenericConversionService.convert(GenericConversionService.

Here is the guilty party:

	@OneToMany(fetch = FetchType.LAZY, mappedBy = "resources")
	public Set<Resources> getResourceses() {
		return this.resourceses;
	}

Here is my config:

	<flex:message-broker mapping-order="1">
		
		<flex:config-processor ref="myJpaConfigProcessor" />
		<flex:mapping pattern="/messagebroker/*"/>
		<flex:message-service
			default-channels="my-streaming-amf,my-longpolling-amf,my-polling-amf" />
		<flex:secured />
	</flex:message-broker>

	<bean id="myJpaConfigProcessor" class="org.springframework.flex.core.io.JpaHibernateConfigProcessor">
		<property name="entityManagerFactory" ref="entityManagerFactory"/>
	</bean>

Any ideas? - what I am missing ...I tried the SNAPSHOT too. Same issue.

Thansk, Chuck

[cwiese@documationcorp.com]

I am logging org.springframework.flex.core.io.SpringPropertyPro xy

Everthing seems to work as expected until org.springframework.flex.core.io.PersistentCollect ionConverterFactory.

I would expect that this - would prevent the LIE. Is the java.util.Set not treated the same?

                if (!Hibernate.isInitialized(source)) {
                    return null;
                } else {
                    return (T) source.getValue();
                }

29.03.2011 19:54:56.462  DEBUG    org.springframework.core.convert.support.GenericConversionService  - Looking for Converter to convert from [TypeDescriptor java.sql.Date] to [TypeDescriptor @javax.persistence.Temporal @javax.persistence.Column java.util.Date]
29.03.2011 19:54:56.463  DEBUG    org.springframework.core.convert.support.GenericConversionService  - Converting value 2011-03-23 of [TypeDescriptor java.sql.Date] to [TypeDescriptor @javax.persistence.Temporal @javax.persistence.Column java.util.Date]
29.03.2011 19:54:56.464  DEBUG    org.springframework.core.convert.support.GenericConversionService  - Looking for Converter to convert from [TypeDescriptor java.sql.Date] to [TypeDescriptor @javax.persistence.Temporal @javax.persistence.Column java.util.Date]
29.03.2011 19:54:56.465  DEBUG    org.springframework.flex.core.io.SpringPropertyProxy  - Actual type of value for property 'resourceMgrInd' on instance org.trinityhealth.resource.domain.Resources@13eb41e5 is class java.lang.String
29.03.2011 19:54:56.466  DEBUG    org.springframework.flex.core.io.SpringPropertyProxy  - Actual type of value for property 'userModDt' on instance org.trinityhealth.resource.domain.Project@3e99c59d is null
29.03.2011 19:54:56.467  DEBUG    org.springframework.flex.core.io.SpringPropertyProxy  - Actual type of value for property 'userAddId' on instance org.trinityhealth.resource.domain.Project@3e99c59d is null
29.03.2011 19:54:56.468  DEBUG    org.springframework.flex.core.io.SpringPropertyProxy  - Actual type of value for property 'projectClass' on instance org.trinityhealth.resource.domain.Project@3e99c59d is class java.lang.String
29.03.2011 19:54:56.469  DEBUG    org.springframework.flex.core.io.SpringPropertyProxy  - Actual type of value for property 'projectResourceses' on instance org.trinityhealth.resource.domain.Project@3e99c59d is class org.hibernate.collection.PersistentSet
29.03.2011 19:54:56.471  DEBUG    org.springframework.core.convert.support.GenericConversionService  - Looking for Converter to convert from [TypeDescriptor org.hibernate.collection.PersistentSet] to [TypeDescriptor @javax.persistence.OneToMany java.util.Set]
29.03.2011 19:54:56.472  DEBUG    org.springframework.core.convert.support.GenericConversionService$MatchableConverters  - Default converter lookup [MATCHED] org.hibernate.collection.PersistentCollection -> java.lang.Object : org.springframework.flex.core.io.PersistentCollectionConverterFactory@3abd6b1e

[cwiese@documationcorp.com]

Stepping through the code it seems that [CORRECTION]

org.springframework.flex.core.io.PersistentCollect ionConverterFactory is attempting to prevent LIE by checking !Hibernate.isInitialized(source).....but this SET property never get to this point. See next message ...it gets a LIE trying to call SpringPropertyProxy.getValue BEFORE conversion.

I switched from Hibernate 3.6 to 3.3.1 ...same issue.

[cwiese@documationcorp.com]

Not sure how this could work ...but my use case dies with a LIE in SpringPropertyProxy.getValue BEFORE the PersistentCollectionConverterFactory has a change to run....when passing the "value" to conversionService.convert.

I guess I need to check Hibernate.isInitialized(value) here?!?!?!

    @Override
    public Object getValue(Object instance, String propertyName) {
        PropertyAccessor accessor = getPropertyAccessor(instance);
        Object value = accessor.getPropertyValue(propertyName);
     ..........

        if (!sourceType.getType().equals(targetType.getType()) && this.conversionService.canConvert(sourceType, targetType)) {
     -->>       value = this.conversionService.convert(value, sourceType, targetType);
        }
        return value;
    }

[gianalvarez]

Has anyone been able to resolve this issue? I'm also running into the same situation with Spring-Blaze-DS integration 1.5.0.M2. Based on the Reference Guide, Spring is supposed to detect that Hibernate is being used.

Same as the original post, I have an entity with a @OneToMany and I'm getting a LIE when the entity is being serialized back to the Flex client.

[cwiese@documationcorp.com]

The idea to have BlazeDS serialization fail silently (with null not LIE) is a great concept. We do not have to create static DTO and mechanically copy the data. In fact, I have every 1:M as Lazy but use the HQL query to determine the various "views" of data that I require (thereby loading the 1:M in on SQL call).

However, until it is fixed by the pros :-) here is a work around.

org.springframework.flex.core.io.SpringPropertyPro xy.java

@Override
public Object getValue(Object instance, String propertyName) {
PropertyAccessor accessor = getPropertyAccessor(instance);
Object value = accessor.getPropertyValue(propertyName);
--ADD THIS LINE 84:
if (!Hibernate.isInitialized(value)) return null;

PS) When using DOMAIN objects to transfer from SPRING to FLEX....becareful when sending updated DOMAIN objects ..the same serialization happens going back. Sometimes, with a couple simple self joins (1:M) a lot of data gets sent back to SPRING.

[gianalvarez]

Thanks for the workaround. I did a little bit of digging around and found the following Bug open https://jira.springsource.org/browse/FLEX-158.

This exactly matches the issue I was having. I was able to solve the problem by changing Tomcat to use log4j (simply cause it was easier for me this way) and setting the logging to INFO.

log4j.category.org.springframework = INFO (you can be more specific if you don't want to lose all the spring DEBUG statements)

Hopefully this helps other people as well until the issue gets solved.

[cwiese@documationcorp.com]

Great find.

In fact the very next line after my hack is a DEBUG with the "value".....that must be it.

Thanks, Chuck!!!!