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 <[email protected]> > > > 2009/11/12 Guillaume Nodet <[email protected]> > > 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 <[email protected]> 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 <[email protected]> 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 >> > >
