Hi,
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? > Attaching the patch for the fix done. Thanks, Lakmali > > 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 > * > * > > -- Lakmali Baminiwatta* * Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware mobile: +94 71 2335936 * *
CalloutFix.patch
Description: Binary data
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
