[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rampart-dev
Subject:    Re: WSDL generation for the services exposed only in local transport
From:       Amila Suriarachchi <amilasuriarachchi () gmail ! com>
Date:       2011-06-25 7:11:50
Message-ID: BANLkTimizZoz4HS4nPp_eMgyFfY9m8AT1w () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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.

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/

[Attachment #5 (text/html)]

<br><br><div class="gmail_quote">On Mon, Jun 20, 2011 at 10:55 AM, Heshan \
Suriyaarachchi <span dir="ltr">&lt;<a \
href="mailto:heshan.suriyaarachchi@gmail.com">heshan.suriyaarachchi@gmail.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div>Hi Andreas, \
</div><div><br></div><div>So, in that case does that mean, we are going to \
</div><div>1) revert all the improvements did to the local transport OR</div><div>2) \
just remove the NonBlockingTransportListener class only? </div>

<div><br></div><div>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. </div>

<div><br></div><div>If it is the second option, then we wont have to change that much \
of code level change. </div><div><br></div><div>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. </div> </blockquote><div><br>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.<br><br>It has hard coded the name local. but if you see \
this method same thing has done for http and https as well.<br> <br>thanks,<br>Amila. \
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5"> \
<br><div class="gmail_quote">On Thu, Jun 16, 2011 at 1:09 PM, Andreas Veithen <span \
dir="ltr">&lt;<a href="mailto:andreas.veithen@gmail.com" \
target="_blank">andreas.veithen@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">

