I think we should keep this mbean a bit more coarse grained as done
with other services in RFC 139.
So instead of having something like:
CompositeData getLastEvent(long containerServiceId);
I think we should have:
TabularData getLastEvents();
Actually, we could have both, but being able to retrieve the last
event for each managed bundle in a single call is much more scalable
...
On Thu, Nov 12, 2009 at 07:04, Jarek Gawor <jga...@gmail.com> wrote:
> 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
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
