Serialize spring scoped proxies

[kar...@gmail.com]

Hello,

I wonder if anyone could give me a few pointers how to serialize classes which use Spring injected beans? I have a web project that uses spring web flow, which serializes a lot of classes.

I have both regular singleton @Autowired beans and also proxies with different scopes (request etc). I guess I'll have to write a custom serializer that extends the FieldSerializer and register that one as the default one?

/K

[Joachim Durchholz]

Am 23.02.2014 02:52, schrieb kar...@gmail.com:
> Hello,
>
> I wonder if anyone could give me a few pointers how to serialize classes
> which use Spring injected beans?
>

> I have both regular singleton @Autowired beans

Injected stuff (@Autowired etc.) is just a normal reference and
shouldn't create any specific issues.

You may want to prevent it from getting serialized, and "deserialize" it
by putting in a reference to the Spring bean on the receiving side.
It might be a good idea to call into Spring's auto-injection methods,
though I have no idea how to get at that.

> and also proxies with
> different scopes (request etc).

I'm not sure what happens if the proxy is a class that's auto-generated
via Javassist or some other byte code generation framework.

Deserialization could fail if Kryo thinks the generated class on the
receiving side is incompatible with the generated class on the sending
side; whether that's the case or not would depend on specifics of the
generation process.

It's also possible that a proxy doesn't make sense on the receiving
side; it depends on what exactly the proxy does (e.g. if it's proxying
an RMI object, deserialization should probably do something different
than if it's proxying something to be loaded from a database).

And in general, if it's a database proxy, you probably don't want to
serialize the object graph anyway, because deserialization will load
everything on demand and you'll get N SELECTs when deserializing a
network of N objects.

> I guess I'll have to write a custom
> serializer that extends the FieldSerializer and register that one as the
> default one?

I suspect that application logic will dictate custom serializers on a
case-by-base basis.
It might be possible to cover multiple cases by inspecting annotations.

[kar...@gmail.com]

Hello, thank you for your answer!

On Sunday, February 23, 2014 5:01:28 AM UTC+1, Toolforger wrote:

Am 23.02.2014 02:52, schrieb kar...@gmail.com:
> Hello,
>
> I wonder if anyone could give me a few pointers how to serialize classes
> which use Spring injected beans?
 >
 > I have both regular singleton @Autowired beans

Injected stuff (@Autowired etc.) is just a normal reference and
shouldn't create any specific issues.

You may want to prevent it from getting serialized, and "deserialize" it
by putting in a reference to the Spring bean on the receiving side.
It might be a good idea to call into Spring's auto-injection methods,
though I have no idea how to get at that.

Yeah, this was what I initially had in mind. I maybe should mark all my "spring fields" as transient and have some serializer that injects all the dependencies again. There probably is some spring method.

 

 > and also proxies with
> different scopes (request etc).

I'm not sure what happens if the proxy is a class that's auto-generated
via Javassist or some other byte code generation framework.

Deserialization could fail if Kryo thinks the generated class on the
receiving side is incompatible with the generated class on the sending
side; whether that's the case or not would depend on specifics of the
generation process.

It's also possible that a proxy doesn't make sense on the receiving
side; it depends on what exactly the proxy does (e.g. if it's proxying
an RMI object, deserialization should probably do something different
than if it's proxying something to be loaded from a database).

And in general, if it's a database proxy, you probably don't want to
serialize the object graph anyway, because deserialization will load
everything on demand and you'll get N SELECTs when deserializing a
network of N objects.

 > I guess I'll have to write a custom
> serializer that extends the FieldSerializer and register that one as the
> default one?

I suspect that application logic will dictate custom serializers on a
case-by-base basis.
It might be possible to cover multiple cases by inspecting annotations.

Seems like it would be possible to use AspectJ to get spring to inject dependencies automatically when creating a new instance, I might try that.

Would creating a serializer extending the fieldSerializer which looks for a special annotation and putting this serializer as the default one make any sense? Maybe the overhead of checking for that annotation will be to big if it's done for each class. Manually registering these classes would be possible for me since they are not that many (well, below 20 at least)

[Martin Grotzke]

You could try
CGLibProxySerializer and JdkProxySerializer provided by kryo-serializers: https://github.com/magro/kryo-serializers

Cheers,
Martin

--
You received this message because you are subscribed to the "kryo-users" group.
http://groups.google.com/group/kryo-users
---
You received this message because you are subscribed to the Google Groups "kryo-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kryo-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.