You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Brent Daniel <br...@gmail.com> on 2011/06/13 04:30:40 UTC
Issue with policy intents and shared implementations
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
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>
>
> In my local Eclipse environment it's running into the Jaxws code that
> calls the test client but never arriving at the service that the test
> client offers. Don't know why yet.
>
> Simon
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Ok, so this seems to be caused by a change I made to the WS binding
context configuration. If fails to find some information in the async
response path case and fails with an exception. Hence the client waits
for a response that never arrives. Interesting, although and exception
is thrown, the ResponseDispatchImpl.sendResponse() swallows it. The
test therefore waits forever for apparently no reason.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jun 28, 2011 at 12:35 PM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Jun 28, 2011 at 12:25 PM, ant elder <an...@apache.org> wrote:
>> It also looks like JCA_11017_TestCase is hanging in the async callback
>> test. Thats on Hudson and i can see it locally too.
>>
>> ...ant
>>
>> On Tue, Jun 28, 2011 at 9:46 AM, Simon Laws <si...@googlemail.com> wrote:
>>> On Tue, Jun 28, 2011 at 9:40 AM, ant elder <an...@gmail.com> wrote:
>>>> There are still several build fails in the policy compliance tests,
>>>> testing/itest/oneway, and testing/itest/ws/authentication-basic.
>>>> Should i take these out of the build while the policy work goes on?
>>>
>>> Thanks for the heads up Ant. I thought it was just the three
>>> compliance failures (which I'm looking at). Let me do a completely
>>> fresh build and see what comes up.
>>>
>>> Simon
>>>
>>> --
>>> Apache Tuscany committer: tuscany.apache.org
>>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>>
>>
>
> Yes, I see that too in the build I kicked off this morning.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
In my local Eclipse environment it's running into the Jaxws code that
calls the test client but never arriving at the service that the test
client offers. Don't know why yet.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jun 28, 2011 at 12:25 PM, ant elder <an...@apache.org> wrote:
> It also looks like JCA_11017_TestCase is hanging in the async callback
> test. Thats on Hudson and i can see it locally too.
>
> ...ant
>
> On Tue, Jun 28, 2011 at 9:46 AM, Simon Laws <si...@googlemail.com> wrote:
>> On Tue, Jun 28, 2011 at 9:40 AM, ant elder <an...@gmail.com> wrote:
>>> There are still several build fails in the policy compliance tests,
>>> testing/itest/oneway, and testing/itest/ws/authentication-basic.
>>> Should i take these out of the build while the policy work goes on?
>>
>> Thanks for the heads up Ant. I thought it was just the three
>> compliance failures (which I'm looking at). Let me do a completely
>> fresh build and see what comes up.
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>
>
Yes, I see that too in the build I kicked off this morning.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by ant elder <an...@apache.org>.
It also looks like JCA_11017_TestCase is hanging in the async callback
test. Thats on Hudson and i can see it locally too.
...ant
On Tue, Jun 28, 2011 at 9:46 AM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Jun 28, 2011 at 9:40 AM, ant elder <an...@gmail.com> wrote:
>> There are still several build fails in the policy compliance tests,
>> testing/itest/oneway, and testing/itest/ws/authentication-basic.
>> Should i take these out of the build while the policy work goes on?
>
> Thanks for the heads up Ant. I thought it was just the three
> compliance failures (which I'm looking at). Let me do a completely
> fresh build and see what comes up.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jun 28, 2011 at 9:40 AM, ant elder <an...@gmail.com> wrote:
> There are still several build fails in the policy compliance tests,
> testing/itest/oneway, and testing/itest/ws/authentication-basic.
> Should i take these out of the build while the policy work goes on?
Thanks for the heads up Ant. I thought it was just the three
compliance failures (which I'm looking at). Let me do a completely
fresh build and see what comes up.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by ant elder <an...@gmail.com>.
There are still several build fails in the policy compliance tests,
testing/itest/oneway, and testing/itest/ws/authentication-basic.
Should i take these out of the build while the policy work goes on?
...ant
On Wed, Jun 22, 2011 at 1:30 PM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Jun 21, 2011 at 8:07 PM, Brent Daniel <br...@gmail.com> wrote:
>> On Tue, Jun 21, 2011 at 6:59 AM, Simon Laws <si...@googlemail.com> wrote:
>>> Ok, I just checked with Dave Booz from the policy spec team and the
>>> intention is the following:
>>>
>>> - the attachTo and appliesTo processing are independent
>>> - it is binding implementations or implementation type implementations
>>> that act on attached policysets after attachTo and appliesTo have been
>>> resolved
>>> - the appliesTo XPath expression can point to elements other than
>>> bindings or implementation elements in which case you look to the
>>> child elements to find a binding or implementation element
>>>
>>> So, from POL_4005
>>>
>>> <policySet name="Qual1PolicySet"
>>> provides="test:testImplIntent.qual1" appliesTo="//service"
>>> attachTo="//sca:component[@name='TEST_POL_4005Component1']/sca:service[@name='Service1']">
>>> <!-- This policy intentionally left blank -->
>>> </policySet>
>>>
>>> This policySet appliesTo all of the bindings of all of the services in
>>> the composite.
>>>
>>> - you could configure a policy set so that it applies to
>>> implementations and bindings, e.g. set appliesTo to point to a
>>> component, but this is likely to lead to errors as policy sets will
>>> normally be specific to an implementation or a binding. Having said
>>> that in Tuscany the runtime can still treats policy sets somewhat
>>> independently to add generic interceptors to wires so we may still
>>> want to maintain this ability as an extension to the specs
>>>
>>> So in short we do need to rework the appliesTo processing.
>>>
>>
>> I've reworked things based on this clarification and committed it in
>> rev 1138105. This is causing three new compliance test failures, but I
>> think in all three cases the issue is in the test suite.
>>
>> In POL_4003, "ExtPolicySet" only applies to binding.sca, but the
>> reference where the intent is specified will use binding.ws.
>>
>> In POL_4024, "PolicySet1" only applies to binding.ws, but the
>> reference will use binding.sca.
>>
>> POL_4020 also fails because the appliesTo is not specifying the
>> namespace for binding.sca. This is actually a pretty pervasive problem
>> across many of the policy tests, but seems to only affect this test.
>>
>> Brent
>>
>
> Hi Brent
>
> I'm seeing quite a lot of failures on the latest code. Are you seeing the same?
>
> 22.131s]
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA iTest Policy Matching (during insta
> ll)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policy/matching/targe
> t/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA iTest Policy WS-Policy (during inst
> all)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policy/wspolicy/targe
> t/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA iTest Policies (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policies/target/suref
> ire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Asse
> mbly (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/assembly/t
> arget/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Java
> CAA (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/java-caa/t
> arget/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Java
> CI (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/java-ci/ta
> rget/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Poli
> cy (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/policy/tar
> get/surefire-reports for the individual test results.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Jun 22, 2011 at 1:30 PM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Jun 21, 2011 at 8:07 PM, Brent Daniel <br...@gmail.com> wrote:
>> On Tue, Jun 21, 2011 at 6:59 AM, Simon Laws <si...@googlemail.com> wrote:
>>> Ok, I just checked with Dave Booz from the policy spec team and the
>>> intention is the following:
>>>
>>> - the attachTo and appliesTo processing are independent
>>> - it is binding implementations or implementation type implementations
>>> that act on attached policysets after attachTo and appliesTo have been
>>> resolved
>>> - the appliesTo XPath expression can point to elements other than
>>> bindings or implementation elements in which case you look to the
>>> child elements to find a binding or implementation element
>>>
>>> So, from POL_4005
>>>
>>> <policySet name="Qual1PolicySet"
>>> provides="test:testImplIntent.qual1" appliesTo="//service"
>>> attachTo="//sca:component[@name='TEST_POL_4005Component1']/sca:service[@name='Service1']">
>>> <!-- This policy intentionally left blank -->
>>> </policySet>
>>>
>>> This policySet appliesTo all of the bindings of all of the services in
>>> the composite.
>>>
>>> - you could configure a policy set so that it applies to
>>> implementations and bindings, e.g. set appliesTo to point to a
>>> component, but this is likely to lead to errors as policy sets will
>>> normally be specific to an implementation or a binding. Having said
>>> that in Tuscany the runtime can still treats policy sets somewhat
>>> independently to add generic interceptors to wires so we may still
>>> want to maintain this ability as an extension to the specs
>>>
>>> So in short we do need to rework the appliesTo processing.
>>>
>>
>> I've reworked things based on this clarification and committed it in
>> rev 1138105. This is causing three new compliance test failures, but I
>> think in all three cases the issue is in the test suite.
>>
>> In POL_4003, "ExtPolicySet" only applies to binding.sca, but the
>> reference where the intent is specified will use binding.ws.
>>
>> In POL_4024, "PolicySet1" only applies to binding.ws, but the
>> reference will use binding.sca.
>>
>> POL_4020 also fails because the appliesTo is not specifying the
>> namespace for binding.sca. This is actually a pretty pervasive problem
>> across many of the policy tests, but seems to only affect this test.
>>
>> Brent
>>
>
> Hi Brent
>
> I'm seeing quite a lot of failures on the latest code. Are you seeing the same?
>
> 22.131s]
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA iTest Policy Matching (during insta
> ll)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policy/matching/targe
> t/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA iTest Policy WS-Policy (during inst
> all)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policy/wspolicy/targe
> t/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA iTest Policies (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policies/target/suref
> ire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Asse
> mbly (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/assembly/t
> arget/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Java
> CAA (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/java-caa/t
> arget/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Java
> CI (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/java-ci/ta
> rget/surefire-reports for the individual test results.
> [INFO] ------------------------------------------------------------------------
> [INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Poli
> cy (during install)
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/policy/tar
> get/surefire-reports for the individual test results.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
I've just started at the top and what I'm finding in the matching test
is that the test is wrong. The policies used to read something like...
<policySet name="testPolicy3"
provides="tuscany:testIntent6"
appliesTo="//binding | //implementation">
When what they should be is more like...
<policySet name="testPolicy3"
provides="tuscany:testIntent6"
appliesTo="//sca:binding.sca | //sca:implementation.java">
There is also an issue in the appliesTo calculation that removes
policy sets from references that are not yet resolved. Am looking at a
fix for that. It's always had that fault and is not due to the recent
changes.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jun 21, 2011 at 8:07 PM, Brent Daniel <br...@gmail.com> wrote:
> On Tue, Jun 21, 2011 at 6:59 AM, Simon Laws <si...@googlemail.com> wrote:
>> Ok, I just checked with Dave Booz from the policy spec team and the
>> intention is the following:
>>
>> - the attachTo and appliesTo processing are independent
>> - it is binding implementations or implementation type implementations
>> that act on attached policysets after attachTo and appliesTo have been
>> resolved
>> - the appliesTo XPath expression can point to elements other than
>> bindings or implementation elements in which case you look to the
>> child elements to find a binding or implementation element
>>
>> So, from POL_4005
>>
>> <policySet name="Qual1PolicySet"
>> provides="test:testImplIntent.qual1" appliesTo="//service"
>> attachTo="//sca:component[@name='TEST_POL_4005Component1']/sca:service[@name='Service1']">
>> <!-- This policy intentionally left blank -->
>> </policySet>
>>
>> This policySet appliesTo all of the bindings of all of the services in
>> the composite.
>>
>> - you could configure a policy set so that it applies to
>> implementations and bindings, e.g. set appliesTo to point to a
>> component, but this is likely to lead to errors as policy sets will
>> normally be specific to an implementation or a binding. Having said
>> that in Tuscany the runtime can still treats policy sets somewhat
>> independently to add generic interceptors to wires so we may still
>> want to maintain this ability as an extension to the specs
>>
>> So in short we do need to rework the appliesTo processing.
>>
>
> I've reworked things based on this clarification and committed it in
> rev 1138105. This is causing three new compliance test failures, but I
> think in all three cases the issue is in the test suite.
>
> In POL_4003, "ExtPolicySet" only applies to binding.sca, but the
> reference where the intent is specified will use binding.ws.
>
> In POL_4024, "PolicySet1" only applies to binding.ws, but the
> reference will use binding.sca.
>
> POL_4020 also fails because the appliesTo is not specifying the
> namespace for binding.sca. This is actually a pretty pervasive problem
> across many of the policy tests, but seems to only affect this test.
>
> Brent
>
Hi Brent
I'm seeing quite a lot of failures on the latest code. Are you seeing the same?
22.131s]
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA iTest Policy Matching (during insta
ll)
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policy/matching/targe
t/surefire-reports for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA iTest Policy WS-Policy (during inst
all)
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policy/wspolicy/targe
t/surefire-reports for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA iTest Policies (during install)
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /home/simonlaws/sca-java-2.x/testing/itest/policies/target/suref
ire-reports for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Asse
mbly (during install)
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/assembly/t
arget/surefire-reports for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Java
CAA (during install)
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/java-caa/t
arget/surefire-reports for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Java
CI (during install)
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/java-ci/ta
rget/surefire-reports for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests Poli
cy (during install)
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /home/simonlaws/sca-java-2.x/testing/compliance-tests/policy/tar
get/surefire-reports for the individual test results.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Brent Daniel <br...@gmail.com>.
On Tue, Jun 21, 2011 at 6:59 AM, Simon Laws <si...@googlemail.com> wrote:
> Ok, I just checked with Dave Booz from the policy spec team and the
> intention is the following:
>
> - the attachTo and appliesTo processing are independent
> - it is binding implementations or implementation type implementations
> that act on attached policysets after attachTo and appliesTo have been
> resolved
> - the appliesTo XPath expression can point to elements other than
> bindings or implementation elements in which case you look to the
> child elements to find a binding or implementation element
>
> So, from POL_4005
>
> <policySet name="Qual1PolicySet"
> provides="test:testImplIntent.qual1" appliesTo="//service"
> attachTo="//sca:component[@name='TEST_POL_4005Component1']/sca:service[@name='Service1']">
> <!-- This policy intentionally left blank -->
> </policySet>
>
> This policySet appliesTo all of the bindings of all of the services in
> the composite.
>
> - you could configure a policy set so that it applies to
> implementations and bindings, e.g. set appliesTo to point to a
> component, but this is likely to lead to errors as policy sets will
> normally be specific to an implementation or a binding. Having said
> that in Tuscany the runtime can still treats policy sets somewhat
> independently to add generic interceptors to wires so we may still
> want to maintain this ability as an extension to the specs
>
> So in short we do need to rework the appliesTo processing.
>
I've reworked things based on this clarification and committed it in
rev 1138105. This is causing three new compliance test failures, but I
think in all three cases the issue is in the test suite.
In POL_4003, "ExtPolicySet" only applies to binding.sca, but the
reference where the intent is specified will use binding.ws.
In POL_4024, "PolicySet1" only applies to binding.ws, but the
reference will use binding.sca.
POL_4020 also fails because the appliesTo is not specifying the
namespace for binding.sca. This is actually a pretty pervasive problem
across many of the policy tests, but seems to only affect this test.
Brent
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jun 21, 2011 at 2:05 PM, Simon Laws <si...@googlemail.com> wrote:
>> The spec could certainly stand to be a bit more explicit here. :) It
>> does seem to make more sense to limit it to bindings and
>> implementations, so I agree that we should look into changing the
>> appliesTo builder. I do notice there are several compliance tests
>> using @appliesTo attributes that specify service, component, or
>> composite, though (POL_4005 through 4009.)
>>
>
> Ok, that's interesting. I think we should check with OASIS before
> making further changes. I'll see if I can track down someone.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Ok, I just checked with Dave Booz from the policy spec team and the
intention is the following:
- the attachTo and appliesTo processing are independent
- it is binding implementations or implementation type implementations
that act on attached policysets after attachTo and appliesTo have been
resolved
- the appliesTo XPath expression can point to elements other than
bindings or implementation elements in which case you look to the
child elements to find a binding or implementation element
So, from POL_4005
<policySet name="Qual1PolicySet"
provides="test:testImplIntent.qual1" appliesTo="//service"
attachTo="//sca:component[@name='TEST_POL_4005Component1']/sca:service[@name='Service1']">
<!-- This policy intentionally left blank -->
</policySet>
This policySet appliesTo all of the bindings of all of the services in
the composite.
- you could configure a policy set so that it applies to
implementations and bindings, e.g. set appliesTo to point to a
component, but this is likely to lead to errors as policy sets will
normally be specific to an implementation or a binding. Having said
that in Tuscany the runtime can still treats policy sets somewhat
independently to add generic interceptors to wires so we may still
want to maintain this ability as an extension to the specs
So in short we do need to rework the appliesTo processing.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
> The spec could certainly stand to be a bit more explicit here. :) It
> does seem to make more sense to limit it to bindings and
> implementations, so I agree that we should look into changing the
> appliesTo builder. I do notice there are several compliance tests
> using @appliesTo attributes that specify service, component, or
> composite, though (POL_4005 through 4009.)
>
Ok, that's interesting. I think we should check with OASIS before
making further changes. I'll see if I can track down someone.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Brent Daniel <br...@gmail.com>.
On Mon, Jun 20, 2011 at 8:57 AM, Simon Laws <si...@googlemail.com> wrote:
>
> While I agree that you can attach to anywhere I doesn't seem to make
> sense to applyTo anywhere but bindings and implementations. The spec
> says....
>
> 388 PolicySet authors need to be aware of the evaluation of the
> @appliesTo attribute in order to designate
> 389 meaningful values for this attribute. Although policySets can be
> attached to any element in an SCA
> 390 composite, the applicability of a policySet is not scoped by where
> it is attached in the SCA framework.
> 391 Rather, policySets always apply to either binding instances or
> implementation elements regardless of where they are attached.
>
> So while technically you can describe and XPath statement that points
> to anywhere in the composite I don't know what it means if the
> appliesTo field doesn't point to an implementation or a binding.
>
The spec could certainly stand to be a bit more explicit here. :) It
does seem to make more sense to limit it to bindings and
implementations, so I agree that we should look into changing the
appliesTo builder. I do notice there are several compliance tests
using @appliesTo attributes that specify service, component, or
composite, though (POL_4005 through 4009.)
The compliance test failures seem to be a result of a change I made to
avoid pushing implementation intents to endpoints. I've backed that
change out and things seem to be OK now
Brent
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
>
> A) I disagree that we only have to check the binding. The appliesTo
> XPath expression could potentially point to any element in the
> composite. Also, consider the case where an intent is specified on a
> higher level element:
> <service requires="myIntent">
> <binding.ws>
> </service>
>
> "myIntent" could potentially not apply here, but we wouldn't be
> checking it if we only check the binding.
While I agree that you can attach to anywhere I doesn't seem to make
sense to applyTo anywhere but bindings and implementations. The spec
says....
388 PolicySet authors need to be aware of the evaluation of the
@appliesTo attribute in order to designate
389 meaningful values for this attribute. Although policySets can be
attached to any element in an SCA
390 composite, the applicability of a policySet is not scoped by where
it is attached in the SCA framework.
391 Rather, policySets always apply to either binding instances or
implementation elements regardless of where they are attached.
So while technically you can describe and XPath statement that points
to anywhere in the composite I don't know what it means if the
appliesTo field doesn't point to an implementation or a binding.
>
> B) The binding policy sets will not encompass the full set of policy
> sets inherited by the endpoint, but the idea is that we will check
> every element that the endpoint has inherited from (I don't think this
> is correct today, as the component is missing.)
The endpoint should contain all of the policy sets that are applicable
to the binding up to this stage. The "inheritance" processing uses the
endpoint as the point of aggregation.
>
> C) It's called from within the loop because "policySetsToRemove" is
> the set of policy sets on the service which do not apply to the
> endpoint, and it needs to be removed from each endpoint underneath the
> service.
Ah OK, I get it. I still don't think we need it though.
> The code you listed I think would be correct if we assume that
> appliesTo can only reference a binding element (and implementations,
> though we don't care about that here.) Maybe we should be doing this
> (it would make sense), but without that limit in the spec I don't
> think we can assume it.
I think that is what the spec says.
>
> I'll take a look at the CTS failures.. I wouldn't expect them to be
> related to the changes to the appliesTo builder because those should
> only affect services with multiple endpoints, but there have certainly
> been some other changes that could break them.
Right, am looking too.
>
> Brent
>
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Brent Daniel <br...@gmail.com>.
On Mon, Jun 20, 2011 at 3:42 AM, Simon Laws <si...@googlemail.com> wrote:
>>
>> Simon,
>>
>> Maybe I'm not understanding you, but I think this is working as it
>> should. We are forced to use a two step process, but the policies do
>> get removed from the EPs/EPRs.
>>
>> On the EP side, we loop through the list of component services and see
>> if we need to remove any policy sets. If we do, we also remove the
>> same policy sets from the endpoints for the service (since the
>> endpoints will have inherited the policy sets earlier in the build
>> process.)
>>
>> I think we're kind of stuck with this as it is -- the appliesTo
>> processing can not directly apply to the EP/EPR because it is XPath
>> based and needs to work against the actual composite model. We also
>> can't move it to occur prior to inheritance because it is legal to
>> specify a policy set on an element where it does not apply and have it
>> be inherited by an element where it does apply.
>>
>> Brent
>>
>
> Hi Brent
>
> I agree both that we have to run the appliesTo processing after the
> inheritance processing and that the XPath has to be applied against
> the composite model and not endpoints. I note that there were some
> recent changes to the code but looking at the current code for the
> part that deals with the EP
>
> 1 for (ComponentService componentService : component.getServices()) {
> 2 List<PolicySet> policySetsToRemove =
> checkAppliesToSubject(document, appliesToSubjects, topComposite,
> componentService, componentService.getPolicySets());
> 3 for (Endpoint ep : componentService.getEndpoints()) {
> 4 ep.getPolicySets().removeAll(policySetsToRemove);
> 5 if (ep.getBinding() instanceof PolicySubject) {
> 6 List<PolicySet> bindingPolicySetsToRemove =
> checkAppliesToSubject(document, appliesToSubjects, topComposite,
> (PolicySubject)ep.getBinding(),
> ((PolicySubject)ep.getBinding()).getPolicySets());
> 7 ep.getPolicySets().removeAll(bindingPolicySetsToRemove);
> 8 }
> 9 }
> 10 }
>
> A) during the policy processing all of the policies that are relevant
> to the EP, regardless of where they are attached, should be
> accumulated on the endpoint by this stage so I don't see the need to
> check both the service and the binding. The only thing we need to
> check is the binding as the applies to will, I believe, only refer to
> binding or implementation types.
>
> B) passing in ((PolicySubject)ep.getBinding()).getPolicySets()) as the
> set of policy sets to check is not correct I believe because it will
> not hold the full set of policy sets aggregated at the EP
>
> C) why is ep.getPolicySets().removeAll(policySetsToRemove); called
> inside the loop. From A) and B) I don't think this line is required at
> all now.
>
> So I think we can reduce the above to
>
> for (ComponentService componentService : component.getServices()) {
> for (Endpoint ep : componentService.getEndpoints()) {
> if (ep.getBinding() instanceof PolicySubject) {
> List<PolicySet> policySetsToRemove =
> checkAppliesToSubject(document, appliesToSubjects, topComposite,
> (PolicySubject)ep.getBinding(), ep.getPolicySets());
> ep.getPolicySets().removeAll(policySetsToRemove);
> }
> }
> }
>
> Note. I still check against the binding model but get the policy sets
> from the EP. Similar changes would apply to reference also.
>
> With the code as it currently is in svn I'm getting failures in the
> policy compliance tests 9006, 9009, 9019, 9020, 9021. For 9006 it was
> expecting an exception and the test is now running successfully. Not
> sure which changes it's related to so I'll look at bit more closely as
> I've been changing policy stuff as well.
>
> Regards
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
A) I disagree that we only have to check the binding. The appliesTo
XPath expression could potentially point to any element in the
composite. Also, consider the case where an intent is specified on a
higher level element:
<service requires="myIntent">
<binding.ws>
</service>
"myIntent" could potentially not apply here, but we wouldn't be
checking it if we only check the binding.
B) The binding policy sets will not encompass the full set of policy
sets inherited by the endpoint, but the idea is that we will check
every element that the endpoint has inherited from (I don't think this
is correct today, as the component is missing.)
C) It's called from within the loop because "policySetsToRemove" is
the set of policy sets on the service which do not apply to the
endpoint, and it needs to be removed from each endpoint underneath the
service.
The code you listed I think would be correct if we assume that
appliesTo can only reference a binding element (and implementations,
though we don't care about that here.) Maybe we should be doing this
(it would make sense), but without that limit in the spec I don't
think we can assume it.
I'll take a look at the CTS failures.. I wouldn't expect them to be
related to the changes to the appliesTo builder because those should
only affect services with multiple endpoints, but there have certainly
been some other changes that could break them.
Brent
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
>
> Simon,
>
> Maybe I'm not understanding you, but I think this is working as it
> should. We are forced to use a two step process, but the policies do
> get removed from the EPs/EPRs.
>
> On the EP side, we loop through the list of component services and see
> if we need to remove any policy sets. If we do, we also remove the
> same policy sets from the endpoints for the service (since the
> endpoints will have inherited the policy sets earlier in the build
> process.)
>
> I think we're kind of stuck with this as it is -- the appliesTo
> processing can not directly apply to the EP/EPR because it is XPath
> based and needs to work against the actual composite model. We also
> can't move it to occur prior to inheritance because it is legal to
> specify a policy set on an element where it does not apply and have it
> be inherited by an element where it does apply.
>
> Brent
>
Hi Brent
I agree both that we have to run the appliesTo processing after the
inheritance processing and that the XPath has to be applied against
the composite model and not endpoints. I note that there were some
recent changes to the code but looking at the current code for the
part that deals with the EP
1 for (ComponentService componentService : component.getServices()) {
2 List<PolicySet> policySetsToRemove =
checkAppliesToSubject(document, appliesToSubjects, topComposite,
componentService, componentService.getPolicySets());
3 for (Endpoint ep : componentService.getEndpoints()) {
4 ep.getPolicySets().removeAll(policySetsToRemove);
5 if (ep.getBinding() instanceof PolicySubject) {
6 List<PolicySet> bindingPolicySetsToRemove =
checkAppliesToSubject(document, appliesToSubjects, topComposite,
(PolicySubject)ep.getBinding(),
((PolicySubject)ep.getBinding()).getPolicySets());
7 ep.getPolicySets().removeAll(bindingPolicySetsToRemove);
8 }
9 }
10 }
A) during the policy processing all of the policies that are relevant
to the EP, regardless of where they are attached, should be
accumulated on the endpoint by this stage so I don't see the need to
check both the service and the binding. The only thing we need to
check is the binding as the applies to will, I believe, only refer to
binding or implementation types.
B) passing in ((PolicySubject)ep.getBinding()).getPolicySets()) as the
set of policy sets to check is not correct I believe because it will
not hold the full set of policy sets aggregated at the EP
C) why is ep.getPolicySets().removeAll(policySetsToRemove); called
inside the loop. From A) and B) I don't think this line is required at
all now.
So I think we can reduce the above to
for (ComponentService componentService : component.getServices()) {
for (Endpoint ep : componentService.getEndpoints()) {
if (ep.getBinding() instanceof PolicySubject) {
List<PolicySet> policySetsToRemove =
checkAppliesToSubject(document, appliesToSubjects, topComposite,
(PolicySubject)ep.getBinding(), ep.getPolicySets());
ep.getPolicySets().removeAll(policySetsToRemove);
}
}
}
Note. I still check against the binding model but get the policy sets
from the EP. Similar changes would apply to reference also.
With the code as it currently is in svn I'm getting failures in the
policy compliance tests 9006, 9009, 9019, 9020, 9021. For 9006 it was
expecting an exception and the test is now running successfully. Not
sure which changes it's related to so I'll look at bit more closely as
I've been changing policy stuff as well.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Brent Daniel <br...@gmail.com>.
On Fri, Jun 17, 2011 at 10:38 AM, Simon Laws <si...@googlemail.com> wrote:
> On Fri, Jun 17, 2011 at 6:19 PM, Brent Daniel <br...@gmail.com> wrote:
>> The applies to processing actually does end up working on
>> endpoints/endpoint references. It has to operate against the composite
>> model since it is XPath based, but when we find policies that need to
>> be removed from a service, reference, etc, we remove them from the
>> corresponding endpoint or endpoint reference.
>>
>> There is currently a bug here that surfaces when there are multiple
>> endpoints or endpoint references under a service/reference. It's only
>> removing the policies from one of the endpoints in this case. I'm
>> going to commit a fix for this shortly.
>>
>> Brent
>>
>> On Thu, Jun 16, 2011 at 9:26 AM, Simon Laws <si...@googlemail.com> wrote:
>>> On Thu, Jun 16, 2011 at 5:25 PM, Simon Laws <si...@googlemail.com> wrote:
>>>> On Thu, Jun 16, 2011 at 3:55 PM, Brent Daniel <br...@gmail.com> wrote:
>>>>> Simon,
>>>>>
>>>>> I've been operating with basically the same set of changes locally and
>>>>> things do seem to work fine.
>>>>>
>>>>> From a design perspective, the unshared model seems like a better
>>>>> alternative to me. I'm sure there are performance gains from not
>>>>> having to do annotation processing, etc, multiple times, but these
>>>>> could probably be achieved with caching elsewhere.
>>>>>
>>>>> Brent
>>>>>
>>>>
>>>> Ok, Brent. Lets go with it for the time being and see how hangs
>>>> together. If you have improvements in your changes over what I added
>>>> feel free to go in and fix it up.
>>>>
>>>> Simon
>>>>
>>>> --
>>>> Apache Tuscany committer: tuscany.apache.org
>>>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>>>
>>>
>>> And I forgot to add that I'm still seeing some residual issues in the
>>> way that appliesTo is processed. I think because the applies to
>>> processing is based on reference and services where it should really
>>> be based on endpints and endpoint references.
>>>
>>> Simon
>>>
>>> --
>>> Apache Tuscany committer: tuscany.apache.org
>>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>>
>>
> The other thing that is wrong though is that the set of policies it;s
> looking at is from the service/reference/binding and not from the
> ep/epr where the correct set of policies have been aggregated.
>
> Simon
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Simon,
Maybe I'm not understanding you, but I think this is working as it
should. We are forced to use a two step process, but the policies do
get removed from the EPs/EPRs.
On the EP side, we loop through the list of component services and see
if we need to remove any policy sets. If we do, we also remove the
same policy sets from the endpoints for the service (since the
endpoints will have inherited the policy sets earlier in the build
process.)
I think we're kind of stuck with this as it is -- the appliesTo
processing can not directly apply to the EP/EPR because it is XPath
based and needs to work against the actual composite model. We also
can't move it to occur prior to inheritance because it is legal to
specify a policy set on an element where it does not apply and have it
be inherited by an element where it does apply.
Brent
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jun 17, 2011 at 6:19 PM, Brent Daniel <br...@gmail.com> wrote:
> The applies to processing actually does end up working on
> endpoints/endpoint references. It has to operate against the composite
> model since it is XPath based, but when we find policies that need to
> be removed from a service, reference, etc, we remove them from the
> corresponding endpoint or endpoint reference.
>
> There is currently a bug here that surfaces when there are multiple
> endpoints or endpoint references under a service/reference. It's only
> removing the policies from one of the endpoints in this case. I'm
> going to commit a fix for this shortly.
>
> Brent
>
> On Thu, Jun 16, 2011 at 9:26 AM, Simon Laws <si...@googlemail.com> wrote:
>> On Thu, Jun 16, 2011 at 5:25 PM, Simon Laws <si...@googlemail.com> wrote:
>>> On Thu, Jun 16, 2011 at 3:55 PM, Brent Daniel <br...@gmail.com> wrote:
>>>> Simon,
>>>>
>>>> I've been operating with basically the same set of changes locally and
>>>> things do seem to work fine.
>>>>
>>>> From a design perspective, the unshared model seems like a better
>>>> alternative to me. I'm sure there are performance gains from not
>>>> having to do annotation processing, etc, multiple times, but these
>>>> could probably be achieved with caching elsewhere.
>>>>
>>>> Brent
>>>>
>>>
>>> Ok, Brent. Lets go with it for the time being and see how hangs
>>> together. If you have improvements in your changes over what I added
>>> feel free to go in and fix it up.
>>>
>>> Simon
>>>
>>> --
>>> Apache Tuscany committer: tuscany.apache.org
>>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>>
>>
>> And I forgot to add that I'm still seeing some residual issues in the
>> way that appliesTo is processed. I think because the applies to
>> processing is based on reference and services where it should really
>> be based on endpints and endpoint references.
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>
>
The other thing that is wrong though is that the set of policies it;s
looking at is from the service/reference/binding and not from the
ep/epr where the correct set of policies have been aggregated.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Brent Daniel <br...@gmail.com>.
The applies to processing actually does end up working on
endpoints/endpoint references. It has to operate against the composite
model since it is XPath based, but when we find policies that need to
be removed from a service, reference, etc, we remove them from the
corresponding endpoint or endpoint reference.
There is currently a bug here that surfaces when there are multiple
endpoints or endpoint references under a service/reference. It's only
removing the policies from one of the endpoints in this case. I'm
going to commit a fix for this shortly.
Brent
On Thu, Jun 16, 2011 at 9:26 AM, Simon Laws <si...@googlemail.com> wrote:
> On Thu, Jun 16, 2011 at 5:25 PM, Simon Laws <si...@googlemail.com> wrote:
>> On Thu, Jun 16, 2011 at 3:55 PM, Brent Daniel <br...@gmail.com> wrote:
>>> Simon,
>>>
>>> I've been operating with basically the same set of changes locally and
>>> things do seem to work fine.
>>>
>>> From a design perspective, the unshared model seems like a better
>>> alternative to me. I'm sure there are performance gains from not
>>> having to do annotation processing, etc, multiple times, but these
>>> could probably be achieved with caching elsewhere.
>>>
>>> Brent
>>>
>>
>> Ok, Brent. Lets go with it for the time being and see how hangs
>> together. If you have improvements in your changes over what I added
>> feel free to go in and fix it up.
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>
>
> And I forgot to add that I'm still seeing some residual issues in the
> way that appliesTo is processed. I think because the applies to
> processing is based on reference and services where it should really
> be based on endpints and endpoint references.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jun 16, 2011 at 5:25 PM, Simon Laws <si...@googlemail.com> wrote:
> On Thu, Jun 16, 2011 at 3:55 PM, Brent Daniel <br...@gmail.com> wrote:
>> Simon,
>>
>> I've been operating with basically the same set of changes locally and
>> things do seem to work fine.
>>
>> From a design perspective, the unshared model seems like a better
>> alternative to me. I'm sure there are performance gains from not
>> having to do annotation processing, etc, multiple times, but these
>> could probably be achieved with caching elsewhere.
>>
>> Brent
>>
>
> Ok, Brent. Lets go with it for the time being and see how hangs
> together. If you have improvements in your changes over what I added
> feel free to go in and fix it up.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
And I forgot to add that I'm still seeing some residual issues in the
way that appliesTo is processed. I think because the applies to
processing is based on reference and services where it should really
be based on endpints and endpoint references.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jun 16, 2011 at 3:55 PM, Brent Daniel <br...@gmail.com> wrote:
> Simon,
>
> I've been operating with basically the same set of changes locally and
> things do seem to work fine.
>
> From a design perspective, the unshared model seems like a better
> alternative to me. I'm sure there are performance gains from not
> having to do annotation processing, etc, multiple times, but these
> could probably be achieved with caching elsewhere.
>
> Brent
>
Ok, Brent. Lets go with it for the time being and see how hangs
together. If you have improvements in your changes over what I added
feel free to go in and fix it up.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Brent Daniel <br...@gmail.com>.
Simon,
I've been operating with basically the same set of changes locally and
things do seem to work fine.
>From a design perspective, the unshared model seems like a better
alternative to me. I'm sure there are performance gains from not
having to do annotation processing, etc, multiple times, but these
could probably be achieved with caching elsewhere.
Brent
On Thu, Jun 16, 2011 at 5:20 AM, Simon Laws <si...@googlemail.com> wrote:
> On Thu, Jun 16, 2011 at 9:14 AM, Simon Laws <si...@googlemail.com> wrote:
>> On Thu, Jun 16, 2011 at 2:31 AM, Brent Daniel <br...@gmail.com> wrote:
>>> I noticed that the appliesTo processing in PolicyAppliesToBuilderImpl
>>> is not operating on components. Otherwise it seems to be working fine
>>> from what I can tell. This is something to take into consideration if
>>> the implementation policies are moved back to the component, though.
>>> The appliesTo would happen after the policy set was moved to the
>>> component, so if the builder was correctly handling components, any
>>> implementation policy set that had a reasonably specific appliesTo
>>> would be removed. For example, the ManagedTransactionPolicySet applies
>>> to elements that start with "implementation", so it would be removed.
>>>
>>> Brent
>>
>> You're right Brent. Currently the appliesTo process assumes that the
>> policies for an implementation are retained on the implementation
>> model. If we do resort to holding them on the component then we will
>> have to take the set on the component into account when calculating
>> appliesTo. The bottom line is that we have some code that assumes
>> policy sets are on the implementation and some that assumes they are
>> on the component. If we use the implementation then we loose the
>> shared implementation optimization. If we use the component then we
>> have to fix applies to etc. At the moment it looks like most of the
>> code assumes it's on the component so, as I said, I'll first take and
>> approach of putting them back on the component and see if I can get
>> that path working again. I I struggle I'll look at unpicking the
>> shared implementation assumption.
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>
>
> I started down the rout of putting back the code to support
> implementation policy at the component level. It does quickly become
> untidy though as we have to take account of things like appliesTo and
> writing the composite back out correctly.I stopped and changed track
> to put a small set of changes in to disable implementation model
> sharing and to pick up policy from the implementation. The policy
> providers are still stored on the component and the implementation
> factory interface still takes a component. This though hould give us
> enough to get tests written and see if the approach is practical.
> Brent can you repeat whatever you were doing when you found the
> problem and see if it now works for you.
>
> Change checked in against TUSCANY-3876
>
> Regards
>
> Simon
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jun 16, 2011 at 9:14 AM, Simon Laws <si...@googlemail.com> wrote:
> On Thu, Jun 16, 2011 at 2:31 AM, Brent Daniel <br...@gmail.com> wrote:
>> I noticed that the appliesTo processing in PolicyAppliesToBuilderImpl
>> is not operating on components. Otherwise it seems to be working fine
>> from what I can tell. This is something to take into consideration if
>> the implementation policies are moved back to the component, though.
>> The appliesTo would happen after the policy set was moved to the
>> component, so if the builder was correctly handling components, any
>> implementation policy set that had a reasonably specific appliesTo
>> would be removed. For example, the ManagedTransactionPolicySet applies
>> to elements that start with "implementation", so it would be removed.
>>
>> Brent
>
> You're right Brent. Currently the appliesTo process assumes that the
> policies for an implementation are retained on the implementation
> model. If we do resort to holding them on the component then we will
> have to take the set on the component into account when calculating
> appliesTo. The bottom line is that we have some code that assumes
> policy sets are on the implementation and some that assumes they are
> on the component. If we use the implementation then we loose the
> shared implementation optimization. If we use the component then we
> have to fix applies to etc. At the moment it looks like most of the
> code assumes it's on the component so, as I said, I'll first take and
> approach of putting them back on the component and see if I can get
> that path working again. I I struggle I'll look at unpicking the
> shared implementation assumption.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
I started down the rout of putting back the code to support
implementation policy at the component level. It does quickly become
untidy though as we have to take account of things like appliesTo and
writing the composite back out correctly.I stopped and changed track
to put a small set of changes in to disable implementation model
sharing and to pick up policy from the implementation. The policy
providers are still stored on the component and the implementation
factory interface still takes a component. This though hould give us
enough to get tests written and see if the approach is practical.
Brent can you repeat whatever you were doing when you found the
problem and see if it now works for you.
Change checked in against TUSCANY-3876
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jun 16, 2011 at 2:31 AM, Brent Daniel <br...@gmail.com> wrote:
> I noticed that the appliesTo processing in PolicyAppliesToBuilderImpl
> is not operating on components. Otherwise it seems to be working fine
> from what I can tell. This is something to take into consideration if
> the implementation policies are moved back to the component, though.
> The appliesTo would happen after the policy set was moved to the
> component, so if the builder was correctly handling components, any
> implementation policy set that had a reasonably specific appliesTo
> would be removed. For example, the ManagedTransactionPolicySet applies
> to elements that start with "implementation", so it would be removed.
>
> Brent
You're right Brent. Currently the appliesTo process assumes that the
policies for an implementation are retained on the implementation
model. If we do resort to holding them on the component then we will
have to take the set on the component into account when calculating
appliesTo. The bottom line is that we have some code that assumes
policy sets are on the implementation and some that assumes they are
on the component. If we use the implementation then we loose the
shared implementation optimization. If we use the component then we
have to fix applies to etc. At the moment it looks like most of the
code assumes it's on the component so, as I said, I'll first take and
approach of putting them back on the component and see if I can get
that path working again. I I struggle I'll look at unpicking the
shared implementation assumption.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Brent Daniel <br...@gmail.com>.
I noticed that the appliesTo processing in PolicyAppliesToBuilderImpl
is not operating on components. Otherwise it seems to be working fine
from what I can tell. This is something to take into consideration if
the implementation policies are moved back to the component, though.
The appliesTo would happen after the policy set was moved to the
component, so if the builder was correctly handling components, any
implementation policy set that had a reasonably specific appliesTo
would be removed. For example, the ManagedTransactionPolicySet applies
to elements that start with "implementation", so it would be removed.
Brent
On Wed, Jun 15, 2011 at 9:20 AM, Simon Laws <si...@googlemail.com> wrote:
> On Wed, Jun 15, 2011 at 4:49 PM, Raymond Feng <en...@gmail.com> wrote:
>> I ran into the same issue too. In addition to the model, we don't honor the
>> appliesTo (in this case, it only applies to certain implementation types).
>> Thanks,
>> Raymond
>> ________________________________________________________________
>> Raymond Feng
>> rfeng@apache.org
>> Apache Tuscany PMC member and committer: tuscany.apache.org
>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>> Personal Web Site: www.enjoyjava.com
>> ________________________________________________________________
>
>
> As a first step I'm going to update the builder code to push
> implementation policy back into the component to see if we can get
> back to where we were. There is still code in that depends on this
> being the case which is why this is not the case.
>
> I hadn't noticed that appliesTo isn't working properly. There is code
> for it so we need to look at it.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Jun 15, 2011 at 4:49 PM, Raymond Feng <en...@gmail.com> wrote:
> I ran into the same issue too. In addition to the model, we don't honor the
> appliesTo (in this case, it only applies to certain implementation types).
> Thanks,
> Raymond
> ________________________________________________________________
> Raymond Feng
> rfeng@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> ________________________________________________________________
As a first step I'm going to update the builder code to push
implementation policy back into the component to see if we can get
back to where we were. There is still code in that depends on this
being the case which is why this is not the case.
I hadn't noticed that appliesTo isn't working properly. There is code
for it so we need to look at it.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Raymond Feng <en...@gmail.com>.
I ran into the same issue too. In addition to the model, we don't honor the appliesTo (in this case, it only applies to certain implementation types).
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Jun 15, 2011, at 6:42 AM, Simon Laws wrote:
>>
>> 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
>>
>
> I added some implementation policy to a test I'm writing and sure
> enough it doesn't work properly. I've created TUSCANY-3876 to track.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.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
>
I added some implementation policy to a test I'm writing and sure
enough it doesn't work properly. I've created TUSCANY-3876 to track.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jun 13, 2011 at 11:37 AM, Simon Laws <si...@googlemail.com> wrote:
> On Mon, Jun 13, 2011 at 3:30 AM, Brent Daniel <br...@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
Re: Issue with policy intents and shared implementations
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jun 13, 2011 at 3:30 AM, Brent Daniel <br...@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