axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <amilasuriarach...@gmail.com>
Subject Re: WSDL generation for the services exposed only in local transport
Date Thu, 28 Jul 2011 05:22:59 GMT
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 think Ruwans fix is to set the severSide property at the nhttp transport
level. similar to what we doing here.

For me, I can not see any way of using same transport for both axis2
serviceClient and synapse since they use
a different thread models. Axis2 client always assume response has received
when the thread return from the transport sender but synapse should work
without this condition.

The only possible way to do that is to make the transport sender thread wait
until response returns like in SMTP transport. But that may cause lot of
performance issues at synapse level.

However testing your suggestion won't make any harm.

Heshan can you please test these two with the Andreas suggestion
1. Does that make work with Axis2. This means it should not invoke
AxisEngine twice etc ..
2. Does that make it work with synapse case.

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/

Mime
View raw message