geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Blueprint MBean progress
Date Thu, 12 Nov 2009 08:42:55 GMT
On Thu, Nov 12, 2009 at 08:50, Rex Wang <rwonly@gmail.com> wrote:
>
>
> 2009/11/12 Jarek Gawor <jgawor@gmail.com>
>>
>> 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:
>
> Thank you very much! I also hope our work can be pushed to Aries when we
> feel the design is good enough..And I am not idea how to contribute this to
> Aries?

Just subscribe to aries-dev@incuabator.apache.org ...

>>
>> 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.
>
> OK.  Seems our original thinking that decentralized the data is not
> comfortable.
>>
>> 2) Similarly, the SERVICE_METADATA_TYPE should contain the service
>> properties to mimic the ServiceMetadata structure. And the
>> getServiceProperties() method could be eliminated.
>
> OK
>>
>> 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.
>
> Yes! You are right, that's my fault.
>>
>> 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.
>
> Actually, we ever thought to change the argument from serviceId to bundleId.
> But if a user input a bundleId which is not belongs to a blueprint bundle,
> or the blueprint bundle inited failed. It will be a little bit agonizing to
> provide different error messages(or Exceptions). Using serviceId also have
> such problems, but user will prefer to call getBlueprintContainerServiceId()
> to get the serviceId first and then invoke the rest methods, because there
> are really very limited ways to get that. Then we can just throw IOException
> just like what they did in rfc 139 ServiceStateMBean. Is that acceptable?
>>
>> 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()
>
> Yes, we need such method. Will add it.
>>
>> 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?
>
> I am not sure if I understand this. Can we have more than 1 blueprint
> extender in a single framework?

It is possible, though not very well supported.   If all blueprint
bundles actually import the org.osgi.service.blueprint package, it
should be ok, as a given extender will only extend the bundles that
are wired to this extender (assuming the extender always export the
package and do not import it from another bundle).

> Thanks again, Jarek :-)
> -Rex
>
>>
>> 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