"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.

 

"kabir.khan@jboss.com" wrote:

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. :-)

 

"kabir.khan@jboss.com" wrote:

"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...

I'd concentrate on fixing this problem, since it is the real reason why the test is failing
(when it shouldn't).

For the MetaData serialization, just add a default implementation of something like:

if (metadata instanceof Serializable)
// serialize
else
// no metadata on the client