tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Re: svn commit: r1302317 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
Date Thu, 22 Mar 2012 10:48:52 GMT
On Wed, Mar 21, 2012 at 10:35 PM, Luciano Resende <luckbr1975@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 2:57 PM, ant elder <ant.elder@gmail.com> wrote:
>> On Wed, Mar 21, 2012 at 9:48 PM, Raymond Feng <enjoyjava@gmail.com> wrote:
>>> Hi,
>>> The change had a huge impact on all the binding invokers that rely on the service
binding to resolve the deployed URIs when the endpoint reference is resolved to a target endpoint.
>>> BTW, the use case applies to something like the following:
>>> <component name="A">
>>> <service name="S1">
>>> <tuscany:binding.rest uri="/a/b"/>
>>> </service>
>>> </component>
>>> <component name="B">
>>> <reference name="r1" target="A/S1"/>
>>> </component>
>>> The r1 reference is now have /a/b as the uri instead of the deployed URI. Ideally,
the binding invoker should ask for the target endpoint's deployed URI. But it involves quite
a bit changes.
>>> I'll revert the change for now until we find a consistent solution.
>> Raymond, I think you know that unilaterally reverting a commit like
>> that is not the way to do things.
>>   ...ant
> I don't see this as "unilaterally reverting a commit". I see this as a
> commit extensively broke existing functionality, the issue was brought
> up in the mailing list for discussion of a better fix, while, in the
> mean time, the commit was reverted.
> Please let's concentrate on the technical facts and try to find a
> solution that works without huge impact on existing functionality.

Luciano, the build didn't get broken until the r1303591 commit so
phrases like "extensively broke" do nothing to constructively help
find a solution that works for everyone. There is well known and clear
ASF process for vetos and following that will help avoid these type of
exchanges. From whats been said so far about this issue it seems like
the rest binding invoker has no tests for this function and was only
working by relying on an existing bug so having that change while we
clean up trunk on the way to 2.0 is no cause for getting grumpy. There
has already been a fix for that suggested in TUSCANY-4029, if that
doesn't completely resolve the issue then respectful dev in trunk and
dev-list is the way to get to something that does.


View raw message