Rex, This is a good start and I think this discussion and code should be happening in Aries. But I do have a few comments/questions:
1) The BEAN_METADATA_TYPE should contain the ARGUMENT_TYPE and PROPERTY_TYPE to mimic the BeanMetadata structure. Therefore, the getBeanArguments() and getBeanProperties() methods shouldn't be necessary. 2) Similarly, the SERVICE_METADATA_TYPE should contain the service properties to mimic the ServiceMetadata structure. And the getServiceProperties() method could be eliminated. 3) The getLastEvent() method will need to take a bundleId because the BlueprintContainer service is only registered at the end when the BlueprintContainer construction is successful. So the service won't be there if the container is currently being created or the construction has failed. But in either case you should be able to get the last event. 4) Because of 3) I think the other methods should also take bundleId instead of containerServiceId. Probably in most cases the users will know the bundleId and that won't have to call getBlueprintContainerServiceId() to convert from bundleId to containerServiceId. 5) Assuming we switch to bundleIds, the getBlueprintContainerServiceId() won't be needed anymore. And also, the getAllBlueprintContainerServiceIds() will need be replaced by a function that returns a list of blueprint bundles (successfully created or not). For example: long[] listBlueprintBundles() 6) From the design of this mbean it looks like it is more associated with the blueprint extender and not so much with a particular BlueprintContainer service. That is, I would expect that there would be one instance of this mbean per blueprint extender (even if there was 100s of BlueprintContainer services). Do I have that right? Thanks, Jarek On Wed, Nov 11, 2009 at 3:48 AM, Rex Wang <rwo...@gmail.com> wrote: > Hi, Dear all, > > I just created my floder "rex" underneath sandbox to post the current design > of BlueprintMBean. If anyone is interesting about it, you can checkout and > help give us some review comments :-) > > You can get the definition by svn co > https://svn.apache.org/repos/asf/geronimo/sandbox/rex/org.apache.geronimo.blueprint.jmx > > The MBean mainly contains two parts of contents. One is about how to > retrieve a blueprint bundles metadata, and the other one is for getting the > last event of a blueprint bundle, which actually represents its state. > Besides, we also define two util methods to help retrieve the > blueprintContainer's service ID from the framework. > > We try keeping the design and code style consistent with the OSGi rfc 139. > So, as the returned compositeData of the above methods, we define 5 > CompositeTypes accordingly, i.e. BEAN_METADATA_TYPE, SERVICE_MATADATA_TYPE, > REFERENCE_METADATA_TYPE, REFERENCE_LIST_METADATA_TYPE, BLUEPRINT_EVENT_TYPE. > What's more, to simplify the data structure, we pull out the ARGUMENT_TYPE > and PROPERTY_TYPE from the BEAN_METADATA_TYPE, and define two independent > methods for them. The other composite types, such as COMPONENT_METADATA_TYPE > and SERVICE_REFERENCE_METADATA_TYPE are just intermediate material to create > Bean, service, reference, and reference-list types. > > The problem is the values. From the bluepirnt spec, the values can appear in > 4 places, that is, BeanArgument, BeanProperty, CollectionMetadata, MapEntry. > That means there should be an item named "VALUE" in the 4 compositeTypes. > But the value type is uncertain. A value can be one of 7 value > types(<value>, <ref>, <idref>, <map>, Collectoins, <props>, <null>) + 4 > manager types(<bean>, <service>, <reference>, <reference-list>). So we have > to create a placeholder type to represent such value item. Hence, if a user > get a compositeData and one of its item has a placeholder type, he need to > iterate all the 11 types to confirm what is the exact one. That is why the > GENERIC_METADATA_TYPE exists. I am not very comfortable on this, but seems > that is the only acceptable solution. (btw, we haven't finished the coding > on the 7 value compositeTypes.) > > Another problem is the namespace. Currently we used > "org.apache.geronimo.blueprint.jmx" as the package name, but I don't know if > there is any concern on it. And we also borrow the Item class and > JmxConstants class from the rfc 139 api. That may not be applicable because > they won't be exported by the 139 api bundle. So we have to create them by > ourselves. Temporarily, you have to check out > https://svn.apache.org/repos/asf/geronimo/sandbox/rex/M2_REPO to help pass > the compilation. > > Ok, that is a brief introduction on what a BlueprintMBean is. Particularly, > thanks Siqi for his help, and any suggestion is appreciated! > > -Rex > > >
