On Thu, Nov 12, 2009 at 08:50, Rex Wang <rwo...@gmail.com> wrote: > > > 2009/11/12 Jarek Gawor <jga...@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-...@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 <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
