Well, I think it's kind of working now... cxf bc consumer is still doing in/out but it delegates to wiretap, the wiretap send the message to cxfse and also to cxfbc:producer which is doing an in-only mep (or is it out-only ?) as it's using a person2.wsdl with output/faults removed.
so it appears a message is dropped to the queue (JConsole is not quite helpful) abd the browser gets it 200 OK and cxfse gets invoked along the way too. May be it's still an illusion that it is working. I'll try the actual test tomorrow... Sergey Beryozkin wrote: > > Hi Freeman > >> I think you also need remove fault part > I did... > >> And how about add defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; > > I tried but I think either cxf bc consumer or cxf bc provider did not > support it (a setter) > > will keep trying... > > cheers, Sergey > > > > Freeman Fang wrote: >> >> Hi Sergey, >> >> I think you also need remove fault part of the operation/binding from >> wsdl as oneway shouldn't include output and fault. >> And how about add defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; >> to all http endpoint in the flow? >> >> Regards >> Freeman >> On 2009-10-29, at 下午9:33, Sergey Beryozkin wrote: >> >>> >>> Hi Freeman >>> >>> After commenting out the "<output>" bits in portType/operation and >>> binding/operation in the wsdl shipped with cxf-bc-su I can see >>> cxfbc;consumer delegating to cxfbc:provider : >>> >>> 13:13:54,671 | DEBUG | /PersonService/ | >>> NMR | >>> .servicemix.nmr.core.ChannelImpl 198 | Channel >>> org.apache.servicemix.nmr.core.channeli...@9c62da delivering >>> exchange: [ >>> id: 23b54014-555a-422f-8c7e-bc90695ce464 >>> mep: InOnly >>> status: Active >>> role: Consumer >>> target: >>> PropertyMatchingReference[{SERVICE_NAME={http://servicemix.apache.org/samples/wsdl-first >>> >>> }PersonService, >>> ENDPOINT_NAME=pojo3}] >>> operation: {http://servicemix.apache.org/samples/wsdl-first}GetPerson >>> properties: [ >>> javax.jbi.ServiceEndpoint = >>> org.apache.servicemix.jbi.runtime.impl.serviceendpointi...@127510b >>> javax.jbi.messaging.MessageExchange = >>> org.apache.servicemix.jbi.runtime.impl.inonlyi...@39d3d3 >>> javax.jbi.messaging.sendSync = <null> >>> javax.jbi.ServiceName = >>> {http://servicemix.apache.org/samples/wsdl-first}PersonService >>> org.apache.servicemix.correlationId = >>> 23b54014-555a-422f-8c7e-bc90695ce464 >>> javax.jbi.transaction.jta = <null> >>> javax.jbi.InterfaceName = >>> {http://servicemix.apache.org/samples/wsdl-first}Person >>> org.apache.servicemix.senderEndpoint = >>> {http://servicemix.apache.org/samples/wsdl-first}PersonService:pojo >>> ] >>> In: [ >>> content: <?xml version="1.0" encoding="UTF-8"?><jbi:message >>> xmlns:jbi="http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper"; >>> xmlns:msg="http://servicemix.apache.org/samples/wsdl-first"; >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> name="GetPersonRequest" type="msg:GetPersonRequest" >>> version="1.0"><jbi:part><tns:GetPerson >>> xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; >>> xmlns:tns="http://servicemix.apache.org/samples/wsdl-first/types";> >>> <tns:personId>world</tns:personId> >>> </tns:GetPerson></jbi:part></jbi:message> >>> properties: [ >>> javax.jbi.messaging.protocol.headers = {} >>> ] >>> ] >>> ] >>> >>> and then a provider invoking : >>> >>> 13:13:54,749 | DEBUG | -cxf-bc-thread-2 | >>> HTTPConduit | >>> e.cxf.transport.http.HTTPConduit 933 | Sending POST Message with >>> Headers to >>> http://localhost:9001/PersonService/ Conduit >>> :{http://servicemix.apache.org/samples/wsdl-first}pojo3.http-conduit >>> Content-Type: text/xml; charset=UTF-8 >>> >>> However, immediately after that I can see : >>> >>> java.io.IOException: An existing connection was forcibly closed by the >>> remote host >>> >>> and this is together with >>> >>> 13:13:54,780 | DEBUG | /PersonService/ | >>> jetty | >>> .service.internal.util.JCLLogger 85 | servlet holder=jbiServlet >>> 13:13:54,780 | DEBUG | /PersonService/ | >>> HttpComponent | >>> p.endpoints.HttpConsumerEndpoint 276 | Receiving HTTP request: POST >>> /PersonService/ HTTP/1.1 >>> Content-Type: text/xml; charset=UTF-8 >>> >>> which confirms the final http consumer gets this message >>> >>> and then >>> >>> 13:14:20,671 | DEBUG | NetworkBridge | >>> DemandForwardingBridge | >>> .DemandForwardingBridgeSupport$5 373 | Caught exception sending >>> shutdown >>> org.apache.activemq.transport.InactivityIOException: Channel was >>> inactive >>> for too long: Heather820/10.5.2.22:61616 >>> at >>> org >>> .apache >>> .activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java: >>> 229) >>> at >>> org >>> .apache >>> .activemq.transport.TransportFilter.oneway(TransportFilter.java:83) >>> at >>> org >>> .apache >>> .activemq >>> .transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:104) >>> at >>> org >>> .apache.activemq.transport.MutexTransport.oneway(MutexTransport.java: >>> 40) >>> at >>> org >>> .apache >>> .activemq >>> .transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) >>> at >>> org.apache.activemq.network.DemandForwardingBridgeSupport >>> $5.run(DemandForwardingBridgeSupport.java:371) >>> at >>> java.util.concurrent.ThreadPoolExecutor >>> $Worker.runTask(ThreadPoolExecutor.java:650) >>> at >>> java.util.concurrent.ThreadPoolExecutor >>> $Worker.run(ThreadPoolExecutor.java:675) >>> at java.lang.Thread.run(Thread.java:595) >>> 13:14:21,703 | ERROR | -cxf-bc-thread-2 | >>> CxfBcComponent | >>> icemix.common.AsyncBaseLifeCycle 480 | Error processing exchange >>> org.apache.servicemix.jbi.runtime.impl.inonlyi...@39d3d3 >>> org.apache.servicemix.nmr.core.ChannelClosedException >>> at >>> org.apache.servicemix.nmr.core.ChannelImpl.dispatch(ChannelImpl.java: >>> 268) >>> >>> >>> I'm confused :-) >>> I reckon I can deal with improving the test once I can the basic >>> route being >>> up and running :-) >>> >>> cheers, Sergey >>> >>> >>> Freeman Fang wrote: >>>> >>>> Hi Sergey, >>>> >>>> Cxf bc provider/consumer determine the MEP from the wsdl model, so if >>>> it's oneway in wsdl, then it's InOnly exchange. >>>> So I guess the problem may come from that the method defined in your >>>> wsdl isn't oneway, so that cxf bc provider expect some response from >>>> the queue. >>>> If you want to use InOnly MEP for cxf bc provider, ensure the method >>>> in wsdl is oneway. >>>> >>>> Btw, your test flow include http provider ==> cxf bc consumer over >>>> http and cxf bc provider ==> http consumer over http, that's ok, if >>>> it >>>> also can include something like >>>> cxf bc consumer==>http provider through NMR and http consumer===>cxf >>>> bc provider through NMR, that would be great. >>>> >>>> >>>> Best Regards >>>> Freeman >>>> >>>> On 2009-10-29, at 下午8:15, Sergey Beryozkin wrote: >>>> >>>>> >>>>> Hi JB, >>>>> >>>>> I'm not quite sure what you mean when you say 'with the map', but >>>>> I'll try >>>>> to give more info... >>>>> >>>>> The test service assembly has 3 units, http-in-su, cxf-bc-su, jms- >>>>> su. >>>>> >>>>> 1. http-in-su : >>>>> >>>>> <beans xmlns:http="http://servicemix.apache.org/http/1.0"; >>>>> xmlns:person="http://servicemix.apache.org/samples/wsdl-first";> >>>>> <!-- gets the initial request and redirects to 'soap2' --> >>>>> <http:soap-consumer service="person:PersonService" >>>>> endpoint="soap" >>>>> targetEndpoint="soap2" >>>>> targetService="person:PersonService" >>>>> locationURI="http://0.0.0.0:8192/PersonService/"; >>>>> defaultMep="http://www.w3.org/2004/08/wsdl/in-only >>>>> " >>>>> wsdl="classpath:person.wsdl"/> >>>>> >>>>> <!-- sends it to the external service exposed by cxfbc:consumer --> >>>>> <http:soap-provider service="person:PersonService" >>>>> endpoint="soap2" >>>>> interfaceName="person:Person" >>>>> locationURI="http://localhost:9000/PersonService/"; >>>>> wsdl="classpath:person.wsdl"/> >>>>> >>>>> <!-- gets the message from the cxf:bc provider and drops it to the >>>>> queue >>>>> --> >>>>> >>>>> <http:soap-consumer service="person:PersonService" >>>>> endpoint="soap3" >>>>> targetService="person:jms" >>>>> locationURI="http://localhost:9001/ >>>>> PersonService/" >>>>> defaultMep="http://www.w3.org/2004/08/wsdl/in-only >>>>> " >>>>> wsdl="classpath:person.wsdl"/> >>>>> >>>>> </beans> >>>>> >>>>> person.wsdl has 3 ports for PersonService, named soap, soap2 and >>>>> soap3. >>>>> >>>>> Next is the cxfbc-su : >>>>> >>>>> >>>>> <beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0"; >>>>> xmlns:person="http://servicemix.apache.org/samples/wsdl-first";> >>>>> >>>>> <!-- gets the message sent from a http:soap-provider 'soap2' >>>>> endpoint and >>>>> redirects to cxf:bc provider --> >>>>> >>>>> <cxfbc:consumer wsdl="classpath:person.wsdl" >>>>> targetService="person:PersonService" >>>>> targetInterface="person:Person" >>>>> endpoint="pojo" >>>>> targetEndpoint="pojo2"/> >>>>> >>>>> <!-- sends it back to the http:soap-consumer 'soap3' --> >>>>> <cxfbc:provider wsdl="classpath:person.wsdl" >>>>> locationURI="http://localhost:9001/ >>>>> PersonService/" >>>>> service="person:PersonService" >>>>> endpoint="pojo2" >>>>> interfaceName="person:Person"/> >>>>> </beans> >>>>> >>>>> The person.wsdl shipped with the cxf-bc su has two ports named >>>>> 'pojo' and >>>>> 'pojo2'. >>>>> >>>>> There's also a jms su which the 'soap3' endpoint delegates to : >>>>> >>>>> beans xmlns:jms="http://servicemix.apache.org/jms/1.0"; >>>>> xmlns:person="http://servicemix.apache.org/samples/wsdl-first";> >>>>> <jms:endpoint service="person:jms" >>>>> endpoint="jmsendpoint" >>>>> role="provider" >>>>> destinationStyle="queue" >>>>> jmsProviderDestinationName="bridge.output" >>>>> connectionFactory="#connectionFactory" /> >>>>> <bean id="connectionFactory" >>>>> class="org.apache.activemq.ActiveMQConnectionFactory"> >>>>> <property name="brokerURL" value="tcp://localhost:61616" /> >>>>> </bean> >>>>> </beans> >>>>> >>>>> Let me know please if I can provide more info... >>>>> There're some log entries here : http://pastebin.com/m7180a31e >>>>> >>>>> I'm going to look into it further. The interesting thing is that >>>>> if I >>>>> introduce cxf:se endpoint into the route and have a cxf:bc consumer >>>>> delegating to it (as opposed to cxfbc:provider) then the cxf:se >>>>> endpoint >>>>> gets called and the initiator (browser) gets the 200 OK back... >>>>> >>>>> So I'm wondering may be I need to add a cxf:se and a wiretap, for >>>>> the >>>>> cxfbc:consumer to delegate to this wiretap instead, and with the >>>>> wiretap >>>>> targeting the cxfse, but also copying the request (through >>>>> inListener) to >>>>> the cxfbc:provider.... >>>>> >>>>> thanks, Sergey >>>>> >>>>> >>>>> Jean-Baptiste Onofré wrote: >>>>>> >>>>>> Hi Sergey, >>>>>> >>>>>> Could you provide the xbeans used (especially with the map) ? >>>>>> >>>>>> Thx, >>>>>> Regards >>>>>> JB >>>>>> ------Original Message------ >>>>>> From: Sergey Beryozkin >>>>>> To: [email protected] >>>>>> ReplyTo: [email protected] >>>>>> Subject: servicemix-http and cxf-bc interoperability >>>>>> Sent: Oct 29, 2009 11:59 >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm working on a test which has to verify that servicemix-http and >>>>>> cxf-bc >>>>>> components can interoperate (using soap payloads just for now). >>>>>> >>>>>> So I'm trying to build a route which can be initiated by the test. >>>>>> The route can be described as follows : >>>>>> >>>>>> 1. The test sends a SOAP request to the HTTP SOAP consumer (port >>>>>> 8192, >>>>>> endpoint 'soap') which gets and and routes it to the HTTP SOAP >>>>>> provider >>>>>> (endpoint 'soap2') which pushes it further to a service endpoint >>>>>> listening >>>>>> on localhost:9000. >>>>>> >>>>>> 2. CXF BC consumer listening on localhost:9000 receives it and >>>>>> routes it >>>>>> to >>>>>> CXF BC provider which pushes it further to a service endpoint >>>>>> listening on >>>>>> localhost:9001. >>>>>> >>>>>> 3. HTTP SOAP consumer (port 9001, endpoint 'soap3') gets the soap >>>>>> request >>>>>> and drops it to a jms queue which will be checked by the test. >>>>>> >>>>>> I've gone ahead with implementing this route and it appears that >>>>>> the >>>>>> initial >>>>>> message is received at 1 and eventually dropped to the queue, >>>>>> however I'm >>>>>> seeing that the initiator (the browser in this case) gets HTTP 500 >>>>>> due to >>>>>> one of the exchanges expiring. >>>>>> >>>>>> I've posted some more details here : >>>>>> >>>>>> http://pastebin.com/m7180a31e >>>>>> >>>>>> >>>>>> I have few questions. >>>>>> >>>>>> Is this test route built correctly, given what needs to be tested ? >>>>>> >>>>>> Why the initiator does not get the confirmation like 202/200 back >>>>>> given >>>>>> that >>>>>> an initial soap consumer is listening in the in-only mode ? >>>>>> >>>>>> I think the problem has to do with the fact that a cxfbc:provider >>>>>> expects >>>>>> some response back but the final http soap consumer just drops >>>>>> the in >>>>>> message to the queue so cxfbc:provider fails. >>>>>> >>>>>> Any hints will be appreciated >>>>>> >>>>>> thanks, Sergey >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://www.nabble.com/servicemix-http-and-cxf-bc-interoperability-tp26110897p26110897.html >>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/servicemix-http-and-cxf-bc-interoperability-tp26110897p26111901.html >>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> -- >>>> Freeman Fang >>>> ------------------------ >>>> Open Source SOA: http://fusesource.com >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/servicemix-http-and-cxf-bc-interoperability-tp26110897p26113149.html >>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>> >> >> >> -- >> Freeman Fang >> ------------------------ >> Open Source SOA: http://fusesource.com >> >> >> > > -- View this message in context: http://www.nabble.com/servicemix-http-and-cxf-bc-interoperability-tp26110897p26118159.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
