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?
> > 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? 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 > > > > > > >
