axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: WSDL generation for the services exposed only in local transport
Date Thu, 28 Jul 2011 20:01:35 GMT
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?

> 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


Mime
View raw message