[
https://issues.apache.org/activemq/browse/CAMEL-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53007#action_53007
]
Ron Gavlin edited comment on CAMEL-1818 at 7/29/09 2:04 AM:
------------------------------------------------------------
Hi Willem,
Thanks for the unit test in CAMEL-1856. Unfortunately, it is not completely
clear to me that the test case reproduces my problem. In my case, I guess I am
looking for another level of indirection where the HelloWorld proxy gets
injected into the JbiServiceProcessor. Then in the JbiServiceProcessor
proxy.echo() is invoked to send a message to a jbi endpoint (maybe a smx-cxf-se
endpoint or maybe a smx-cxf-bc endpoint). Maybe the only real way to
demonstrate this is to write a test in smx-camel that bundles and leverages the
camel-cxf component to implement this functionality.
The smx-camel cxf client proxy test would essentially look just like smx-cxf-se
test
http://svn.apache.org/viewvc/servicemix/smx3/branches/servicemix-3.2/deployables/serviceengines/servicemix-cxf-se/src/test/java/org/apache/servicemix/cxfse/CxfSeClientProxyTest.java?view=co
except it would be re-implemented to test the Cxf client proxy in smx-camel
instead of smx-cxf-se. This would demonstrate how the cxf client proxy is
configured in smx-camel and verify that all the cxf client proxy features
available in smx-cxf-se are also available in smx-camel with the bundled
camel-cxf component using the jbi binding.
Does that make sense?
/Ron
was (Author: rgavlin):
Hi Willem,
Thanks for the unit test in CAMEL-1856. Unfortunately, it is not completely
clear to me that the test case reproduces my problem. In my case, I guess I am
looking for another level of indirection where the HelloWorld proxy gets
injected into the JbiServiceProcessor. Then in the JbiServiceProcessor
proxy.echo() is invoked to send a message to a jbi endpoint (maybe a smx-cxf-se
endpoint or maybe a smx-cxf-bc endpoint). Maybe the only real way to
demonstrate this is to write a test in smx-camel that bundles and leverages the
camel-cxf component to implement this functionality.
The smx-camel cxf client proxy test would essentially look just like
smx-cxff-se test
http://svn.apache.org/viewvc/servicemix/smx3/branches/servicemix-3.2/deployables/serviceengines/servicemix-cxf-se/src/test/java/org/apache/servicemix/cxfse/CxfSeClientProxyTest.java?view=co
except it would be re-implemented to test the Cxf client proxy in smx-camel
instead of smx-cxf-se. This would demonstrate how the cxf client proxy is
configured in smx-camel and verify that all the cxf client proxy features
available in smx-cxf-se are also available in smx-camel with the bundled
camel-cxf component using the jbi binding.
Does that make sense?
/Ron
> camel-cxf should fully support cxf jbi transport
> ------------------------------------------------
>
> Key: CAMEL-1818
> URL: https://issues.apache.org/activemq/browse/CAMEL-1818
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-cxf
> Affects Versions: 1.6.0
> Reporter: Ron Gavlin
> Assignee: Willem Jiang
>
> I would like to incorporate the camel-cxf component into smx-camel and use
> wsdl2java-generated stubs to send jbi requests and receive jbi responses from
> smx-cxf-bc and smx-cxf-se endpoints. Essentially, what I can do today in the
> smx-cxf-se container with proxies I would also like to be able to do in the
> smx-camel.
> The discussion on this topic with willem and ffang is pasted below.
> <rong> willem: i have code currently running in smx-cxf-se that I
> would like to move into smx-camel. The code in smx-cxf-se uses wsdl2java to
> proxy to a smx-cxf-bc provider. If I bundle the camel-cxf component within
> smx-camel, should I be able to port this code over from smx-cxf-se to
> smx-camel?
> <rong> willem: of course, I would provide a jbi location uri as the
> proxy address.
> <willem> rong: wsdl2java generated artifacts can be used in
> camel-cxf.
> <rong> willem: so in this scenario, I am not explicitly using
> camel-cxf at all. I presume it is being used behind the scenes to send a
> camel CxfExchange which then gets converted into a jbi exchange on its way to
> the smx-cxf-bc provider. Is that how you would understand it?
> <rong> willem: the smx-cxf-bc provider allows me to share the same jbi
> endpoint configuration across numerous camel routes defined in different
> smx-camel sus.
> <willem> rong: Do you still want to use the smx-cxf-bc for the
> transport work ?
> <willem> rong: are you using SMX 3?
> <rong> willem: i see it as providing a single exit/entry point on the
> bus that can be shared across numerous camel routes. Yes, I am still on smx3.
> <willem> rong: do you just want route the jbi message to camel
> and let camel call the POJO as the smx-cxf-se does?
> <rong> willem: what advantage would defining a separate smx-camel su
> with a route "from jbi to cxf" have over directly using the smx-cxf-bc
> provider?
> <rong> willem: no, i have a service that choreographs multiple
> external SOAP services. Today, the work is done in smx-cxf-se. It would be
> more convenient to do the choreography work in camel where I can inline other
> mediation/routing operations with the external SOAP service invocations.
> <rong> willem: I know how the smx-cxf-se proxies to smx-cxf-bc
> provider endpoints. However, it is not clear how the wsdl2java-generated
> classes running in smx-camel would use camel-cxf behind the scenes to send a
> jbi message to the smx-cxf-bc provider endpoint.
> <willem> rong; If you just want to routing the raw message and
> don't get the CXF interceptor get touch of the message, you could route the
> JBI message into the camel.
> <rong> willem: I am not sure I understand your comment. When I say
> smx-cxf-bc provider, I am using the term "provider" in jbi speak, meaning it
> is a proxy to an external service. So, I am not trying to route a message
> into camel, I am trying to route a message out of camel to the "jbi
> provider". Does that make sense?
> <willem> rong: but for camel-cxf , it doesn't take the transport
> and soap stack business apart. if you still want to the smx-cxf-se's marshal
> and unmarshal work do inside the camel, you still need to route the message
> to smx-cxf-se and camel-cxf can't do it.
> <rong> willem: doesn't cxf's native support for the jbi transport mean
> that the wsdl2java-generated stubs running in smx-camel do the jbi work for
> me. I was thinking I was only using camel-cxf to essentially import the
> relevant cxf jars. When the smx-cxf-se proxies to the smx-cxf-bc provider, is
> it doing more for me than I realize?
> <willem> rong: wsdl2java generated artifacts are for the mapping
> between the xml message and Java objects, they can't handle the jbi transport
> themselves. It need the CXF runtime to handle it.
> <willem> rong : I don't know what the smx-cxf-se proxies does,
> maybe I need to ask ffang to join this discussion.
> <rong> willem: i was thinking the same thing...
> <rong> ffang: ping
> <ffang> rong:pong
> <rong> ffang: i have been chatting with willem about moving some
> integration logic from a smx-cxf-se component to smx-camel. Do you have a
> moment to read our discussion history here and provide additional insight
> regarding how proxies to smx-cxf-bc providers work in smx-cxf-se?
> <ffang> rong: sure, basically, proxy in cxf se means, cxf se can hold
> the proxy of provider endpoint inside jbi bus, then from within the cxf se
> endpoint, can use this proxy to send message exchange to the provider
> endpoint just like a normal java invocation, but the provider endpoint must
> has the wsdl interface
> <rong> ffang: So, ii am trying to determine if the smx-cxf-se itself
> has magic to support proxying to smx-cxf-bc providers or if all the magic is
> the cxf runtime's support for jbi destinations...
> <ffang> rong: so you can from smx-cxf-se, use proxy of other cxf se
> endpoint/ cxf bc provider/ jsr181 se endpoint, because all of these provider
> endpoint has wsdl as interface
> <willem> ffang: does smx-cxf-se still need to marshal and
> unmarshal of the incoming and outgoing JBI message ?
> <ffang> rong: in your scenario, if camel se(as a provider) has wsdl
> interface, then it should be ok
> <ffang> willem: yeah
> <willem> ffang: Does the wsdl interface means SEI ?
> <rong> ffang: so, in smx-camel, if i bundle the camel-cxf component to
> incorporate the cxf runtime and I use wsdl2java-generated stubs with a jbi
> locationUri pointing to the smx-cxf-bc provider (just like I do in smx-cxf-se
> today), the code should port from smx-cxf-se to smx-camel?
> <ffang> rong: yeah, cxf se proxy use cxf JBI destination underlying,
> but it doesn't care the provider endpoint on the other side is cxf bc
> provider or not, any provider has wsdl interface should be ok
> <ffang> willem: yeah
> <rong> ffang: but in this case, i wouldn't be using the cxf-se proxy.
> i am running in smx-camel and trying to send a jbi request to smx-cxf-bc
> provider using wsdl2java-generated classes.
> <rong> ffang: is all the work i need being done in the cxf jbi
> transport layer and not in the cxf-se?
> <rong> ffang: the jbi proxy work, i mean
> <ffang> rong: yeah, basically it's cxf runtime issue, I mean here
> mainly involve ClientProxyFactoryBean(which is cxf client proxy) an cxf JBI
> transport
> <ffang> willem: can we use ClientProxyFactoryBean from camel-cxf now?
> <rong> ffang: am I correct that the major drawback of using this
> technique, i.e., ClientProxyFactoryBean, is that only synchronous invocations
> are supported. OTOH, if I manually build the request rather than using
> wsdl2java-generated classes, then I can asynchronously send the request,
> correct?
> <willem> ffang: camel-cxf uses ClientProxyFactoryBean to create
> the proxy to send the request to out side of service.
> <willem> ffang: I think the issue is how to initial the JBI
> transport in normal CXF endpoint.
> <willem> ffang: current camel-cxf endpoint can't consume the JBI
> message directly.
> <ffang> rong: yeah
> <ffang> rong: actually no
> <rong> willem: when the cxf runtime sees a jbi location uri, doesn't
> it know to automatically perform this initialization? I would think camel-cxf
> endpoint would play any role here, except making sure it brings with it the
> jbi transport jars.
> <ffang> rong: even we use sendSync in proxy to send out MessageChangr,
> but for cxf client api level, we have asyn, so the asyn/sync of cxf client
> api decouple with the underlying transport
> <ffang> rong: think about cxf client can support async over http
> transport, which is sync indeed
> <rong> willem: s/would/would not
> <willem> rong: yes, if you take a look at the
> CxfSeProxyFactoryBean in cxf-se, cxf-se did some customization on the client
> side.
> <ffang> willem: it's easy do use JBI transport, just do like
> cf.setAddress("jbi://" + "anything");
> <rong> ffang: it looks like CxfSeProxyFactoryBean has a reasonable
> amount of goodness to make proxies work with MTOM attachments, etc. Any idea
> how much of this functionality would have to be integrated into cxf,
> camel-cxf, or smx-camel? Would it make sense to move this into the cxf jbi
> library as a helper class so that smx-cxf-se and camel can share it?
> <ffang> rong: yeah, maybe some interceptors should move to cxf code
> base, if these would be shared by camel-cxf also
> <rong> willem, ffang: so it sounds to me like camel-cxf does not
> currently fully support the cxf jbi transport. If you agree, I'll open a
> Camel JIRA for this functionality to be added to the camel-cxf component.
> <willem> rongļ¼ current camel JBI related work is done in
> servicemix-camel component, I don't know if it is right for camel-cxf do
> consume or produce any JBI related message.
> <willem> rong: if you want to camel-cxf handle the JBI message
> from smx-cxf-se and smx-cxf-bc, we need to do merge the JBI related work in
> to camel-cxf.
> <willem> rong: please feel free to fill that requirement.
> <rong> willem: yes, i want camel-cxf to send jbi request and receive
> jbi response from both smx-cxf-se & smx-cxf-bc. So, should that be a
> camel-cxf JIRA?
> <willem> rong: yes, camel-cxf can cover that.
> <rong> willem, ffang: thanks for your assistance. i'll open a
> camel-cxf JIRA then.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
