2009/11/12 Guillaume Nodet <gno...@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 <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 >
