Scoped proxies are fragile with respect to serialization [SPR-14117]

[spring-projects-issues]

Dave Syer opened SPR-14117 and commented

A scoped proxy (e.g. in @Scope("session") with @Lazy) carries a reference to a "serialization id" for the BeanFactory. This is in case, when it is deserialized, it needs to inject a dependency from the Spring context. As such, that can be quite useful, but it is also brittle, and not always necessary, since not all beans have dependencies to re-inject, and sometimes you want to share an instance between two contexts that don't naturally have the same serialization id.

There's quite a bit of discussion in one or two github issues related to Spring Cloud, Spring Boot and Spring OAuth2 (e.g. spring-attic/spring-security-oauth#705).

In the OAuth2 case we are only using @Scope("session") to keep the state segregated between concurrent users, and the data held in those beans is naturally serializable without any reference to the BeanFactory. I imagine this could be quite common, and I would like a way to annotate (or have Spring detect) that this is the case, so that the serialized form of the object does not contain a BeanFactory reference if it is not going to be needed.

---

Reference URL: spring-attic/spring-security-oauth#705

Issue Links:

• ClassCastException during deserialization of ScopedObject [SPR-15766] #20321 ClassCastException during deserialization of ScopedObject

Referenced from: commits 4024b2f

[spring-projects-issues]

Juergen Hoeller commented

The serialized representation of such a BeanFactory reference is quite trivial, so I suppose this is not about the computation effort or the memory requirement... but more about the failure to deserialize when the serialization id isn't resolvable, even when the deserialized BeanFactory isn't actually needed? If that is the case, do you have a use case plus stacktrace handy for such a deserialization failure?

[spring-projects-issues]

Dave Syer commented

Correct, it's not about computation or memory - for the kinds of objects I am interested in there is literally no use for the serialization id anyway (it's just noise). There's a link to another gh issue with a stack trace in the reference URL (here's the link: spring-cloud/spring-cloud-commons#93). The use case that sparked the debate was sharing a session between 2 apps using Spring Session, and having a @Scope("session") object blow up when it crossed the boundary.

[spring-projects-issues]

Juergen Hoeller commented

We might be able to make this more lenient, deserializing to a dummy BeanFactory instead of throwing an IllegalStateException. After all, the intent was just to reconnect to the same BeanFactory if available; if not available, we can proceed on a best-effort basis.