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 Wed, 27 Jul 2011 11:13:30 GMT
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.



> 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/

Mime
View raw message