axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal jayasinghe <deep...@gmail.com>
Subject Re: WSDL generation for the services exposed only in local transport
Date Tue, 02 Aug 2011 00:01:59 GMT
I think Amila was trying to explain how Axis2 transport works in
general, so I do not see any problem with that.

In Axis2, the response of non-blocking (transport asynchronous) is
treated as a request coming to the system. However, the difference is at
the end (once the message is passed through in-flow) instead of calling
service implementation class, the callback object is called.

We use the isServerSide flag for blocking invocation, because in the
case of blocking once the message is passed through in-flow it should
give the control black to the caller (rather than calling MR).  Thus,
when calling a blocking call OperationClient sets this flag and no
transport needs to aware of this.

Local transport is in fact different, main reason we created that to
reduce the running time of test cases (rather than using HTTP). by any
means it was not created as a real transport.

One  point to make here is that the transport needs to know whether it
is creating message context for the client side or server side
(isServerSide). But, given the current architecture that is a good way
to handle it. Much better approach would be to take a constructor
augment to make it more explicit. 

Thanks,
Deepal


> On Fri, Jul 29, 2011 at 08:15, Amila Suriarachchi
> <amilasuriarachchi@gmail.com> wrote:
>>
>> On Fri, Jul 29, 2011 at 1:31 AM, Andreas Veithen <andreas.veithen@gmail.com>
>> wrote:
>>> On Thu, Jul 28, 2011 at 08:49, Amila Suriarachchi
>>> <amilasuriarachchi@gmail.com> wrote:
>>>>
>>>> On Wed, Jul 27, 2011 at 5:25 PM, Andreas Veithen
>>>> <andreas.veithen@gmail.com>
>>>> wrote:
>>>>> On Wed, Jul 27, 2011 at 13:13, Amila Suriarachchi
>>>>> <amilasuriarachchi@gmail.com> wrote:
>>>>>>
>>>>>> On Wed, Jul 27, 2011 at 2:04 PM, Andreas Veithen
>>>>>> <andreas.veithen@gmail.com>
>>>>>> wrote:
>>>>>>> On Wed, Jul 27, 2011 at 07:52, Amila Suriarachchi
>>>>>>> <amilasuriarachchi@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Wed, Jul 27, 2011 at 10:45 AM, Amila Suriarachchi
>>>>>>>> <amilasuriarachchi@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Jul 26, 2011 at 6:07 PM, Andreas Veithen
>>>>>>>>> <andreas.veithen@gmail.com> wrote:
>>>>>>>>>> So, the bottom line is that it is OK to introduce a component
>>>>>>>>>> into
>>>>>>>>>> Axis2 that violates the Axis2 API
>>>>>>>>>> (NonBlockingLocalTransportSender
>>>>>>>>>> sets an incorrect value for the serverSide property) and it is
>>>>>>>>>> not
>>>>>>>>>> worth trying to understand how this can be fixed such that it
>>>>>>>>>> works
>>>>>>>>>> both in a pure Axis2 context and in Synapse?
>>>>>>>>> Here no new component is introduced. It is improving an existing
>>>>>>>>> thing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> NonBlockingLocalTransportSender actually works just fine with
>>>>>>>>>> the
>>>>>>>>>> ServiceClient API if the incorrect code is changed so that it
>>>>>>>>>> sets
>>>>>>>>>> serverSide=false.
>>>>>>>>> Which line you talk about? if your concern about this property?
>>>>>>>> And also how to define the server side and client side of Axis2?
>>>>>>>> Can
>>>>>>>> you
>>>>>>>> please explain why it works with server side false and not server
>>>>>>>> side
>>>>>>>> true?
>>>>>>> serverSide is set to true if and only if the message context
>>>>>>> corresponds to an incoming message received by a transport listener.
>>>>>> if you look at where isServerSide is used it is used in the
>>>>>> AxisEngine
>>>>>> as a
>>>>>> means of kipping the message receiver invocation. But in synapse it
>>>>>> always
>>>>>> registers a callback handler and hence this parameter is needed.
>>>>>>
>>>>>> And also if you make this parameter twice I think it calls
>>>>>> AxisEngine.receive twice.
>>>>>>
>>>>>> Heshan can you please double check this?
>>>>>>
>>>>>> If someone wants to do a local transport in axis2 level then they can
>>>>>> always
>>>>>> use the existing local transport sender and the new code does not
>>>>>> make
>>>>>> any
>>>>>> alternation to the existing transport execution paths. What is the
>>>>>> reason
>>>>>> for making NonBlockingLocalTransport sender also making the same
>>>>>> usage?
>>>>>> The
>>>>>> idea of NonBlockingLocal transport is to make it work even the
>>>>>> response
>>>>>> receives in a different thread.
>>>>>>
>>>>>> Axis2 is a project one can use as it is. But there are some other
>>>>>> projects
>>>>>> use it as a library as well. And also local transport is not a part
>>>>>> of
>>>>>> axis2
>>>>>> kernel. So I still think it is reasonable improvement to existing
>>>>>> local
>>>>>> transport to make it work with synapse.
>>>>>>
>>>>>> thanks,
>>>>>> Amila.
>>>>>>
>>>>> I don't know any project that (knowingly) ships code that is not
>>>>> interoperable with its own API. If the community is OK to go down that
>>>>> road and starts doing such things, then this will likely be a turning
>>>>> point in the evolution of the project.
>>>>>
>>>>> Anyway, it is likely that the fix in Synapse done by Ruwan for
>>>>> WSCOMMONS-444 also solves the issue with NonBlockingLocalTransport and
>>>>> that the argument that we need two different local transports
>>>>> completely breaks down. Therefore I repeat my question: Did somebody
>>>>> actually check what happens in Synapse when
>>>>> NonBlockingLocalTransportSender is made compliant with the Axis2 API?
>>>> I did check your suggestion with Axis2. It passes the test as you have
>>>> mentioned.
>>>>
>>>> But it hits AxisEngine.receive twice. One from the handleResponse of the
>>>> localResponder and other one is
>>>> handleResponse method of the OutIn operation. So it is not a proper fix.
>>> The JMS transport also invokes AxisEngine.receive for the response
>>> message. Does this mean that we have the same problem (double
>>> invocation of AxisEngine.receive) there too?
>> I am not sure. If you look at the commons http transport you will see after
>> getting the response it just saves the message and returns without calling
>> AxisEngine.receive.
> I made a statement about the JMS transport. Why do you reply with a
> statement about the HTTP transport?
>
>> AxisEngine.receive is called by OutInAxisOperationClient.
>>
>> And also you can see here[1] serverSide is set to true. But it is not
>> invoked through a listener thread.
>>
>> What I try to say is that there is not such convention as you have defined.
>> But people use this property appropriate manner depending on whether they
>> want to invoke the message receiver or not.
> Whether or not a message receiver should be invoked is a concern of
> the operation client and the kernel. It is not a concern of the
> transport. Your argument means that when writing a transport, one has
> to take into account how the operation client interacts with the
> kernel. This introduces a strong coupling between the transport and
> the application code. If we declare that this is OK, then this is an
> indication that Axis2 has started to degenerate from a framework
> (which implies some degree of architectural consistency) into a mere
> library that provides components to downstream projects without
> enforcing a consistent architecture and programming model.
>
>> As I mentioned earlier I agree that the NonBlockingLocalTransport is only
>> useful with synapse. But it having here as an improvement to existing local
>> transport is more sensible options to take.
>>
>> thanks,
>> Amila.
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/branches/1_6/modules/transport/local/src/org/apache/axis2/transport/local/LocalTransportReceiver.java
>>
>>
>>
>>>> As I mentioned earlier reason for this is the two thread models (which
>>>> are
>>>> not enforced through and API) assumed by the synapse and Axis2.
>>>>
>>>> thanks,
>>>> Amila.
>>>>
>>>>> Or did you guys completely ignore my comment in AXIS2-4944?
>>>>>
>>>>>>> All transports in the Axis2 project (including the Transports
>>>>>>> project)
>>>>>>> satisfy this requirement, except for NonBlockingLocalTransportSender
>>>>>>> which is the reason why it doesn't work. See my comment in
>>>>>>> AXIS2-4944
>>>>>>> for more information about where the incorrect code is located and
>>>>>>> how
>>>>>>> to test this.
>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Amila.
>>>>>>>>> thanks,
>>>>>>>>> Amila.
>>>>>>>>>
>>>>>>>>>> Did somebody actually check what happens in Synapse
>>>>>>>>>> when NonBlockingLocalTransportSender is made compliant with the
>>>>>>>>>> Axis2
>>>>>>>>>> API? Some time ago there was a similar problem with other
>>>>>>>>>> transports
>>>>>>>>>> (WSCOMMONS-444) and the conclusion was that it required a change
>>>>>>>>>> in
>>>>>>>>>> Synapse to make these transports work properly with both Axis2
>>>>>>>>>> and
>>>>>>>>>> Synapse. It is likely that this fix in Synapse also covers the
>>>>>>>>>> case
>>>>>>>>>> of
>>>>>>>>>> NonBlockingLocalTransportSender.
>>>>>>>>>>
>>>>>>>>>> Andreas
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 26, 2011 at 11:22, Amila Suriarachchi
>>>>>>>>>> <amilasuriarachchi@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 25, 2011 at 10:55 PM, Andreas Veithen
>>>>>>>>>>> <andreas.veithen@gmail.com> wrote:
>>>>>>>>>>>> Just to summarize:
>>>>>>>>>>>>
>>>>>>>>>>>> * We have added a NonBlockingLocalTransportSender into the
>>>>>>>>>>>> Axis2
>>>>>>>>>>>> code
>>>>>>>>>>>> base that doesn't respect the Axis2 APIs and that only works
>>>>>>>>>>>> in
>>>>>>>>>>>> Synapse (see AXIS2-4944).
>>>>>>>>>>>> * I took us 5 JIRA issues (AXIS2-4967, AXIS2-5035,
>>>>>>>>>>>> AXIS2-5036,
>>>>>>>>>>>> AXIS2-5037 and AXIS2-5043) to add a TransportListener for the
>>>>>>>>>>>> local
>>>>>>>>>>>> transport. That TransportListener only implements the methods
>>>>>>>>>>>> to
>>>>>>>>>>>> calculate the EPR, but it actually calculates the wrong EPR
>>>>>>>>>>>> (see
>>>>>>>>>>>> AXIS2-5043).
>>>>>>>>>>>> * Now the proposal is to hardcode something into the kernel
>>>>>>>>>>>> to
>>>>>>>>>>>> exclude
>>>>>>>>>>>> these EPRs from WSDL generation.
>>>>>>>>>>>>
>>>>>>>>>>>> Can somebody please explain me what we are trying to achieve
>>>>>>>>>>>> here?
>>>>>>>>>>> If you go through this thread you can see the answers. But let
>>>>>>>>>>> me
>>>>>>>>>>> tell
>>>>>>>>>>> you
>>>>>>>>>>> again.
>>>>>>>>>>>
>>>>>>>>>>> 1. Exposing a service only with local transport. The
>>>>>>>>>>> motivation
>>>>>>>>>>> is
>>>>>>>>>>> the
>>>>>>>>>>> security. When you expose a service only with local transport
>>>>>>>>>>> then
>>>>>>>>>>> that
>>>>>>>>>>> service is automatically secured. Can you suggest a way to do
>>>>>>>>>>> this
>>>>>>>>>>> with
>>>>>>>>>>> Axis2 1.6?
>>>>>>>>>>>
>>>>>>>>>>> 2. Second is to improve the existing local transport to work
>>>>>>>>>>> within
>>>>>>>>>>> a
>>>>>>>>>>> synapse proxy service. This does not have a use case only at
>>>>>>>>>>> axis2
>>>>>>>>>>> level
>>>>>>>>>>> (same as axis2 can't use synapse nhttp transport to
>>>>>>>>>>> send/receive
>>>>>>>>>>> messages).
>>>>>>>>>>> But I think improving the existing thing rather than having a
>>>>>>>>>>> separate
>>>>>>>>>>> transport in synapse does not make any problem.
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> Amila.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Andreas
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 4, 2011 at 15:06, Heshan Suriyaarachchi
>>>>>>>>>>>> <heshan.suriyaarachchi@gmail.com> wrote:
>>>>>>>>>>>>> Hi Amila,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jun 25, 2011 at 12:29 PM, Amila Suriarachchi
>>>>>>>>>>>>> <amilasuriarachchi@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jun 20, 2011 at 10:55 AM, Heshan Suriyaarachchi
>>>>>>>>>>>>>> <heshan.suriyaarachchi@gmail.com> wrote:
>>>>>>>>>>>>>>> Hi Andreas,
>>>>>>>>>>>>>>> So, in that case does that mean, we are going to
>>>>>>>>>>>>>>> 1) revert all the improvements did to the local transport
>>>>>>>>>>>>>>> OR
>>>>>>>>>>>>>>> 2) just remove the NonBlockingTransportListener class
>>>>>>>>>>>>>>> only?
>>>>>>>>>>>>>>> If it is the first option, then we have to improve the
>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> such a way that a user should be able to extended the
>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>> implementation and write a custom implementation. That
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> help
>>>>>>>>>>>>>>> us to
>>>>>>>>>>>>>>> move
>>>>>>>>>>>>>>> the Synapse specific local transport to Synapse itself.
>>>>>>>>>>>>>>> If it is the second option, then we wont have to change
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> level change.
>>>>>>>>>>>>>>> Although we have discussed about local transport here, my
>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>> question still remains ie. improving WSDL generation
>>>>>>>>>>>>>>> logic
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>> WSDL
>>>>>>>>>>>>>>> generation for serivces that is only exposed in local
>>>>>>>>>>>>>>> transport.
>>>>>>>>>>>>>> Can you please test the given patch with the attached
>>>>>>>>>>>>>> local
>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>> sender. This should allow you to export the service with
>>>>>>>>>>>>>> only
>>>>>>>>>>>>>> local
>>>>>>>>>>>>>> transport.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It has hard coded the name local. but if you see this
>>>>>>>>>>>>>> method
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>> has done for http and https as well.
>>>>>>>>>>>>> I tested your patch and with the given patch, the local
>>>>>>>>>>>>> endpoints
>>>>>>>>>>>>> are
>>>>>>>>>>>>> not
>>>>>>>>>>>>> shown in the generated WSDL. I have created a jira [1] to
>>>>>>>>>>>>> track
>>>>>>>>>>>>> the
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>> There were some test failures and I will fix them and
>>>>>>>>>>>>> attach
>>>>>>>>>>>>> the
>>>>>>>>>>>>> patch
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the jira.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] - https://issues.apache.org/jira/browse/AXIS2-5085
>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>> Amila.
>>>>>>>>>>>>>>> On Thu, Jun 16, 2011 at 1:09 PM, Andreas Veithen
>>>>>>>>>>>>>>> <andreas.veithen@gmail.com> wrote:
>>>>>>>>>>>>>>>> Since there is a consensus that
>>>>>>>>>>>>>>>> NonBlockingLocalTransportSender
>>>>>>>>>>>>>>>> doesn't work with a pure Axis2 setup, is not unit
>>>>>>>>>>>>>>>> testable
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> relevant for Synapse, the logical conclusion would be
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>> not be included in Axis2 but in Synapse.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andreas
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jun 16, 2011 at 08:43, Heshan Suriyaarachchi
>>>>>>>>>>>>>>>> <heshan.suriyaarachchi@gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Jun 15, 2011 at 1:27 AM, Andreas Veithen
>>>>>>>>>>>>>>>>> <andreas.veithen@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> On Tue, Jun 14, 2011 at 08:48, Heshan Suriyaarachchi
>>>>>>>>>>>>>>>>>> <heshan.suriyaarachchi@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>> Hi Devs,
>>>>>>>>>>>>>>>>>>> I am opening up this thread to discuss $subject.
>>>>>>>>>>>>>>>>>>> Recently, I did some improvements [1] to the Axis2
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> transport,
>>>>>>>>>>>>>>>>>>> inorder
>>>>>>>>>>>>>>>>>>> to get it working against Synapse nhttp transport.
>>>>>>>>>>>>>>>>>>> Now
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>>>>>> is working fine against the nhttp transport.
>>>>>>>>>>>>>>>>>> To me the statement "getting transport A working
>>>>>>>>>>>>>>>>>> against
>>>>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>>>>> B"
>>>>>>>>>>>>>>>>>> doesn't make sense. Two distinct transports A and B
>>>>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>>>>> interact
>>>>>>>>>>>>>>>>>> directly. Each of them interacts with the Axis2
>>>>>>>>>>>>>>>>>> engine
>>>>>>>>>>>>>>>>>> through
>>>>>>>>>>>>>>>>>> (in
>>>>>>>>>>>>>>>>>> principle) well defined APIs. If a component (Synapse
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> case)
>>>>>>>>>>>>>>>>>> based on Axis2 has an issue when using A and B
>>>>>>>>>>>>>>>>>> together,
>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>> transport A, transport B, the component or the Axis2
>>>>>>>>>>>>>>>>>> engine
>>>>>>>>>>>>>>>>>> has an
>>>>>>>>>>>>>>>>>> issue (or multiple components have an issue), but
>>>>>>>>>>>>>>>>>> saying
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> transport A needs to be fixed to work with transport
>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>> sense and is an indication that the fundamental issue
>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>> identified properly.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> At this point, what we know is this:
>>>>>>>>>>>>>>>>>> * NHTTP doesn't work as a transport sender in a
>>>>>>>>>>>>>>>>>> standard
>>>>>>>>>>>>>>>>>> Axis2
>>>>>>>>>>>>>>>>>> setup
>>>>>>>>>>>>>>>>>> [1]. It only works in Synapse. That means that from
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> view
>>>>>>>>>>>>>>>>>> of Axis2, the NHTTP transport is broken. That is of
>>>>>>>>>>>>>>>>>> course
>>>>>>>>>>>>>>>>>> OK,
>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>> NHTTP is shipped with Synapse and nobody claims that
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> supported
>>>>>>>>>>>>>>>>>> in a plain Axis2 setup.
>>>>>>>>>>>>>>>>>> * At some point I tried to figure out what would need
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> changed
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> make the NHTTP transport work in Axis2. IIRC the
>>>>>>>>>>>>>>>>>> conclusion
>>>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> one can make it work in Axis2, but then it no longer
>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> Synapse.
>>>>>>>>>>>>>>>>>> This would indicate that Synapse actually uses the
>>>>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>>>>> API
>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>> way it was not designed for.
>>>>>>>>>>>>>>>>>> * As indicated in AXIS2-4944, the current version of
>>>>>>>>>>>>>>>>>> NonBlockingLocalTransportSender doesn't work in
>>>>>>>>>>>>>>>>>> Axis2.
>>>>>>>>>>>>>>>>>> Unless
>>>>>>>>>>>>>>>>>> somebody
>>>>>>>>>>>>>>>>>> can come up with a valid unit test that exercises
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> piece
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> code,
>>>>>>>>>>>>>>>>>> this would mean that we introduced a broken piece of
>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> Axis2
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> order to work around another broken piece of code in
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> downstream
>>>>>>>>>>>>>>>>>> project. That is of course not OK.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note that the issue with
>>>>>>>>>>>>>>>>>> NonBlockingLocalTransportSender
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>> blocking the review of other issues such as
>>>>>>>>>>>>>>>>>> AXIS2-4991,
>>>>>>>>>>>>>>>>>> because it
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> not possible to construct a unit test that validates
>>>>>>>>>>>>>>>>>> (or
>>>>>>>>>>>>>>>>>> invalidates)
>>>>>>>>>>>>>>>>>> the proposed patch. That is BTW a general issue with
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> recent
>>>>>>>>>>>>>>>>>> patches for the local transport. As far as I can
>>>>>>>>>>>>>>>>>> tell,
>>>>>>>>>>>>>>>>>> none
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>> added any new unit tests.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [1] At least that was my conclusion when I last
>>>>>>>>>>>>>>>>>> looked
>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>> ready to retract that claim if somebody comes up with
>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>> example
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> shows how to set up a simple Axis2 client that uses
>>>>>>>>>>>>>>>>>> NHTTP
>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>> outgoing
>>>>>>>>>>>>>>>>>> transport.
>>>>>>>>>>>>>>>>> As Amila has pointed out earlier,
>>>>>>>>>>>>>>>>> NonBlockingLocalTransportSender
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> used to
>>>>>>>>>>>>>>>>> talk to a proxy service from another proxy service.
>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> nhttp
>>>>>>>>>>>>>>>>> transport is written in a non blocking manner,
>>>>>>>>>>>>>>>>> NonBlockingLocalTransport
>>>>>>>>>>>>>>>>> will work seamlessly against nhttp transport. Since,
>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> TransportSender to talk between proxy services, it's
>>>>>>>>>>>>>>>>> difficult
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> come
>>>>>>>>>>>>>>>>> up
>>>>>>>>>>>>>>>>> with a test case (test client) for this particular
>>>>>>>>>>>>>>>>> usecase.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Now, my requirement is to expose an Synapse Proxy
>>>>>>>>>>>>>>>>>>> Service
>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> transport. The reason behind is that, these proxy
>>>>>>>>>>>>>>>>>>> services
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> exposed
>>>>>>>>>>>>>>>>>>> only in local transport will be used by other proxy
>>>>>>>>>>>>>>>>>>> services
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> not be
>>>>>>>>>>>>>>>>>>> available for outside parties. Earlier, axis2 local
>>>>>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>>>>>> did
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>>> TransportListener.
>>>>>>>>>>>>>>>>>>> With a TransportListener
>>>>>>>>>>>>>>>>>>> ====================
>>>>>>>>>>>>>>>>>>> I introduced [2] a TransportListener to the local
>>>>>>>>>>>>>>>>>>> transport.
>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>>>>>> listener's methods are used to calculate the
>>>>>>>>>>>>>>>>>>> endpoints
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> will be used in generating the WSDL for the
>>>>>>>>>>>>>>>>>>> service.
>>>>>>>>>>>>>>>>>>> Therefore,
>>>>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> service exposed in the local transport, the local
>>>>>>>>>>>>>>>>>>> endpoint
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>> shown
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> the WSDL. Although the local endpoints are shown in
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> WSDL,
>>>>>>>>>>>>>>>>>>> outside
>>>>>>>>>>>>>>>>>>> parties can not access the local endpoint.
>>>>>>>>>>>>>>>>>>> The problem this patch introduce is, now the WSDL
>>>>>>>>>>>>>>>>>>> shows
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> transport
>>>>>>>>>>>>>>>>>>> endpoints. Which is wrong since external users can
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> access
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> transport.
>>>>>>>>>>>>>>>>>>> So the solution is not to show the local transport
>>>>>>>>>>>>>>>>>>> endpoints
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> generated
>>>>>>>>>>>>>>>>>>> wsdl. For that we may have to change Axis2 code.
>>>>>>>>>>>>>>>>>>> eg: As an example, I am attaching the following
>>>>>>>>>>>>>>>>>>> resources
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> prove
>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>> point.
>>>>>>>>>>>>>>>>>>> The synapse-config.xml is the Synapse Configuration
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> attached
>>>>>>>>>>>>>>>>>>> WSDLs
>>>>>>>>>>>>>>>>>>> are for the proxy servivces, LocalTransportProxy
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> SecondProxy.
>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>> SecondProxy is exposed only via the local transport
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> endpoints
>>>>>>>>>>>>>>>>>>> are shown in the WSDL which is wrong IMV.
>>>>>>>>>>>>>>>>>>> Without a TransportListener
>>>>>>>>>>>>>>>>>>> ======================
>>>>>>>>>>>>>>>>>>> If we did not have a LocalTransportListener and if
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> exposed
>>>>>>>>>>>>>>>>>>> through local transport only, the WSDL for the
>>>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> generated. The reason behind is that; inorder to
>>>>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> WSDL,
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> should be a mechanism to derive the endpoints for
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> service.
>>>>>>>>>>>>>>>>>>> Since,
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> TransportListener is not there, there is no
>>>>>>>>>>>>>>>>>>> mechanism
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> derive
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> endpoints for the service(which is only exposed
>>>>>>>>>>>>>>>>>>> through
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> transport).
>>>>>>>>>>>>>>>>>>> In case the service exposed through
>>>>>>>>>>>>>>>>>>> http,https,local
>>>>>>>>>>>>>>>>>>> transports;
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> wont
>>>>>>>>>>>>>>>>>>> be the case. Then the WSDL will be generated and
>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> http,https
>>>>>>>>>>>>>>>>>>> endpoints will be shown.
>>>>>>>>>>>>>>>>>>> Without the listener, if we expose a service only
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> local
>>>>>>>>>>>>>>>>>>> transport,
>>>>>>>>>>>>>>>>>>> WSDL
>>>>>>>>>>>>>>>>>>> generation fails since the endpoints can not be
>>>>>>>>>>>>>>>>>>> derived
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>>>> service.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Your ideas and feedback on $subject is much
>>>>>>>>>>>>>>>>>>> appreciated.
>>>>>>>>>>>>>>>>>>> [1] -
>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/AXIS2-4944
>>>>>>>>>>>>>>>>>>> [2] -
>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/AXIS2-5043
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Heshan Suriyaarachchi
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://heshans.blogspot.com/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>>>>>>>> java-dev-unsubscribe@axis.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>>>> java-dev-help@axis.apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>>>>>>> java-dev-unsubscribe@axis.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>>> java-dev-help@axis.apache.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Heshan Suriyaarachchi
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://heshans.blogspot.com/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>>>>> java-dev-unsubscribe@axis.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>> java-dev-help@axis.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Heshan Suriyaarachchi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://heshans.blogspot.com/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Amila Suriarachchi
>>>>>>>>>>>>>> WSO2 Inc.
>>>>>>>>>>>>>> blog: http://amilachinthaka.blogspot.com/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>>> java-dev-unsubscribe@axis.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> java-dev-help@axis.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Heshan Suriyaarachchi
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://heshans.blogspot.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> java-dev-help@axis.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Amila Suriarachchi
>>>>>>>>>>> WSO2 Inc.
>>>>>>>>>>> blog: http://amilachinthaka.blogspot.com/
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>>>>>>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Amila Suriarachchi
>>>>>>>>> WSO2 Inc.
>>>>>>>>> blog: http://amilachinthaka.blogspot.com/
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Amila Suriarachchi
>>>>>>>> WSO2 Inc.
>>>>>>>> blog: http://amilachinthaka.blogspot.com/
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>>>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Amila Suriarachchi
>>>>>> WSO2 Inc.
>>>>>> blog: http://amilachinthaka.blogspot.com/
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>>>
>>>>
>>>>
>>>> --
>>>> Amila Suriarachchi
>>>> WSO2 Inc.
>>>> blog: http://amilachinthaka.blogspot.com/
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message