[starksm64]

The ManagedProperty/Fields going to the client should not be wrapped in an aop proxy. It should just be a simple pojo whose value will be read during process and applied to the server side version that has the aop proxy. Really, aop usage is not needed. Where we copy the client side value to the server side property, the Fields impl can handle the writethrough, and the runtime property dispatch be done in the ManagementViewImpl.

[alesj]

We are missing the setup of the Fields proxy. The fields creation in AbstractManagedObjectFactory needs to be using the org.jboss.managed.plugins.advice.WrapperAdvice.wrapFields utility to allow an advice to update the metadata instance on the setValue call.

Really, aop usage is not needed.

This means removing WrapperAdvice usage?

Where we copy the client side value to the server side property, the Fields impl can handle the writethrough, and the runtime property dispatch be done in the ManagementViewImpl.

I saw we already have WritethroughManagedPropertyImpl, but I think it overrides the wrong method - instead of overridding setField it should override setValue.
Fixing this is exactly what we need + adding runtime dispatch into MVI. And like you said, with no AOP.

On the other hand, keeping the WrapperAdvice, does give you a lot of flexibility. I guess its intention should be clarified.

[alesj]

When I'm running PSUnitTestCase.testUpdateDefaultDS or PSUnitTestCase.testDefaultDSOps I get 107 ManagedComponent instances which match

 ComponentType type = new ComponentType("DataSource", "LocalTx");
 ManagedComponent hsqldb = getManagedComponent(mgtView, type, "DefaultDS");

Guess this is not normal? :-)
And the number keeps on increasing ...

Or is this todo

 // Process the deployments
 // TODO: this should only be done once for a profile

in loadProfile the reason?

[starksm64]

No, components are being added and not removed by the test for this to happen.

[alesj]

Regarding ManagedOperations (MOps).
How can we be sure that the MOps proxy change will take place?
Otherwise client will simply get plain ManagedOperationImpl serialized over.

This is what I questioned myself when trying to correctly impl ManagedPropertys.
Since WritethroughManagedPropertyImpl is exactly what we need on the server side, but we definitely don't want to push/serialize this to the client.
But if I change this similar to MOps, then the server side also sticks with simplified version.

Is there a way/mechanism to serialize something else to the client - other that hacky writeObject that would return not the class instance on which this is implemented.

Or should we transform every server side impl to client side impl on every client call/demand for MObjects, MComponents, ... ?

Or if we eventually used WrapperAdvice for MProps/Fields on server side, how to efficiently change this for the client?

I hope you understand what I'm rambling about. :-)

[alesj]

"alesj" wrote:

Since WritethroughManagedPropertyImpl is exactly what we need on the server side, but we definitely don't want to push/serialize this to the client.

I'm thinking about something similar to this:
I would like to change the serialization marshaler for a particular invocation.
e.g. ManagementView.getComponentsForType(ComponentType type)

 public Set<ManagedComponent> getComponentsForType(ComponentType type)
 throws Exception
 {
 SerializationMarshaller old = SerializationUtil.getCurrentMarshaller();
 try
 {
 SerializationMarshaller wmpi = WMPIClientMarshaler.INSTANCE;
 SerializationUtil.setCurrentMarshaller(wmpi);
 return compByCompType.get(type);
 }
 finally
 {
 SerializationUtil.setCurrentMarshaller(old);
 }
 }

Where the WMPIClientMarshaler would marshall all WritethroughManagedPropertyImpl to ManagedPropertyImpl.

Or is this too hacky?
Or even impossible? :-)

[clebert.suconic]

Wouldn't writeReplace be equivalent?

public class YourServerClass implements SomeClass
{
 // java serialization will take of this replace for you?
 private Object writeReplace()
 {
 return YourClientClass somehow;
 }
}

public class YourClientClass implements SomeClass
{
}

Probably I didn't fully understand your requirements.

[alesj]

Probably I didn't fully understand your requirements.

Wouldn't this mean that I would also get YourClientClass when the seriazalition would take place server-->server?

[clebert.suconic]

You mean server2server on the same server or different servers?

If it's on the same server you will probably pass it by reference, so.. no serialization.


And.. if you correctly implement the protocol, would it matter if it's server2server communication?


I mean.. it won't be easy, as you will probably have to replace the client object by a server object on the server.. so you will have to test it well, but I think this could be done.

[starksm64]

There really is not a usecase for server/server serialization, so the replaceObject approach where the Fields impl is replaced with the simple DefaultFieldsImpl as a value place holder is what we want.