Serialization error using <lookup-method>

[MHarhen]

I have just downloaded the release version of Spring 1.1. I am using lookup method injection using <lookup-method name="..." bean="..." />. It works perfectly.

However I receive a "Not serializable: net.sf.cglib.proxy.NoOp$1" error with the bean containing the injected method. As a result my HttpSessions won't serialize.

Is there a workaround?

I see that the Dynaop project https://dynaop.dev.java.net can make CGLIB proxies serializable - see its dynaop.CglibProxyHandle class. Is there any way to apply this method using Spring?

Thanks in advance for any suggestions or comments.

[Rod Johnson]

This is an oversight. I'll fix it promptly.

Btw Spring AOP proxies in 1.1 are serializable so long as the relevant application code is serializable. The lookup method functionality uses CGLIB directly, rather than going through Spring's AOP framework.

[Rod Johnson]

I've been looking into this more deeply and it's not actually so straightforward. The purpose of lookup method functionality is to enable the overridden method to return a prototype bean from the owning BeanFactory. This implies that the subclass created by the factory holds a reference to the factory. Serializing that subclass would imply serializing the whole factory (and the beans and bean definitions it contains), or a sophisticated tracking of the dependencies required to create the target prototype, which could still result in serializing a large number of beans.

With respect to MethodReplace overrides, rather than lookups, if the MethodReplacer implementation is a singleton and isn't BeanFactoryAware, ApplicationContextAware or the like, serialization might be possible with implementation changes.

But the lookup method functionality is of course most commonly used.

Thus I'm not sure that serializability is really feasible. So I'd like to open this to discussion, rather than leap in and change code at this point...

[MHarhen]

Thus I'm not sure that serializability is really feasible. So I'd like to open this to discussion, rather than leap in and change code at this point...

My vote is for serializability:
1. The Java convention is that containers/collections should be serializable e.g. HashMap, although their contents may not be serializable.
2. Not enabling serializability will reduce functionality in applications using serializable beans, whereas enabling it will provide increased functionality whenever the application's beans are serializable.
3. I am currently using a bean which holds a reference to my BeanFactory - the bean is serializable because all my beans are serializable. When I eliminate the BeanFactory reference using lookup method injection, my bean is no longer serializable.

[gpoirier]

3. I am currently using a bean which holds a reference to my BeanFactory - the bean is serializable because all my beans are serializable. When I eliminate the BeanFactory reference using lookup method injection, my bean is no longer serializable.

I didn't think Spring offered any BeanFactory that was Serializable? I know at least that DefaultListableBeanFactory and XmlBeanFactory are not serializable. And even if any BeanFactory was, would it really make sense to serialize it and create a new BeanFactory when you unserialize your bean?

[MHarhen]

I didn't think Spring offered any BeanFactory that was Serializable?

My mistake - you are correct - I did not receive serialization errors because my bean inadvertently held a static reference to a BeanFactory.

It is now clear to me that any bean holding a direct or indirect reference to a BeanFactory cannot be serializable, unless the reference is static. This is probably not a serious problem, as all instances of the bean are likely to be created by the same BeanFactory. However it is at odds with the "statics are bad" philosophy.

Unfortunately <lookup-method> does not seem to work for static methods, so the only way I can think of to achieve serializability is to use a static reference to a BeanFactory. Is there any other way?

Thanks in advance.

[Rod Johnson]

The Java convention is that containers/collections should be serializable e.g. HashMap, although their contents may not be serializable.

True, but a Spring factory is a rather different animal. Something that resulted in serializing a whole factory could be dangerous, as people could innocently put huge amounts of state into an HTTP Session or throw it over the wire. Unlike a typical list, the chances are very high that a Spring factory will contain objects that are not likely to be serializable, like DataSources.

One option might be the make the bean serializable but have the lookup methods throw an UnsupportedOperationException on deserialization. It would be better to be able to connect to a new factory, but how would that factory be located? Perhaps the lookup methods could throw UnsupportedOperationException until a method such as attachToFactory(BeanFactory bf) was invoked on deserialization. Would that address your requirement?

[MHarhen]

One option might be the make the bean serializable but have the lookup methods throw an UnsupportedOperationException on deserialization. It would be better to be able to connect to a new factory, but how would that factory be located? Perhaps the lookup methods could throw UnsupportedOperationException until a method such as attachToFactory(BeanFactory bf) was invoked on deserialization. Would that address your requirement?

Serializability is desirable for beans stored in HttpSessions. That is why I am trying to make my beans Serializable.

If you are suggesting that an attachToFactory(BeanFactory bf) method could be called in a custom readObject() method, that would work. However I am unclear on how the new BeanFactory would be located.

[ram_2000]

I think Serialization is important...

Instead of serializing the entire factory and all the bean definitions, can we somehow just serialize what is required for deserialize. Maybe even just allow serailization of the file name that stores the bean definition.

Just a thought.

[Rod Johnson]

Maybe even just allow serailization of the file name that stores the bean definition

A clever idea, but you'd end up with n instances of the factory if you serialized and deserialized n beans. This might well not be what you want.

Still, good to have some suggestions coming in...