On Mon, Jul 16, 2012 at 3:09 PM, Hiranya Jayathilaka <[email protected]>wrote:
> The server configuration of Synapse usually has the non-blocking > transports. That may have an effect on the thread model of the callout > mediator. this property is only to use with local transport. If some one needs http transport they should not enable this property. thanks, Amila. > > Thanks, > Hiranya > > > On Mon, Jul 16, 2012 at 2:33 PM, Amila Suriarachchi <[email protected]>wrote: > >> >> >> On Fri, Jul 13, 2012 at 4:47 PM, Lakmali Baminiwatta <[email protected]>wrote: >> >>> 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? >>> >> >> +1. This allows to use the call out mediator with local transport as well. >> >> thanks, >> Amila. >> >>> >>> 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 >>> >>> >> >> >> -- >> *Amila Suriarachchi* >> >> Software Architect >> WSO2 Inc. ; http://wso2.com >> lean . enterprise . middleware >> >> phone : +94 71 3082805 >> >> >> _______________________________________________ >> 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 > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
