On 8/8/07, Willem Jiang <[EMAIL PROTECTED]> wrote: > Hi James, > > I agree, let's implement a simple demo first. > I am just trying to create CxfConumser(holds a reference of CXF server) > and CxfProducer (holds a reference of CXF client) with the CXF simple > front endpoint , it is much close now .
Awesome! :). Am looking forward to it! > Now I have a question about the spring configuration file. Can we put > the Spring context into the endpoint ? So I can easily get the server > and client from the spring context. We've done this kinda thing before, sure. Generally how we've done it up to now is that we've added the ApplicationContext into the component class, which is the factory of the endpoints; endpoints typically have a reference to the component which created it, so the endpoint can ask the component for it; or the lookup could be done by the component at endpoint creation time. So just implement ApplicationContextAware on the component and it should just work I think. As an aside; we've an abstraction called Registry which is accessible on the CamelContext which allows you to lookup a bean by name, or by name and type. http://activemq.apache.org/camel/maven/camel-core/apidocs/org/apache/camel/spi/Registry.html We've a JNDI and Spring ApplicationContext based implementation. (We could add an OSGi / OSGi-DS / iPOJO / Guice implementation too etc). By default if you are using camel-spring and the SpringCamelContext (which is used when using the spring XML) then the Registry will use the current ApplicationContext. So maybe you could just perform your lookups in the Registry instead; then your code would work when folks are not using Spring etc? > Here is my other question: > When the CXFProducer get the response message, how can this response > message can be process by Camel ? You could set the response message on the Exchange.getOut() maybe? Then the code invoking the producer can extract the output etc? > I just saw the CxfBinding storeCxfResponse. I guess there need a process > somewhere. > > BTW, I saw a note in the CxfBinding.createCxfMessage(CxfExchange > exchange), there a note 'Is InputStream the best type to give to CXF?' > in the code. > > Here is my answer for that. > CXF uses the stax which is based on the stream API to parser the XML, so > the CXF transport is also based on the stream API. > And the interceptors are also based on the stream API, so we still need > to use the InputStream to hold the CXF on wire message. OK thanks for the clarification! I guess further down the line - when we look at alternative places to integrate with CXF at different points in the processing/interceptor chain (POJO v Payload v Message etc) we could experiment with some alternatives maybe. e.g. let CXF parse the message via StaX/streams into some kinda POJO - then put this in the message for Camel to process. Or vice versa, pass the POJOs to CXF and let it figure out how to marshall it onto the wire etc. Keep up the good work Willem! -- James ------- http://macstrac.blogspot.com/
