"kabir.khan@jboss.com" wrote:I have largely implemented this locally. Adrian's test still fails since the MetaDataRetrievalToMetaDataBridge is not serializable

That could never be properly serializable. e.g. the bridge could link to a MetaDataRetrieval that loads data from a database or it may link to scopes that depend upon the server or cluster you are running in.

What I don't understand is why the objects in the test have a proxy anyway?

Your point creates another issue. The mechanism of "serialization" should depend upon the use case.

1) The proxy is for server side aspects and should be removed when given to the client, i.e. we serialize it as the plain class. Although this use case doesn't make much sense. 2) The proxy is intended for client side use and should contain a MetaData object that is serializable and contains the client side metadata (or knows how to link to it on deserialization). 3) The proxy should be replaced with a client side stub that does remote requests on the server side object.

"adrian@jboss.org" wrote:What I don't understand is why the objects in the test have a proxy anyway?

This is a mystery to me as well...

Regarding the serialization, as it works now (without MetaData), is I serialize some extra information for use when unserializing on a client. I could do the same for the MetaData. How would I get all the present MetaData though?

I could do the same for the MetaData. How would I get all the present MetaData though?

That's my point. You can't in general. Only if the MetaData is specifically designed for serialization to the client would this possible. i.e. the proxy has been specifically setup for client side usage.

e.g. One use case of the MetaData in future is be able to have an AspectManager in the application scope or subsystem scope of the metadata. That's not something you're going to want to serialize to the client. :-)