[jboss-dev-forums] [Design of POJO Server] - Re: ProfileService todos for deployer changes

"scott.stark(a)jboss.org" wrote : | There can be interaction between multiple ManagedDeploymentCreators. For example, with jca, the factories(the managed components) and properties are determined by the ManagedConnectionFactoryDeploymentGroup metadata, but there are runtime ops and stats that have to come from the ServiceMetaData of the mbeans that the jca layer currently uses as the runtime objects implementing the factories. Those mbeans should not be showing up as some manageable sar, while jms destinations currently are deployed as just a collection of mbeans. | Ok, I mentioned this before, but without any conclusion in how this should work. 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). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066245#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...