Since there is a consensus that NonBlockingLocalTransportSender<br>
doesn&#39;t work with a pure Axis2 setup, is not unit testable and is only<br>
relevant for Synapse, the logical conclusion would be that it should<br>
not be included in Axis2 but in Synapse.<br>
<br>
Andreas<br>
<br>
On Thu, Jun 16, 2011 at 08:43, Heshan Suriyaarachchi<br>
<div><div></div><div>&lt;<a href="mailto:heshan.suriyaarachchi@gmail.com" \
target="_blank">heshan.suriyaarachchi@gmail.com</a>&gt; wrote:<br> &gt;<br>
&gt;<br>
&gt; On Wed, Jun 15, 2011 at 1:27 AM, Andreas Veithen &lt;<a \
href="mailto:andreas.veithen@gmail.com" \
target="_blank">andreas.veithen@gmail.com</a>&gt;<br> &gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Jun 14, 2011 at 08:48, Heshan Suriyaarachchi<br>
&gt;&gt; &lt;<a href="mailto:heshan.suriyaarachchi@gmail.com" \
target="_blank">heshan.suriyaarachchi@gmail.com</a>&gt; wrote:<br> &gt;&gt; &gt; Hi \
Devs,<br> &gt;&gt; &gt; I am opening up this thread to discuss $subject.<br>
&gt;&gt; &gt; Recently, I did some improvements [1] to the Axis2 local transport,<br>
&gt;&gt; &gt; inorder<br>
&gt;&gt; &gt; to get it working against Synapse nhttp transport. Now the local<br>
&gt;&gt; &gt; transport<br>
&gt;&gt; &gt; is working fine against the nhttp transport.<br>
&gt;&gt;<br>
&gt;&gt; To me the statement &quot;getting transport A working against transport \
B&quot;<br> &gt;&gt; doesn&#39;t make sense. Two distinct transports A and B never \
interact<br> &gt;&gt; directly. Each of them interacts with the Axis2 engine through \
(in<br> &gt;&gt; principle) well defined APIs. If a component (Synapse in this \
case)<br> &gt;&gt; based on Axis2 has an issue when using A and B together, then \
either<br> &gt;&gt; transport A, transport B, the component or the Axis2 engine has \
an<br> &gt;&gt; issue (or multiple components have an issue), but saying that<br>
&gt;&gt; transport A needs to be fixed to work with transport B doesn&#39;t make<br>
&gt;&gt; sense and is an indication that the fundamental issue has not been<br>
&gt;&gt; identified properly.<br>
&gt;&gt;<br>
&gt;&gt; At this point, what we know is this:<br>
&gt;&gt; * NHTTP doesn&#39;t work as a transport sender in a standard Axis2 setup<br>
&gt;&gt; [1]. It only works in Synapse. That means that from the point of view<br>
&gt;&gt; of Axis2, the NHTTP transport is broken. That is of course OK, because<br>
&gt;&gt; NHTTP is shipped with Synapse and nobody claims that it is supported<br>
&gt;&gt; in a plain Axis2 setup.<br>
&gt;&gt; * At some point I tried to figure out what would need to be changed to<br>
&gt;&gt; make the NHTTP transport work in Axis2. IIRC the conclusion was that<br>
&gt;&gt; one can make it work in Axis2, but then it no longer works in Synapse.<br>
&gt;&gt; This would indicate that Synapse actually uses the transport API in a<br>
&gt;&gt; way it was not designed for.<br>
&gt;&gt; * As indicated in AXIS2-4944, the current version of<br>
&gt;&gt; NonBlockingLocalTransportSender doesn&#39;t work in Axis2. Unless \
somebody<br> &gt;&gt; can come up with a valid unit test that exercises this piece of \
code,<br> &gt;&gt; this would mean that we introduced a broken piece of code in Axis2 \
in<br> &gt;&gt; order to work around another broken piece of code in a downstream<br>
&gt;&gt; project. That is of course not OK.<br>
&gt;&gt;<br>
&gt;&gt; Note that the issue with NonBlockingLocalTransportSender is also<br>
&gt;&gt; blocking the review of other issues such as AXIS2-4991, because it is<br>
&gt;&gt; not possible to construct a unit test that validates (or invalidates)<br>
&gt;&gt; the proposed patch. That is BTW a general issue with the recent<br>
&gt;&gt; patches for the local transport. As far as I can tell, none of them<br>
&gt;&gt; added any new unit tests.<br>
&gt;&gt;<br>
&gt;&gt; [1] At least that was my conclusion when I last looked at it. I&#39;m<br>
&gt;&gt; ready to retract that claim if somebody comes up with an example that<br>
&gt;&gt; shows how to set up a simple Axis2 client that uses NHTTP as outgoing<br>
&gt;&gt; transport.<br>
&gt;<br>
&gt; As Amila has pointed out earlier, NonBlockingLocalTransportSender is used to<br>
&gt; talk to a proxy service from another proxy service. Since the nhttp<br>
&gt; transport is written in a non blocking manner, NonBlockingLocalTransport<br>
&gt; will work seamlessly against nhttp transport. Since, we are using this<br>
&gt; TransportSender to talk between proxy services, it&#39;s difficult to come \
up<br> &gt; with a test case (test client) for this particular usecase.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; Now, my requirement is to expose an Synapse Proxy Service only in \
local<br> &gt;&gt; &gt; transport. The reason behind is that, these proxy services \
which are<br> &gt;&gt; &gt; exposed<br>
&gt;&gt; &gt; only in local transport will be used by other proxy services and \
will<br> &gt;&gt; &gt; not be<br>
&gt;&gt; &gt; available for outside parties. Earlier, axis2 local transport did \
not<br> &gt;&gt; &gt; have a<br>
&gt;&gt; &gt; TransportListener.<br>
&gt;&gt; &gt; With a TransportListener<br>
&gt;&gt; &gt; ====================<br>
&gt;&gt; &gt; I introduced [2] a TransportListener to the local transport. The<br>
&gt;&gt; &gt; transport<br>
&gt;&gt; &gt; listener&#39;s methods are used to calculate the endpoints for the \
service<br> &gt;&gt; &gt; which<br>
&gt;&gt; &gt; will be used in generating the WSDL for the service. Therefore, now \
if<br> &gt;&gt; &gt; the<br>
&gt;&gt; &gt; service exposed in the local transport, the local endpoint is also \
shown<br> &gt;&gt; &gt; in<br>
&gt;&gt; &gt; the WSDL. Although the local endpoints are shown in the WSDL, \
outside<br> &gt;&gt; &gt; parties can not access the local endpoint.<br>
&gt;&gt; &gt; The problem this patch introduce is, now the WSDL shows the local<br>
&gt;&gt; &gt; transport<br>
&gt;&gt; &gt; endpoints. Which is wrong since external users can not access local<br>
&gt;&gt; &gt; transport.<br>
&gt;&gt; &gt; So the solution is not to show the local transport endpoints in<br>
&gt;&gt; &gt; generated<br>
&gt;&gt; &gt; wsdl. For that we may have to change Axis2 code.<br>
&gt;&gt; &gt; eg: As an example, I am attaching the following resources to prove \
my<br> &gt;&gt; &gt; point.<br>
&gt;&gt; &gt; The synapse-config.xml is the Synapse Configuration and the \
attached<br> &gt;&gt; &gt; WSDLs<br>
&gt;&gt; &gt; are for the proxy servivces, LocalTransportProxy and SecondProxy. \
The<br> &gt;&gt; &gt; SecondProxy is exposed only via the local transport and the \
local<br> &gt;&gt; &gt; endpoints<br>
&gt;&gt; &gt; are shown in the WSDL which is wrong IMV.<br>
&gt;&gt; &gt; Without a TransportListener<br>
&gt;&gt; &gt; ======================<br>
&gt;&gt; &gt; If we did not have a LocalTransportListener and if a service is \
exposed<br> &gt;&gt; &gt; through local transport only, the WSDL for the service will \
not be<br> &gt;&gt; &gt; generated. The reason behind is that; inorder to generate \
the WSDL,<br> &gt;&gt; &gt; there<br>
&gt;&gt; &gt; should be a mechanism to derive the endpoints for the service. \
Since,<br> &gt;&gt; &gt; the<br>
&gt;&gt; &gt; TransportListener is not there, there is no mechanism to derive the<br>
&gt;&gt; &gt; endpoints for the service(which is only exposed through the local<br>
&gt;&gt; &gt; transport).<br>
&gt;&gt; &gt; In case the service exposed through http,https,local transports; \
this<br> &gt;&gt; &gt; wont<br>
&gt;&gt; &gt; be the case. Then the WSDL will be generated and only the \
http,https<br> &gt;&gt; &gt; endpoints will be shown.<br>
&gt;&gt; &gt; Without the listener, if we expose a service only in local \
transport,<br> &gt;&gt; &gt; WSDL<br>
&gt;&gt; &gt; generation fails since the endpoints can not be derived for that<br>
&gt;&gt; &gt; particular<br>
&gt;&gt; &gt; service.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Your ideas and feedback on $subject is much appreciated.<br>
&gt;&gt; &gt; [1] - <a href="https://issues.apache.org/jira/browse/AXIS2-4944" \
target="_blank">https://issues.apache.org/jira/browse/AXIS2-4944</a><br> &gt;&gt; \
&gt; [2] - <a href="https://issues.apache.org/jira/browse/AXIS2-5043" \
target="_blank">https://issues.apache.org/jira/browse/AXIS2-5043</a><br> &gt;&gt; \
&gt;<br> &gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Regards,<br>
&gt;&gt; &gt; Heshan Suriyaarachchi<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; <a href="http://heshans.blogspot.com/" \
target="_blank">http://heshans.blogspot.com/</a><br> &gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; ---------------------------------------------------------------------<br>
 &gt;&gt; &gt; To unsubscribe, e-mail: <a \
