Hi, Thinking a bit further with this.. how about the following approach : -
- The Component model has additional fields called 'implPolicies' and 'implOpPolicies'. 'implPolicies' will capture the intents and policysets directly defined on an implementation element that the component uses. 'implOpPolicies' is a map that is keyed on the implementation Operations. If policies have been specified for specific operations in an implemenation, such intents and policysets will be stored in this map against each operation. - Now the problem is, its the implementation processors that will read up the intents and policysets defined on an implementation element. Would they continue to read them up and store in the implemenation model ? Will we then copy this into the component ? Or should we come up with some sort of a 'context' object that we should be able to pass to the 'read' method of stax processors whereby the stax processors may use information in the context or may set some information into this context object ? Thanks - Venkat On 10/9/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi Sebastien, > > Please find my comments inline. Thanks. > > - Venkat > > On 10/9/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > > > > Venkata Krishnan wrote: > > > Hi, > > > > > > As I am extending policy support for implementations I realize that we > > have > > > trouble with aggregating intents and policysets in an > > JavaImplementation > > > instance. The reason for this is that JavaImplementation instances > > could be > > > reused in cases where two or more components provide services thro the > > same > > > implementation. > > > > > > There is also a JIRA - > > > https://issues.apache.org/jira/browse/TUSCANY-1765that talks of this > > > problem with a nice example. The JIRA has a patch that > > > solves the issue to some extent and not entirely. > > > > > > If JavaImplementaition instances are going to be reused when the same > > > implemenation is used by two or more components, then we need an > > alternative > > > to store the intents / policy sets so that they are unique for each > > > component. Take for example > > > > > > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0 " > > name="CompositeX"> > > > <component name="ComponentA" requires="managedTransaction.none"> > > > <implementation.java class="test.DataServiceImpl" /> > > > </component> > > > <component name="ComponentB" requires="managedTransaction.global"> > > > <implementation.java class="test.DataServiceImpl" r/> > > > </component> > > > </composite> > > > > > > This is what I meant - to highlight the case where implementations inherit > intent specified in it ancestor elements i.e. the component and composite > elements. > > Are you sure that this is what you meant in the example? or did you mean: > > > > <component name="ComponentA"> > > <implementation.java class="test.DataServiceImpl" requires=" > > managedTransaction.none"/> > > </component> > > <component name="ComponentB"> > > <implementation.java class="test.DataServiceImpl" requires=" > > managedTransaction.global"/> > > </component> > > > > > > > Here there is going to be a single instance of JavaImplementation that > > will > > > be used for both components. But it happens that both these > > components have > > > different intents defined and these intents will be inherited by the > > > implementations. At the present moment I can only think of storing > > this > > > info in the Component but I am absolutely uncomfortable with this > > pollutes > > > the assembly model design for 'Component'. Any other ideas that folks > > can > > > suggest for this ? > > > > > > Thanks > > > > > > - Venkat > > > > > > > Intents and policySets specified in component/implementation should not > > be stored in the Implementation model as they actually configure the > > Component and not the Implementation (as reported in JIRA 1765). > > > Yes and I understand your point. But the specs allows for intents and > policysets to be specified directly against implementation elements. So > when we load/read an implementation element from an SCDL it seems we have no > other option but to store this information in the implementation model which > is the only model object we are dealing with when reading up this element. > > Storing them in the Component model makes more sense to me, what wrong > > with doing that? > > > Well :), could we add one more field like 'implIntents' and > 'implPolicySets' to capture the intents and policies specified for the > implementation that this component uses ? I wonder how far we could go with > this approach in case the specs decides to add more embellishments to the > implementation element. > > By the way, we have the same issue with 'Operations' as well. We need to > deal with intents that could be specified for Operations under > implementation, services and reference elements. > > -- > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
