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