geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: Blueprint MBean progress
Date Mon, 16 Nov 2009 09:46:26 GMT
I split the MBean to StateMBean and MetadataMBean because I found there are
really a great many items need to define. And the two seperate MBeans also
make users have a choice when they only wanna track the state of a blueprint
extender, vice versa. I also updated the interfaces based on the above
comments, thanks again:-)

An issue in my mind is how to deal with the exceptions.  To keep coarse
graied with 139, I did not design any new exceptions. eg: if we use the
bundleId as the param of getXXXMetadata(bundleId,componentId) methods,
there are following questions:
1. how about the bundle is not exist or is not a blueprint bundle?  -throws
IllegalArgumentException?
2. how about the bundle is a blueprint bundle but init failed? -return null?
3. how about if the componentId does not represent a component of XXX type
(such as getReferenceMetadata, but the componentId is not a <reference>'s
id)? -throws IOException?

Hence, currently I still use containerServiceId as the argument. such as:
CompositeData getReferenceMetadata(long containerServiceId, String
componentId);
and I plan to:
1. throw IllegalArgumentException if the serviceId is not exist or is not a
blueprint container's serviceid
2. throw IOException if the componentId does not represent a component of
"Reference" type, or maybe return null is better.

-Rex

2009/11/12 Rex Wang <rwonly@gmail.com>

>
>
> 2009/11/12 Guillaume Nodet <gnodet@gmail.com>
>
> 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
>> ...
>>
> Got it. Will add it. thanks :-)
>
> -Rex
>
>
>>
>> On Thu, Nov 12, 2009 at 07:04, Jarek Gawor <jgawor@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 <rwonly@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
>>
>
>

Mime
View raw message