ManagedOperation aspects for the ProfileService...| JBoss.org Content Archive (Read Only)

30. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Sep 25, 2007 8:13 PM (in response to alesj)

"alesj" wrote:
Weston, what's the status/progress of this?

This is the point of our discussion - guess forum wiki ate it :-)

"alesj" wrote:

Was this fixed?
Code:

*** CONTEXTS IN ERROR: Name -> Error

vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testHq
ldbDS-ds.xml -> org.xml.sax.SAXParseException: Premature end of file.

31. Re: ManagedOperation aspects for the ProfileService.Manageme

starksm64 Sep 25, 2007 8:23 PM (in response to alesj)

"alesj" wrote:

The RuntimeComponentDispatcher will stay, it's the KernelBus that has changed. And by that our RuntimeComponentDispatcher impl has changed as well.

I agree it should go into MVImpl, but what if we are deep into MC impl - which should be PS unaware?

Where is the RuntimeComponentDispatcher, I don't see it in the mc trunk. Its not clear why the PS can't be doing the KernelBus invocation once it has the name and setter for the runtime property.

32. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Sep 25, 2007 8:33 PM (in response to alesj)

"scott.stark@jboss.org" wrote:
Where is the RuntimeComponentDispatcher, I don't see it in the mc trunk.

The RuntimeComponentDispatcher impl is in AS trunk.
I can move it into MC, since all it's components are MC based.

"scott.stark@jboss.org" wrote:
Its not clear why the PS can't be doing the KernelBus invocation once it has the name and setter for the runtime property.

Sure.
But PS need something like MetaDataNameProvider to get the actual runtime component name.

So you want to change this:

ctxProp.setValue((Serializable)prop.getValue());

with the actual runtime invocation - via KernelBus?

33. Re: ManagedOperation aspects for the ProfileService.Manageme

starksm64 Sep 25, 2007 8:35 PM (in response to alesj)

"alesj" wrote:

Changes metadata instance? How, where?
But there is no actual runtime component invocation at the moment, right?

The ManagedProperty Fields implementation needs an advice that catches the setValue call to write the update onto the metadata instance property the field is associated with. This would apply for javabean type of metadata. Other implementations could be specified for different metadata types. 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.

34. Re: ManagedOperation aspects for the ProfileService.Manageme

starksm64 Sep 25, 2007 8:46 PM (in response to alesj)

"alesj" wrote:

But PS need something like MetaDataNameProvider to get the actual runtime component name.

Yes, I don't see that the RuntimeComponentDispatcher should be in the mc. Its ps integration code.

"alesj" wrote:

So you want to change this:
ctxProp.setValue((Serializable)prop.getValue());
with the actual runtime invocation - via KernelBus?

No, we need an aspect that applies to setValue and:
1. writes the value back to the metada instance
2. forwards the value to the KernelBus if its a runtime property.

35. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Sep 25, 2007 8:47 PM (in response to alesj)

Eh ... you beat me to it ... just about to post this. :-)

So we want to update both at the same time: metadata value + runtime component.
Will see what I can do with the proxy.

36. Re: ManagedOperation aspects for the ProfileService.Manageme

starksm64 Sep 25, 2007 8:54 PM (in response to alesj)

Yes. The problem I see with the metadata update is that the Fields api does no t explicitly provide access to the metadata instance. For the case of the AbstractManagedObjectFactory we are pushing the PropertyInfo as the Fields.PROPERTY_INFO, but the instance to which the property applies is not available. Its the ManagedProperty.getManagedObject().getAttachment() value, but DefaultFieldsImpl does not have access to this currently.

37. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Sep 25, 2007 9:01 PM (in response to alesj)

"scott.stark@jboss.org" wrote:
Its the ManagedProperty.getManagedObject().getAttachment() value, but DefaultFieldsImpl does not have access to this currently.

So what do you propose to do here?
Should we push this attachment as another field value into Fields --> Fields.ATTACHMENT? Would this work?

38. Re: ManagedOperation aspects for the ProfileService.Manageme

starksm64 Sep 25, 2007 9:12 PM (in response to alesj)

Yes, I guess that is the right approach.

39. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Sep 26, 2007 1:39 PM (in response to alesj)

"scott.stark@jboss.org" wrote:
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.

Shouldn't be better if we wrapped ManagedProperty in order just to intercept ManagedProperty.setValue(Serializable value);

OK, I guess it would be nice to wrap fields as well.

The question is, should a change of Fields.VALUE value always trigger both changes/invocation as well --> changing metadata property and runtime component.

40. Re: ManagedOperation aspects for the ProfileService.Manageme

starksm64 Sep 26, 2007 2:13 PM (in response to alesj)

"alesj" wrote:

The question is, should a change of Fields.VALUE value always trigger both changes/invocation as well --> changing metadata property and runtime component.

No, only when the value is set on behalf of the profileservice update.

41. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Sep 26, 2007 3:19 PM (in response to alesj)

"scott.stark@jboss.org" wrote:
"alesj" wrote:

The question is, should a change of Fields.VALUE value always trigger both changes/invocation as well --> changing metadata property and runtime component.

No, only when the value is set on behalf of the profileservice update.

Is there a way to write such an aop pointcut that is caller aware?

But it's the ManagedProperty that gets the first hit from profileservice, making ManagedProperty more appropriate to be aspectized for the setValue invocation.

OK, I'll impl something and then we can discuss further. :-)

42. Re: ManagedOperation aspects for the ProfileService.Manageme

starksm64 Sep 27, 2007 4:01 PM (in response to alesj)

Yes, its cflow or something, but I think this will be too expensive. The field implementation actuall needs to know how to update the metadata so a generic aspect is not going to work. The PropertyInfo stuff only works for javabean type of metadata, which is most, but there can be fields for legacy xml based configuration as well. The aspect for the runtime property dispatch is however generic, but this can just be done at the ManagementViewImpl level.

43. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Sep 28, 2007 11:15 AM (in response to alesj)

"scott.stark@jboss.org" wrote:
Yes, its cflow or something, but I think this will be too expensive.

Yup.
- https://svn.jboss.org/repos/jbossas/projects/aop/trunk/aop/docs/examples/cflow/

44. Re: ManagedOperation aspects for the ProfileService.Manageme

alesj Oct 2, 2007 11:18 AM (in response to alesj)

OK, I wrapped ManagedPropertys + Fields.
This in what I currently get:

java.lang.ClassNotFoundException: AOPContainerProxy$26
 at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:82)
 at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:76)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:242)
 at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:174)
 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at java.util.HashMap.readObject(HashMap.java:1067)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at java.util.HashSet.readObject(HashSet.java:278)
 at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
 at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:239)
 at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)
 at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120)
 at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
 at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:943)
 at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:584)
 at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
 at org.jboss.remoting.Client.invoke(Client.java:1550)
 at org.jboss.remoting.Client.invoke(Client.java:530)
 at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at AOPProxy$1.getComponentsForType(AOPProxy$1.java)
 at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.getManagedComponent(ProfileServiceUnitTestCase.java:424)
 at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testUpdateDefaultDS(ProfileServiceUnitTestCase.java:305)

Guess this is because we don't proxy the properties in ManagedViewImpl:

 protected void mergeRuntimeMO(ManagedObject mo, ManagedObject runtimeMO)
 throws Exception
 {
 Map<String, ManagedProperty> moProps = mo.getProperties();
 Set<ManagedOperation> moOps = mo.getOperations();
 HashMap<String, ManagedProperty> props = new HashMap<String, ManagedProperty>(moProps);
 HashSet<ManagedOperation> ops = new HashSet<ManagedOperation>(moOps);

 Map<String, ManagedProperty> runtimeProps = runtimeMO.getProperties();
 Set<ManagedOperation> runtimeOps = runtimeMO.getOperations();

 if (runtimeProps != null)
 props.putAll(runtimeProps);
 if (runtimeOps != null)
 {
 runtimeOps = createOperationProxies(runtimeMO, runtimeOps);
 ops.addAll(runtimeOps);
 }

 ManagedObjectImpl moi = (ManagedObjectImpl) mo;
 moi.setProperties(props);
 moi.setOperations(ops);
 }

And the server proxy cannot be resolved on client side. :-)