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 Thu, 12 Nov 2009 09:27:48 GMT
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