geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <>
Subject Re: Blueprint MBean progress
Date Thu, 12 Nov 2009 06:04:01 GMT

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

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

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

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?


On Wed, Nov 11, 2009 at 3:48 AM, Rex Wang <> 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
> 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,
> 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
> 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

View raw message