"adrian(a)jboss.org" wrote : | It does need a generic mechanism where the jca created managed object | is able to respond to a request (assuming it is runtime configurable) | "mydatasource".setProperty("max-pool-size", 100); | with a redirect to the MBean (or POJO). | | Only the JCA Deployer knows the ObjectName/Attribute | that "mydatasource"/max-pool-size maps to. | But that ObjectName should not be a part of what the client uses or even cares about. | | That's not to say it can't get help from the real ServiceDeployer to actually | handle the dispatch of the request. | It's only the real ServiceDeployer that knows how the ServiceMetaData | really maps to the runtime objects, i.e. mbeanserver.setAttribute(...); | | But that solution seems like a very long winded and brittle mechanism? | | My preferred solution would be to use KernelBus, but that is not | up-to-date in terms of dispatching MBean/POJO invocations | (Attribute and InvokeDispatchContext). Ok, as we discussed on the call there may not be any interaction in terms of the managed object view between the jca and service deployers, other than, the service deployer should not be assuming that the ServiceDeployment is a managable sar for which it should be creating a management view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066257#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...