href="mailto:java-dev-unsubscribe@axis.apache.org" \
target="_blank">java-dev-unsubscribe@axis.apache.org</a><br> &gt;&gt; &gt; For \
additional commands, e-mail: <a href="mailto:java-dev-help@axis.apache.org" \
target="_blank">java-dev-help@axis.apache.org</a><br> &gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; ---------------------------------------------------------------------<br>
&gt;&gt; To unsubscribe, e-mail: <a \
href="mailto:java-dev-unsubscribe@axis.apache.org" \
target="_blank">java-dev-unsubscribe@axis.apache.org</a><br> &gt;&gt; For additional \
commands, e-mail: <a href="mailto:java-dev-help@axis.apache.org" \
target="_blank">java-dev-help@axis.apache.org</a><br> &gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Regards,<br>
&gt; Heshan Suriyaarachchi<br>
&gt;<br>
&gt; <a href="http://heshans.blogspot.com/" \
target="_blank">http://heshans.blogspot.com/</a><br> &gt;<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href="mailto:java-dev-unsubscribe@axis.apache.org" \
target="_blank">java-dev-unsubscribe@axis.apache.org</a><br> For additional commands, \
e-mail: <a href="mailto:java-dev-help@axis.apache.org" \
target="_blank">java-dev-help@axis.apache.org</a><br> <br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- \
<br><div><div></div><div class="h5">Regards,<br>Heshan Suriyaarachchi<br><br><a \
href="http://heshans.blogspot.com/" \
target="_blank">http://heshans.blogspot.com/</a><br>

</div></div></blockquote></div><br><br clear="all"><br>-- <br>Amila \
Suriarachchi<br>WSO2 Inc.<br>blog: <a \
href="http://amilachinthaka.blogspot.com/">http://amilachinthaka.blogspot.com/</a><br>


--20cf303f6e8251f68604a683dd4e--


["patch.txt" (text/plain)]

Index: src/org/apache/axis2/deployment/util/Utils.java
===================================================================
--- src/org/apache/axis2/deployment/util/Utils.java	(revision 1135082)
+++ src/org/apache/axis2/deployment/util/Utils.java	(working copy)
@@ -1081,7 +1081,9 @@
             ArrayList transports = new ArrayList();
             for (Object o : axisConfiguration.getTransportsIn().values()) {
                 TransportInDescription transportInDescription = (TransportInDescription)o;
-                transports.add(transportInDescription.getName());
+                if (!transportInDescription.getName().equals("local")){
+                   transports.add(transportInDescription.getName());
+                }
             }
             transportInValues = transports.iterator();
         }

["LocalTransportListener.java" (text/x-java)]

/*
 * Copyright 2004,2005 The Apache Software Foundation.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.axis2.transport.local;

import org.apache.axis2.transport.TransportListener;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.SessionContext;
import org.apache.axis2.context.MessageContext;
import org.apache.axis2.description.TransportInDescription;
import org.apache.axis2.AxisFault;
import org.apache.axis2.addressing.EndpointReference;

public class LocalTransportListener implements TransportListener{

    @Override
    public void init(ConfigurationContext axisConf, TransportInDescription transprtIn) throws AxisFault {

    }

    @Override
    public void start() throws AxisFault {

    }

    @Override
    public void stop() throws AxisFault {

    }

    @Override
    public EndpointReference getEPRForService(String serviceName, String ip) throws AxisFault {
        return  new EndpointReference("local://localhost/");
    }

    @Override
    public EndpointReference[] getEPRsForService(String serviceName, String ip) throws AxisFault {
        EndpointReference epr = new EndpointReference("local://localhost/");
        return new EndpointReference[]{epr};
    }

    @Override
    public SessionContext getSessionContext(MessageContext messageContext) {
        return null;
    }

    @Override
    public void destroy() {

    }
}


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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic