I think is a must-have, in order to hit a POJO via RMI. If I have an remote method that returns an object or an object graph, if it hasn't already been Serializable, it will need to be.
Something like this was mentioned at one of the Bootcamps. It's not a huge feature, like transactions or security, but it's a common error for people newer to Java over the wire.
It might be nice to automagically serialize all the parameters/return values of a remoted method/class. Maybe you wouldn't have to do it for the whole class, just for the instances that are "listening" on the remote port.
First of all I agree that serialization should be interceptable.
But I wonder if it's necessary to have special definitions for these kinds of pointcuts. I wouldn't introduce new elements to jboss-aop.xml unless absolutley necessary.
Can't you just always add the read/writeObject methods if they don't exist when you instrument a class that implement Serializable? The implementation would simply call ObjectInput/OutputStream.defaultRead/WriteObject. In that case regular method interception could be used.
This shouldn't change the semantic of serialization if no interceptors are attached. The only disadvantage I can see is a little performance impact when serializing objects, but since serialization is known to be quite slow, this will probably not matter that much.
If a class implements the Externalizable interface, the read/writeExternal methods can again be intercepted by standard method interception.
If the class doesn't implement it, there is no useful default implementation for these methods (I think you can't call the defaultWriteObject from writeExternal), so the externalizable-pointcut would need to provide some implementation in the form of an interceptor or a mixin.
But then these cases can already be handled by introductions:
What do you think?
you can already make a pojo serializable by introducing the Serializable interface, like
I'm not sure if this should be done by 'automagically', there are very good reasons to make some classes not serializable.
Maybe not the right place for this, but when a POJO is made serializable by using aspects, how do you define what is transient and what is persistent?
The only assumption that is safe to use, is that everything should be serialized, but that might not be safe, since not all of its state can be guaranteed safely serialized. Can it?
Using the serialization api and the requirements there mandate a public, no-args constructor that can reconstruct state, but that is not the case here, is it?
Sorry. Read the other post - all fields are transient. Got it.
"Bill Burke" wrote:
I want to add a serialization-pointcut. What it will do is intercept write/readObject for Serializable, or read/Write object on Externalizable.
I have a need for exactly this feature. Did it ever get implemented? I can't find a reference in the doco about it. Is it on the roadmap?
Not in there yet, but I think you can do it with either an introduction, or an execution pointcut.
The introduction would introduce the read/writeObject method if the object did not implement Externalizable. If the object does implement Externalizable, then intercept the read/write of the Externalizable interface.
I think this will work, not sure.
Think the problem with this is that the serialization spec requires readObject/writeObject to be private, but AFAIK there's no way to introduce private methods into your objects (or am I mistaken?). Anyway, I've found another way to solve my problem without this.