Hi all,

On Wed, Jul 11, 2012 at 6:23 PM, Supun Kamburugamuva <[email protected]>wrote:

> The server config context has the nhttp transport as the http transport.
> So callout mediator will pick this transport if we use the server
> configuration context. We should have a proper naming for the transports in
> axis2 before we can do this. i.e. At the moment axis2 thinks that the name
> of the transport is equal to the protocol name of the transport.


We were able to use Callout mediator with local transport by doing some
modifications to the synapse Callout mediator. We are proposing to add an
attribute 'useServerConfig' to the callout mediator which will use server
configuration context if set as true. By default it will be false and
Client configuration context will be used.

So to use the Server Configuration in Callout mediator, the configuration
will be,

<callout serviceURL="local://localhost/services/DTPSampleService"
action="urn:addToAccountBalanceInBank2" useServerConfig="true">
                <source xpath="$body/child::*[fn:position()=1]"/>
                <target xpath="$body/child::*[fn:position()=1]"/>
 </callout>

The modification done to the Callout Mediator was changing the init method
of CalloutMediator.java

public void init(SynapseEnvironment synEnv) {
        try {
            if (useServerConfig) {
                configCtx = ((Axis2SynapseEnvironment)
synEnv).getAxis2ConfigurationContext();
            } else {
                configCtx =
ConfigurationContextFactory.createConfigurationContextFromFileSystem(
                         clientRepository != null ? clientRepository :
DEFAULT_CLIENT_REPO,
                 axis2xml != null ? axis2xml : DEFAULT_AXIS2_XML);
            }
        } catch (AxisFault e) {
            String msg = "Error initializing callout mediator : " +
e.getMessage();
            log.error(msg, e);
            throw new SynapseException(msg, e);
        }
    }

When *useServerConfig* is set true, the *configCtx* will be initialized
with Server Configuration Context as in Send mediator.

Shall we proceed with this solution?

Thanks,
Lakmali

