ManagedObject attachment serialization

[aloubyansky]

Looking into http://jira.jboss.com/jira/browse/JBMICROCONT-225

Is this supposed to be a general rule or should it only affect the metadata classes?

Currently, an attachment in the api is represented as Serializable. If attachments were not serialized then it would not make sense to require them implement Serializable?

If clients should not see the metadata api is there a reason for metadata classes implement Serializable?

[adrian.brock]

The original intention was that the ManagedObject would be used by
the management layer to configure the attachments.

As such for remote management, the attachments needed to be serialzable
such that the remote management tool could use the ManagedObject api
to change the attachment, retriefve the object and place it in the preconfigured
part of the deployment.

The notion of ManagedObject has changed a lot since
the original design. i.e.
* ManagedProperty can exist by itself
* ManagedObject is just an implementation detail with a new api for the managed layer

You'd need to ask Scott, et. al. how they are adding the changed attachments
into the Deployment when doing work remotely to change/persist the values
in for example a remote agent.

If they don't have the metadata classes on the client side, I'd guess there
either needs to be some proxy work (possibly inside the deployment layer?)
that can reconstruct the attachment on the server side
from the "ManagedObject" or the Deployment itself is reconstructed on the
server side from the management artifacts?

[starksm64]

The client effectively works with a proxy view of the ManagedProperties and containing types like ManagedDeployment/ManagedComponent. When an update to a set of properties through the ManagementView interface, the corresponding server side ManagedObject that is bound to the deployment attachment is retrieved, and the ManagedProperty values from the client applied.

[starksm64]

Its really equivalent to detached ejb3 entity beans. The proxied view is a value only copy that is reattached to the attachment through the ManagementView.

[aloubyansky]

So, would making attachment transient in ManagedObjectImpl be a proper fix?
If I make it transient all tests in ProfileServiceUnitTestCase pass. Otherwise, there is 1 error and 1 failure. The error is due to a classloading issue that, AFAIU, what the jira issue is about.

And then again, should the API be changed making the attachment an Object rather than keeping it Serializable?

[starksm64]

I don't think whether the attachment signature is Serializable matters. Other contexts require attachments to be Serializable so I would not change it. Just marking the attachment field as transient does what is needed. I was thinking there was an attachment being written in the ManagedPropertyImpl, but I guess I already removed that from the DefaultFieldsImpl.writeObject.

[aloubyansky]

Ok, I made it transient. And yes, the attachment is already excluded from the serialization of DefaultFieldsImpl.