>> --
>> 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 wh
On Tue, Jun 28, 2011 at 12:35 PM, Simon Laws wrote:
> On Tue, Jun 28, 2011 at 12:25 PM, ant elder 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 Law
On Tue, Jun 28, 2011 at 12:25 PM, ant elder 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 wrote:
>> On Tue, Jun 28, 2011 at 9:40 AM, ant elder wrot
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 wrote:
> On Tue, Jun 28, 2011 at 9:40 AM, ant elder wrote:
>> There are still several build fails in the policy compli
On Tue, Jun 28, 2011 at 9:40 AM, ant elder 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 i
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 wrote:
> On Tue, Jun 21, 2011 at 8:07 PM,
On Wed, Jun 22, 2011 at 1:30 PM, Simon Laws wrote:
> On Tue, Jun 21, 2011 at 8:07 PM, Brent Daniel wrote:
>> On Tue, Jun 21, 2011 at 6:59 AM, Simon Laws
>> wrote:
>>> Ok, I just checked with Dave Booz from the policy spec team and the
>>> intention is the following:
>>>
>>> - the attachTo and a
On Tue, Jun 21, 2011 at 8:07 PM, Brent Daniel wrote:
> On Tue, Jun 21, 2011 at 6:59 AM, Simon Laws 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 implemen
On Tue, Jun 21, 2011 at 6:59 AM, Simon Laws 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
On Tue, Jun 21, 2011 at 2:05 PM, Simon Laws 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 se
> 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 tha
On Mon, Jun 20, 2011 at 8:57 AM, Simon Laws 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
>
> 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:
>
>
>
>
> "myIntent" could potentially not apply here, but we
On Mon, Jun 20, 2011 at 3:42 AM, Simon Laws 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 compo
>
> 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
On Fri, Jun 17, 2011 at 10:38 AM, Simon Laws wrote:
> On Fri, Jun 17, 2011 at 6:19 PM, Brent Daniel 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 poli
On Fri, Jun 17, 2011 at 6:19 PM, Brent Daniel 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,
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 endpoin
On Thu, Jun 16, 2011 at 5:25 PM, Simon Laws wrote:
> On Thu, Jun 16, 2011 at 3:55 PM, Brent Daniel 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
On Thu, Jun 16, 2011 at 3:55 PM, Brent Daniel 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 fr
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, b
On Thu, Jun 16, 2011 at 9:14 AM, Simon Laws wrote:
> On Thu, Jun 16, 2011 at 2:31 AM, Brent Daniel 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
On Thu, Jun 16, 2011 at 2:31 AM, Brent Daniel 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
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
On Wed, Jun 15, 2011 at 4:49 PM, Raymond Feng 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
>
> R
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
rf...@apache.org
Apache Tuscany PMC member and comm
>
> 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
> //
On Mon, Jun 13, 2011 at 11:37 AM, Simon Laws wrote:
> On Mon, Jun 13, 2011 at 3:30 AM, Brent Daniel 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 p
On Mon, Jun 13, 2011 at 3:30 AM, Brent Daniel 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 usi
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 confli
30 matches
Mail list logo
