tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Laws <simonsl...@googlemail.com>
Subject Re: Issue with policy intents and shared implementations
Date Mon, 13 Jun 2011 10:37:07 GMT
On Mon, Jun 13, 2011 at 3:30 AM, Brent Daniel <brenthdaniel@gmail.com> wrote:
> Hi,
>  Currently, the model resolver caches resolved implementation.java
> instances by class name, so there is only one implementation instance
> for a particular class. This causes problems when a composite contains
> multiple components using the same java implementation class but
> different (and conflicting) intents. We add all of the intents found
> on the implementation definitions in the composite to the single
> resolved implementation instance.
>
> For example:
>
>    <component name="Component_One">
>        <implementation.java
> class="test.sca.service.tx.DataAccessServiceImpl"
> requires="managedTransaction.local"/>
>    </component>
>
>    <component name="Component_Two">
>        <implementation.java
> class="test.sca.service.tx.DataAccessServiceImpl"
> requires="managedTransaction.global"/>
>    </component>
>
> The above configuration will result in an error because the intents
> will be merged together on the shared implementation and
> managedTransaction.global and managedTransaction.local are mutually
> exclusive.
>
> There seems to be a fundamental problem with allowing shared
> implementation objects and keeping SCDL configuration attributes in
> the same object. The easy fix here for the impl.java case would be to
> get rid of the hashCode() override in BaseJavaImplementationImpl so
> that each java implementation will have a separate instance, but is
> this the right fix? And would it cause any problems beyond possible
> performance hits to re-introspect the implementation class, etc?
>
> Brent
>

Hi Brent

This shared implementation approach has been in the code base since
early in 1.x. I can only imagine that the intention is to reduce the
number of times that any particular Java class is parsed to determine
the component type. I note in the code that there have been efforts to
work around it, e.g. from CompositeProcessor.resolve()

                //resolve component implementation
                Implementation implementation = component.getImplementation();
                if (implementation != null) {
                    //now resolve the implementation so that even if
there is a shared instance
                    //for this that is resolved, the specified intents
and policysets are safe in the
                    //component and not lost

                	List<PolicySet> policySets = new
ArrayList<PolicySet>(implementation.getPolicySets());
                	List<Intent> intents = new
ArrayList<Intent>(implementation.getRequiredIntents());
                    implementation =
resolveImplementation(implementation, resolver, context);

                    // If there are any policy sets on the
implementation or component we have to
                    // ignore policy sets from the component type
(policy spec 4.9)
                    if ( !policySets.isEmpty() ||
!component.getPolicySets().isEmpty() ) {
                    	implementation.getPolicySets().clear();

	implementation.getPolicySets().addAll(policySets);
                    }
                    	

implementation.getRequiredIntents().addAll(intents);

                    component.setImplementation(implementation);
                }

The suggestion being that intents/policy sets from the implementation
are cached at the component level. I do vaguely remember some
discussion on this several years ago but I don't know if it was ever
made to work. I guess my initial instinct would be to forgo the
performance benefit of sharing implementation model instances and get
policy right although I can't say what the side effects would be. I'd
also have to do some tests to see whether the "caching at the
component level" thing actually does anything useful.

Am just starting to look at policy again myself to address some other
open JIRAs raised by Gang on the ML so am happy to work with you on
this.

Regards

Simon
-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Mime
View raw message