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>
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).
Storing them in the Component model makes more sense to me, what wrong
with doing that?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
