Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:COSMOS Bug Design 209248"
(New page: Do we have a complete list of the Muse annotations? It would be good if we had an “Management Annotations Reference Page” on the wiki--a glossary of annotations if you will. It would...) |
|||
| Line 1: | Line 1: | ||
Do we have a complete list of the Muse annotations? It would be good if we had an “Management Annotations Reference Page” on the wiki--a glossary of annotations if you will. It would be good to indicate the annotations that affect an external interface, e.g. “ManagedResourceCapability” vs. one that supports the framework “Autowire”. | Do we have a complete list of the Muse annotations? It would be good if we had an “Management Annotations Reference Page” on the wiki--a glossary of annotations if you will. It would be good to indicate the annotations that affect an external interface, e.g. “ManagedResourceCapability” vs. one that supports the framework “Autowire”. | ||
Can we java doc this and just use that? | Can we java doc this and just use that? | ||
| + | |||
| + | <Joel>I think a wiki page makes sense. Currently the annotations are all in an "annotations" package, so they're pretty easy to find. I can add some verbiage to the javadoc to indicate the external impact of each annotation.</Joel> | ||
Why does the ManagedResourceCapability need to know if it’s composable or not? There could be situations where the capability can be used in either way. DataBroker may be an example. The DataBroker is essentially composing in a custom DataBroker capability with Service Groups. However, there could be another DataBroker that does not use service groups. Given this, why do we have to know? Why not just always make it composable? | Why does the ManagedResourceCapability need to know if it’s composable or not? There could be situations where the capability can be used in either way. DataBroker may be an example. The DataBroker is essentially composing in a custom DataBroker capability with Service Groups. However, there could be another DataBroker that does not use service groups. Given this, why do we have to know? Why not just always make it composable? | ||
| + | |||
| + | <Joel> The composible option is there to give users the ability to opt-in to a composition scheme. Hubert had a similiar question when I presented this on the DC call, and we agreed to switch the polarity on composible to opt-out, so by default all ManagedResourceCapability annotations are composable. It's just a question of control. Since you can annotate a class as well as an interface, someone may want to keep their implementation to themselves. </Joel> | ||
Will the Muse resource router implement the ComposableManagedCapabilitySet interface? It might be a good fit to introduce an annotated router that does the composition. | Will the Muse resource router implement the ComposableManagedCapabilitySet interface? It might be a good fit to introduce an annotated router that does the composition. | ||
| + | |||
| + | <Joel> Interesting thought. Muse doesn't currently expose the resource router itself, but I see no real reason not to. Are you thinking of decorating it with some MOWS interfaces?</Joel> | ||
Will you elaborate on the “singleton requirement for CMDBf”? I’m not sure I’m following what you are referring to. We will have more than one MDR in the systems, so making that a singleton does not make sense? I suppose it’s conceivable that we would have multiple federating CMDBs in a system as well (although this does seem much less likely). | Will you elaborate on the “singleton requirement for CMDBf”? I’m not sure I’m following what you are referring to. We will have more than one MDR in the systems, so making that a singleton does not make sense? I suppose it’s conceivable that we would have multiple federating CMDBs in a system as well (although this does seem much less likely). | ||
| + | |||
| + | <Joel>This was the issue with CMDBf specifying it's remote interface without addressing information. The Singlton aspect was within the scope of a ResourceRouter.</Joel> | ||
Is there a way to get to the Muse deployment descriptor? Are there options available in this that we might want to expose. Maybe a combination of an autowire target and a factory.... | Is there a way to get to the Muse deployment descriptor? Are there options available in this that we might want to expose. Maybe a combination of an autowire target and a factory.... | ||
| + | |||
| + | <Joel>For annotations, there is no deployment descriptor - it's all generated on the fly. If we're going to put a management interface on the resource router, maybe that's a good place to provide deployment descriptor-level functionality. I like the concept, I just need to think about what's involved...</Joel> | ||
When & where do the binding rules apply? Are they used by the factory? | When & where do the binding rules apply? Are they used by the factory? | ||
| + | |||
| + | <Joel>Binding rules apply whenever a managed resource is handed to the ContributionManager. Since a factory would wind up handing it's output to the ContributionManager, then yes, the factory would essentially use the binding rules. </Joel> | ||
Can we follow on this doc with a very simple example of the things that we talk about? | Can we follow on this doc with a very simple example of the things that we talk about? | ||
| + | |||
| + | <Joel>I was thinking of doing that with the WSDM properties we automagically add today. Of course, I'll also have test cases that will exercise this with generic interfaces/classes.</Joel> | ||
Latest revision as of 09:17, 28 November 2007
Do we have a complete list of the Muse annotations? It would be good if we had an “Management Annotations Reference Page” on the wiki--a glossary of annotations if you will. It would be good to indicate the annotations that affect an external interface, e.g. “ManagedResourceCapability” vs. one that supports the framework “Autowire”. Can we java doc this and just use that?
<Joel>I think a wiki page makes sense. Currently the annotations are all in an "annotations" package, so they're pretty easy to find. I can add some verbiage to the javadoc to indicate the external impact of each annotation.</Joel>
Why does the ManagedResourceCapability need to know if it’s composable or not? There could be situations where the capability can be used in either way. DataBroker may be an example. The DataBroker is essentially composing in a custom DataBroker capability with Service Groups. However, there could be another DataBroker that does not use service groups. Given this, why do we have to know? Why not just always make it composable?
<Joel> The composible option is there to give users the ability to opt-in to a composition scheme. Hubert had a similiar question when I presented this on the DC call, and we agreed to switch the polarity on composible to opt-out, so by default all ManagedResourceCapability annotations are composable. It's just a question of control. Since you can annotate a class as well as an interface, someone may want to keep their implementation to themselves. </Joel>
Will the Muse resource router implement the ComposableManagedCapabilitySet interface? It might be a good fit to introduce an annotated router that does the composition.
<Joel> Interesting thought. Muse doesn't currently expose the resource router itself, but I see no real reason not to. Are you thinking of decorating it with some MOWS interfaces?</Joel>
Will you elaborate on the “singleton requirement for CMDBf”? I’m not sure I’m following what you are referring to. We will have more than one MDR in the systems, so making that a singleton does not make sense? I suppose it’s conceivable that we would have multiple federating CMDBs in a system as well (although this does seem much less likely).
<Joel>This was the issue with CMDBf specifying it's remote interface without addressing information. The Singlton aspect was within the scope of a ResourceRouter.</Joel>
Is there a way to get to the Muse deployment descriptor? Are there options available in this that we might want to expose. Maybe a combination of an autowire target and a factory....
<Joel>For annotations, there is no deployment descriptor - it's all generated on the fly. If we're going to put a management interface on the resource router, maybe that's a good place to provide deployment descriptor-level functionality. I like the concept, I just need to think about what's involved...</Joel>
When & where do the binding rules apply? Are they used by the factory?
<Joel>Binding rules apply whenever a managed resource is handed to the ContributionManager. Since a factory would wind up handing it's output to the ContributionManager, then yes, the factory would essentially use the binding rules. </Joel>
Can we follow on this doc with a very simple example of the things that we talk about?
<Joel>I was thinking of doing that with the WSDM properties we automagically add today. Of course, I'll also have test cases that will exercise this with generic interfaces/classes.</Joel>