-
1. Re: ProfileService todos for deployer changes
adrian.brock Jul 19, 2007 1:45 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
+ testJmsDestinationComponents is broken because the ManagedDeployment/ManagedComponent tree cannot be built from the DeploymentUnit or client Deployment view as there is no access to the service descriptor component mbeans. A destinations-service.xml corresponds to multiple mbeans of various component types. In general the component types are unknown. We need to move the ManagedDeployment construction out of the client view of the profile service into a ManagedDeploymentDeployer, and start adding annotations to the other deployers/deployments to identify the component/jsr77 types that are produced.
I don't understand this. The managed objects are built on the server side
by the MainDeployer with the help of the (parsing) deployers.
The client should not be doing anything except asking for the ManagedObjects.
IMHO the "jsr77 types" should be a part of the managed object api.
i.e. you deploy a -ds.xml and you then ask for the managed objects
you get back a set of managed objects which
return "datasource" or "connectionfactory" from
ManagedObject.getType() -
2. Re: ProfileService todos for deployer changes
starksm64 Jul 19, 2007 3:48 PM (in response to starksm64)The ManagedObject api does not reflect the full structure currently. They only map to the attachments managed for a given DeploymentContext. The full structural view is what the ManagedDeployment/ManagedComponent being created by the aspects associated with the ManagementViewImpl provide. I think we are saying the same thing. The ManagedDeployment should be moved into the org.jboss.managed.api package and created on the server side as part of the deployer chain.
-
3. Re: ProfileService todos for deployer changes
starksm64 Jul 20, 2007 10:52 AM (in response to starksm64)The direction I'm currently heading is to generalize the profile service DeployerAspects to build the ManagedDeployment/ManagedComponent tree from the deployment metadata. The metadata handlers would come from the deployers who handle the associated component metadata. A component handler is something like:
public interface ManagedDeploymentCreator<T> { public buildComponents(ManagedDeployment ctx, Set<? extends T> metaData); }
And the *-service.xml component handler would be:public class ServiceMetaDataManagedDeploymentCreator implements ManagedDeploymentCreator<ServiceMetaData> { public void buildComponents(ManagedDeployment ctx, Set<? extends ServiceMetaData> metaData) { ... } }
The DeployerAspects builds up the ManagedDeployment/ManagedComponent graph by calling out to the ManagedDeploymentCreators:public class DeployerAspects { /** The metadata type to ManagedComponent handlers */ private Map<Class, ManagedDeploymentCreator> mdCreators; ... ManagedDeployment md = ...; for(Class mdType : mdCreators.keySet()) { Set metadata = unit.getAllMetaData(mdType); if( metadata == null || metadata.size() == 0 ) continue; ManagedDeploymentCreator creator = mdCreators.get(mdType); creator.buildComponents(md, metadata); }
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. -
4. Re: ProfileService todos for deployer changes
adrian.brock Jul 20, 2007 11:03 AM (in response to starksm64)I don't get the use AOP (DeployerAspects) for this?
This api should be (and already is) part of the main deployers api.
If it is wrong, then it needs changing. -
5. Re: ProfileService todos for deployer changes
starksm64 Jul 20, 2007 11:06 AM (in response to starksm64)It is wrong as the top level DeploymentUnit managed element needs to be a ManagedDeployment, not a ManagedObject instance or set.
-
6. Re: ProfileService todos for deployer changes
adrian.brock Jul 20, 2007 11:19 AM (in response to starksm64)"scott.stark@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). -
7. Re: ProfileService todos for deployer changes
starksm64 Jul 20, 2007 12:05 PM (in response to starksm64)"adrian@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. -
8. Re: ProfileService todos for deployer changes
adrian.brock Jul 20, 2007 12:12 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
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.
One point I didn't state was that we might still actually want
the managable sar view for "power users" who want to see
what is really going on.
But that would require some notion of the managed object
being "synthetic" (i.e. an implementation detail)
so it doesn't appear in the normal management view.
It would just be a "read only" view for debugging purposes,
not something that the profile service would maintain. -
9. Re: ProfileService todos for deployer changes
starksm64 Jul 20, 2007 12:19 PM (in response to starksm64)"adrian@jboss.org" wrote:
One point I didn't state was that we might still actually want
the managable sar view for "power users" who want to see
what is really going on.
Ok, that makes sense. Maybe that is the annotation the jca deployer puts on its resulting ServiceDeployment (a read-only annotation).