geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Blueprint MBean progress
Date Wed, 11 Nov 2009 08:48:25 GMT
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!


View raw message