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 Tue, 14 Jun 2011 09:40:24 GMT
On Mon, Jun 13, 2011 at 11:37 AM, Simon Laws <simonslaws@googlemail.com> wrote:
> 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
>

As a follow up I just noticed that when the implementation policy
interceptors are added to the wire in
RuntimeEndpointImpl.addImplementationInterceptor() it does the
following.

        // TODO - EPR - don't we need to get the policy from the right
level in the
        //              model rather than the leafmost level
        List<PolicyProvider> pps =
((RuntimeComponent)component).getPolicyProviders();
        if (pps != null) {
            for (PolicyProvider p : pps) {
                Interceptor interceptor = p.createInterceptor(operation);
                if (interceptor != null) {
                    chain.addInterceptor(interceptor);
                }
            }
        }

I'm pretty sure though that the code earlier on in the processing
isn't promoting implementation policy to the component correctly.
Maybe I'm just looking in the wrong place. A test case is called for.

Simon

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

Mime
View raw message