XMBean design question

[ritesh]

Hi,

I have a situation where I need to specify getMethod, setMethod in the descriptor of the AttributeInfo class to have a method which takes in parameters since I want to use existing management operation to get and set value of that attribute!

The problem is, I dont think one can do that, since descriptor only takes getMethod with no argument since it doesnt know what parameter to pass when setAttribute, getAttribute is called through the agent.

Has anyone come across this situation? any solution?

Thanks.

Ritesh

[juha]

You could try to build your own custom interceptor for this case, where you add additional descriptors to the attribute including the argument values you want to pass to the getter operation. In the interceptor include logic to invoke the operation with the correct signature and values.

Might be possible to generalize this kind of functionality as well, will have to think about it.

-- Juha

[juha]

soo.. we could have a descriptor "complexGetter" (I couldn't come up with a better name at the moment) that takes a List as its value, the list containing for example a type, value pairs for the additional operation arguments. Then implement an interceptor that reacts to this new descriptor field and builds a correct operation invocation based on it.

-- Juha

[ritesh]

How about if we have a descriptor called "ParameterizedDescriptorSupport" which extends DescriptorSupport and which lets you specify "DescriptorInvocation", which extends Invocation, for any field(s) in the descriptor. With this we will be able to pass parameters, signature etc... to any field in the descriptor at run time.

Then we write an interceptor which intercepts ATTRIBUTE type invocations and checks to see if the getMethod, setMethod fields are set for the attribute and if DescriptorInvocation is specified for those field. if it has then call the correct management operation if not do same as MBeanAttributeInterceptor.

Hope u get the idea.

Ritesh

[ritesh]

I was looking at the interceptors and one thing I dont understand is, if the interceptor decides to process the invocation at the end of it why doesnt it call the next one in line ? so I guess the more general questions is what are the rules when someone wants to write their own interceptors ?

Thanks.

Ritesh

[juha]

I assume you're talking about the attribute-operation mapping for ModelMBeans in this case..

When an attribute is invoked, the invocation is passed through the configured stack of interceptors. Once it gets to the mapping interceptor, the invocation is turned into a corresponding operation invocation. This means the invocation is set back to the "top" of the stack (in the invoker) so it will be forced to travel through all the interceptor layers of that operation (including security for instance).

We will later convert this design so that the invocation object itself contains the reference to its next interceptor as was prototyped by Trevor. This will make it a bit clearer.

-- Juha

[ritesh]

But thats not always true.

Lets say I am a interceptor writer and have my own interceptor plugged in using insert method in interceptor and I just want to do my thing and not worry about even looking at what other interceptors do, so the ideal thing is I do my thing in my interceptor and pass the control over to the next one in line, to let it do its own thing.

But I have seen interceptors like MBeanAttributeInterceptor, they dont trasfer the control to the next plugged in interceptor in the stack after they are done processing ! Interceptors like that may be an exception but thats not the correct design since what if someone were to plug in their interceptor immediately after MBeanAttributeInterceptor ?

This is just an observation, since I have spent lot of time looking at the code.

Thanks.

Ritesh

[davidjencks]

Interceptors are not commutative. Set up your interceptor stack carefully so the additional behavior each provides occurs in the correct order for the effect you want to produce.

In other words you can't just put another interceptor in the stack anywhere and expect anything to work, you have to look at what the others do.

[juha]

agree with David

take a real world example, like JBoss ejb container, the interceptor stack ends up being pretty static in 95% of cases.

for the rest 5%, you could spend time doing fancy designs to support them, or you can just say "developer beware".