>
> Thanks,
> Supun..
>
>
> On Wed, Jul 11, 2012 at 4:46 AM, Lakmali Baminiwatta <[email protected]>wrote:
>
>> Hi,
>>
>> How can we proceed if we are going to change the Callout mediator to use
>> the server config context as well?
>>
>> Thanks,
>> Lakmali
>>
>>
>>
>> On Tue, Jul 10, 2012 at 11:39 PM, Kasun Indrasiri <[email protected]> wrote:
>>
>>> However, following scenario seems to work fine. Seems this is not the
>>> expected behavior.
>>>
>>>    <proxy name="EchoProxy" transports="https http" startOnLoad="true"
>>> trace="disable">
>>>         <description/>
>>>         <target>
>>>             <inSequence>
>>>
>>>                 <callout serviceURL="local://services/echo"
>>> action="urn:echoString">
>>>                     <source xmlns:s12="
>>> http://www.w3.org/2003/05/soap-envelope"; xmlns:s11="
>>> http://schemas.xmlsoap.org/soap/envelope/";
>>> xpath="s11:Body/child::*[fn:position()=1] |
>>> s12:Body/child::*[fn:position()=1]"/>
>>>                     <target xmlns:s12="
>>> http://www.w3.org/2003/05/soap-envelope"; xmlns:s11="
>>> http://schemas.xmlsoap.org/soap/envelope/";
>>> xpath="s11:Body/child::*[fn:position()=1] |
>>> s12:Body/child::*[fn:position()=1]"/>
>>>                 </callout>
>>>                 <property name="RESPONSE" value="true"/>
>>>                 <header name="To" action="remove"/>
>>>                 <send/>
>>>             </inSequence>
>>>             <outSequence>
>>>                 <send/>
>>>             </outSequence>
>>>         </target>
>>>     </proxy>
>>>
>>> On Tue, Jul 10, 2012 at 10:23 PM, Supun Kamburugamuva <[email protected]
>>> > wrote:
>>>
>>>> For the local transport to work both the invoker and the invoking
>>>> service should be in the same configuration context. So this scenario will
>>>> never work with the local transport + callout mediator.
>>>>
>>>> Thanks,
>>>> Supun..
>>>>
>>>> On Tue, Jul 10, 2012 at 12:48 PM, Hiranya Jayathilaka <[email protected]
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 10, 2012 at 5:50 PM, Lakmali Baminiwatta <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Tue, Jul 10, 2012 at 5:26 PM, Hiranya Jayathilaka <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Send mediator and callout mediator use different
>>>>>>> ConfigurationContext instances. Former uses the server cfgctx and the
>>>>>>> latter uses the client cfgctx. That should be the problem.
>>>>>>
>>>>>>
>>>>>> I have enabled local transport on
>>>>>> samples/axis2Client/client_repo/conf/axis2.xml. Does it require more
>>>>>> configurations to the client cfgctx ?
>>>>>>
>>>>>
>>>>> I think the local transport looks up the cfgctx to find the target
>>>>> AxisService. So unless you somehow use the server cfgctx in the callout
>>>>> mediator, this scenario will never work. Better to debug and confirm - I'm
>>>>> not 100% certain.
>>>>>
>>>>>
>>>>>>
>>>>>>> If you're using the local transport, it doesn't matter which
>>>>>>> mediator you use performance wise. So why not just use the send 
>>>>>>> mediator?
>>>>>>>
>>>>>>
>>>>>> The requirement is to get the response from the endpoint in the same
>>>>>> sequence. For instance with send mediator , when the operation at the
>>>>>> endpoint is failed and soap fault is returned, it will go to the
>>>>>> outSequence. Is there a way to jump to the fault sequence once a soap 
>>>>>> fault
>>>>>> has returned from the endpoint?
>>>>>>
>>>>>
>>>>> Use a simple filter in the out-sequence to check the message and jump
>>>>> to the fault sequence. It will be something like this:
>>>>>
>>>>> <filter xpath="get-property('FAULT')">
>>>>>    <sequence key="my_fault_seq"/>
>>>>>    <drop/>
>>>>> </filter>
>>>>>
>>>>> Thanks,
>>>>> Hiranya
>>>>>
>>>>>
>>>>>>
>>>>>> I am trying to do a distributed transaction between dataservice
>>>>>> endpoints, using ESB transport mediator. When an operation in one of the
>>>>>> data service endpoint has failed, the soap fault message will be received
>>>>>> in the out sequence. As a result we are facing a problem of where to call
>>>>>> rollback action on transport mediator.
>>>>>>
>>>>>> Thanks,
>>>>>> Lakmali
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hiranya
>>>>>>>
>>>>>>> On Tue, Jul 10, 2012 at 1:44 PM, Lakmali Baminiwatta <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 10, 2012 at 1:09 PM, Lakmali Baminiwatta <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am trying to configure ESB Callout mediator to access a
>>>>>>>>> dataservice endpoint through local transport. I have enabled local
>>>>>>>>> transport on samples/axis2Client/client_repo/conf/axis2.xml.
>>>>>>>>>
>>>>>>>>> I configured the callout mediator serviceURL and action as follows,
>>>>>>>>>
>>>>>>>>> * <callout serviceURL="
>>>>>>>>> http://localhost:8282/services/updateNonxaTrans "
>>>>>>>>> action="urn:UpdateXATransOp">
>>>>>>>>> *
>>>>>>>>
>>>>>>>>
>>>>>>>> The callout mediator configuration I used  was,
>>>>>>>> *
>>>>>>>> <callout serviceURL="local://localhost/services/updateNonxaTrans**"
>>>>>>>> action="urn:UpdateXATransOp">*
>>>>>>>>
>>>>>>>> I have mistakenly mentioned a wrong URL above.
>>>>>>>>
>>>>>>>>> *
>>>>>>>>> *I am getting the following error while invoking the service.
>>>>>>>>>
>>>>>>>>> ERROR - AxisEngine The service cannot be found for the endpoint
>>>>>>>>> reference (EPR) local://localhost/services/updateNonxaTrans
>>>>>>>>> org.apache.axis2.AxisFault: The service cannot be found for the
>>>>>>>>> endpoint reference (EPR) local://localhost/services/updateNonxaTrans
>>>>>>>>>     at
>>>>>>>>> org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:78)
>>>>>>>>>     at org.apache.axis2.engine.Phase.invoke(Phase.java:329)
>>>>>>>>>     at
>>>>>>>>> org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:262)
>>>>>>>>>     at
>>>>>>>>> org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:168)
>>>>>>>>>
>>>>>>>>> But the endpoint works when configured with send mediator.
>>>>>>>>>
>>>>>>>>> How can we use callout mediator to access endpoints through local
>>>>>>>>> transport?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Lakmali
>>>>>>>>> --
>>>>>>>>> Lakmali Baminiwatta*
>>>>>>>>> *
>>>>>>>>> Software Engineer
>>>>>>>>> WSO2, Inc.: http://wso2.com
>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Lakmali Baminiwatta*
>>>>>>>> *
>>>>>>>> Software Engineer
>>>>>>>> WSO2, Inc.: http://wso2.com
>>>>>>>> lean.enterprise.middleware
>>>>>>>> mobile:  +94 71 2335936
>>>>>>>> *
>>>>>>>> *
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hiranya Jayathilaka
>>>>>>> Senior Technical Lead;
>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>> E-mail: [email protected];  Mobile: +94 77 633 3491
>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lakmali Baminiwatta*
>>>>>> *
>>>>>> Software Engineer
>>>>>> WSO2, Inc.: http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>> mobile:  +94 71 2335936
>>>>>> *
>>>>>> *
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hiranya Jayathilaka
>>>>> Senior Technical Lead;
>>>>> WSO2 Inc.;  http://wso2.org
>>>>> E-mail: [email protected];  Mobile: +94 77 633 3491
>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> [email protected]
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Supun Kamburugamuva
>>>> Member, Apache Software Foundation; http://www.apache.org
>>>> E-mail: [email protected] <[email protected]>;  Mobile: +94 77 431 3585
>>>> Blog: http://supunk.blogspot.com
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Kasun Indrasiri
>>> Associate Technical Lead
>>>
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> cell: +94 71 536 4128
>>> Blog : http://kasunpanorama.blogspot.com/
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [email protected]
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Lakmali Baminiwatta*
>> *
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> mobile:  +94 71 2335936
>> *
>> *
>>
>>
>
>
> --
> Supun Kamburugamuva
> Member, Apache Software Foundation; http://www.apache.org
> E-mail: [email protected] <[email protected]>;  Mobile: +94 77 431 3585
> Blog: http://supunk.blogspot.com
>
>
>
>


-- 
Lakmali Baminiwatta*
*
Software Engineer
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
mobile:  +94 71 2335936
*
*
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to