Hi Jim, See replay inline.
On 11/17/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi Felix, I committed your patch for Tuscany-927. Thanks a lot! I reformatted it slightly to pass checkstyle. On the QName, issue, yes we can add those to SCAObject but perhaps we should add it to PolicyAttachable instead since not all SCAObjects may have QNames?
Agreed, adding to PolicyAttachable(Model class ) is better than adding to SCAObject. We will make PolicyAttachableObject the base classes for other Model class which can be associated with policy via @requries and/or @policySet attribute, when loaders execute, they should set the values of require intent and policy set name. I still have a question regarding this, in policy framework spec, it says, 1.4.2 Usage of @requires attribute for specifying intents Stating intents with the @requires attribute of an element means that those intents are additionally required by every relevant element descendent. For example, specifying requires="confidentiality" on a <composite> element is the equivalent to adding that same intent to the @requires list of every service and reference that is contained within that composite, including the services and references inside components. So when we want to get the intent name required by an SCA model class (or SCAObject, I'm not sure yet), we need to access the model classes of the every element which are ancestor of the element. But the Model classes do not have a hierarchy and SCAObject's hierarchy highly depends on implementation of the SCAObject, it is not easy to get the ancestor's model classes, any hint?
A couple of small comments: 1. Do you think it would be better to name PolicyModel "PolicyObject" since it is an object that pertains to policies as opposed to a model for them?
Agreed, I renamed it to "PolicyObject".
2. I noticed the is a comment on Intent which says that class is not referenced by model objects but it is in the "model" package. Should this class get moved under the same package as IntentRegistry?
Yes, agreed.
For next steps, let's see if we can start getting the policy infrastructure hooked into the runtime.
Yes, I'm considering this. Another problem is how we keep the scope of intents.xml. My previous thought was to add an URL that points to intents.xml to TuscanyRuntime, but Michael suggested that we'd better not require the user specify a URI, for in the current policy framework design it says that there is one top-level intents.xml file per SCA "system". There is an issue about scope of intents.xml in spec v0502. We may need a more flexible solution, any suggestion? Thanks, Felix
Jim
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
