passing the HTTPServletRequest from Jetty to a SEDA consumer in Spring DSL
Hi,
I have a Jetty endpoint that when recieving a message will perform the
processing asynchronously and syncronously return a correlationId so the
client can come back later to another endpoint to see how processsing is
going.
I found an example on the mailing list of how to pass the HttpSession object
using Java, but I can't seem to find out how
to reference or pass the HttpRequest using SpringDSL. What I have at the
moment is:
http://0.0.0.0:8080/endpoint"/>
${id}
Is there a way to say 'pass the HTTP stuff through please Mr SEDA'?
Should I really be setting a header property to that of a HTTP Object? How
do I obtain it?
Should I architect this differently?
All the best,
Wayne
Re: passing the HTTPServletRequest from Jetty to a SEDA consumer in Spring DSL
Hi,
Apologies, I didn't word my previous email very well; what I should have
also mentioned for clarity is that if I do this:
http://0.0.0.0:8080/endpoint"/>
${id}
The same bean is able to obtain the HTTPServletRequest to get the POST data
(base64 encoded binary) andthe URL parameters, however, if I introduce the
SEDA
call the same bean can't get the HTTPServletRequest. The salient bean code
is:
public String controller(String body, Exchange exchange) {
try {
HttpServletRequest req =
exchange.getIn().getBody(HttpServletRequest.class);
Regards
Wayne
On Wed, Jan 20, 2010 at 9:02 AM, Wayne Keenan wrote:
> Hi,
>
> I have a Jetty endpoint that when recieving a message will perform the
> processing asynchronously and syncronously return a correlationId so the
> client can come back later to another endpoint to see how processsing is
> going.
>
> I found an example on the mailing list of how to pass the HttpSession
> object using Java, but I can't seem to find out how
> to reference or pass the HttpRequest using SpringDSL. What I have at the
> moment is:
>
>
>
> http://0.0.0.0:8080/endpoint"/>
>
>
> ${id}
>
>
>
>
>
>
>
>
> Is there a way to say 'pass the HTTP stuff through please Mr SEDA'?
> Should I really be setting a header property to that of a HTTP Object? How
> do I obtain it?
> Should I architect this differently?
>
> All the best,
> Wayne
>
Re: passing the HTTPServletRequest from Jetty to a SEDA consumer in Spring DSL
Hi,
Thanks for replying.
On Wed, Jan 20, 2010 at 3:28 PM, Willem Jiang wrote:
> Hi,
>
> Can you try to set the ID into the message header instead of the message
> body ? In this way you can the Request object back :)
>
>
> >>
> >> http://0.0.0.0:8080/endpoint"/>
> >>
> >>
> >> ${id}
> >>
>
> >>
> >>
> >>
> >>
> >>
> >>
>
> You bean's method could
> public String controller(@Header("id")String body, Exchange exchange) ;
>
>
>
The request body contains base64 encoded POST I want.
I can get to the body, url paramters and the ID ok without the intermediate
SEDA route, in the bean I have:
HttpServletRequest req =
exchange.getIn().getBody(HttpServletRequest.class);
def corrId = exchange.getIn().getMessageId()
I also can get to the URL (not form encoded) parameters (e.g. the URL is:
http://0.0.0.0:65503/endpoint?myParam=value) by using:
def p1 = req?.getParameter('myParam')
It's ony when I introduce the SEDA that the HttpServletRequest no longer
exists, (I think), and I am unable to obtain the HTTP parameters from the
URL
Perhaps I should be copying the HTTP parameters to Camel message
properties? That way my bean can be less dependent on the HTTP protocol.
Is that something someone would be able to give me an example of please? Is
there a built-in way to auto populate Camel message properties with HTTP
properties
Alternatively, sticking with HTTP aware bean,I just get null using:
println exchange.getProperty(Exchange.HTTP_QUERY)
or
println exchange.getIn().getProperty(Exchange.HTTP_QUERY)
Regards
Wayne
> Willem
>
>
> Wayne Keenan wrote:
>
>> Hi,
>>
>> Apologies, I didn't word my previous email very well; what I should have
>> also mentioned for clarity is that if I do this:
>>
>>
>>http://0.0.0.0:8080/endpoint"/>
>>
>>
>>${id}
>>
>>
>>
>> The same bean is able to obtain the HTTPServletRequest to get the POST
>> data
>> (base64 encoded binary) andthe URL parameters, however, if I introduce
>> the
>> SEDA
>> call the same bean can't get the HTTPServletRequest. The salient bean code
>> is:
>>
>> public String controller(String body, Exchange exchange) {
>>
>>try {
>> HttpServletRequest req =
>> exchange.getIn().getBody(HttpServletRequest.class);
>>
>>
>> Regards
>> Wayne
>>
>> On Wed, Jan 20, 2010 at 9:02 AM, Wayne Keenan > >wrote:
>>
>> Hi,
>>>
>>> I have a Jetty endpoint that when recieving a message will perform the
>>> processing asynchronously and syncronously return a correlationId so the
>>> client can come back later to another endpoint to see how processsing is
>>> going.
>>>
>>> I found an example on the mailing list of how to pass the HttpSession
>>> object using Java, but I can't seem to find out how
>>> to reference or pass the HttpRequest using SpringDSL. What I have at the
>>> moment is:
>>>
>>>
>>>
>>>http://0.0.0.0:8080/endpoint"/>
>>>
>>>
>>>${id}
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Is there a way to say 'pass the HTTP stuff through please Mr SEDA'?
>>> Should I really be setting a header property to that of a HTTP Object?
>>> How
>>> do I obtain it?
>>> Should I architect this differently?
>>>
>>> All the best,
>>> Wayne
>>>
>>>
>>
>
Re: HTTP parameter bug (was passing the HTTPServletRequest from Jetty to a SEDA consumer in Spring DSL)
Hi,
I believe I have found the trouble I am having. I think this bug still
exists in the 2.1.0 release:
http://issues.apache.org/activemq/browse/CAMEL-1806
The docs says from: http://camel.apache.org/jetty.html says:
*Camel also populates all request.parameter and request.headers. For
example, given a client request with the URL,
http://myserver/myserver?orderid=123, the exchange will contain a header
named orderid with the value 123. This feature was introduced in Camel 1.5.*
However, the header parameters are only set for GET, not PUT or POST.
Regards
Wayne
On Wed, Jan 20, 2010 at 4:16 PM, Wayne Keenan wrote:
> Hi,
>
> Thanks for replying.
>
> On Wed, Jan 20, 2010 at 3:28 PM, Willem Jiang wrote:
>
>> Hi,
>>
>> Can you try to set the ID into the message header instead of the message
>> body ? In this way you can the Request object back :)
>>
>>
>> >>
>> >> http://0.0.0.0:8080/endpoint"/>
>> >>
>> >>
>> >> ${id}
>> >>
>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>> You bean's method could
>> public String controller(@Header("id")String body, Exchange exchange) ;
>>
>>
>>
> The request body contains base64 encoded POST I want.
>
> I can get to the body, url paramters and the ID ok without the intermediate
> SEDA route, in the bean I have:
>
>
>
> HttpServletRequest req =
> exchange.getIn().getBody(HttpServletRequest.class);
>
> def corrId = exchange.getIn().getMessageId()
>
> I also can get to the URL (not form encoded) parameters (e.g. the URL is:
> http://0.0.0.0:65503/endpoint?myParam=value) by using:
>
> def p1 = req?.getParameter('myParam')
>
>
>
> It's ony when I introduce the SEDA that the HttpServletRequest no longer
> exists, (I think), and I am unable to obtain the HTTP parameters from the
> URL
>
> Perhaps I should be copying the HTTP parameters to Camel message
> properties? That way my bean can be less dependent on the HTTP protocol.
>
> Is that something someone would be able to give me an example of please?
> Is there a built-in way to auto populate Camel message properties with HTTP
> properties
>
> Alternatively, sticking with HTTP aware bean,I just get null using:
>
> println exchange.getProperty(Exchange.HTTP_QUERY)
> or
> println exchange.getIn().getProperty(Exchange.HTTP_QUERY)
>
>
>
> Regards
> Wayne
>
>
>
>> Willem
>>
>>
>> Wayne Keenan wrote:
>>
>>> Hi,
>>>
>>> Apologies, I didn't word my previous email very well; what I should have
>>> also mentioned for clarity is that if I do this:
>>>
>>>
>>>http://0.0.0.0:8080/endpoint"/>
>>>
>>>
>>>${id}
>>>
>>>
>>>
>>> The same bean is able to obtain the HTTPServletRequest to get the POST
>>> data
>>> (base64 encoded binary) andthe URL parameters, however, if I introduce
>>> the
>>> SEDA
>>> call the same bean can't get the HTTPServletRequest. The salient bean
>>> code
>>> is:
>>>
>>> public String controller(String body, Exchange exchange) {
>>>
>>>try {
>>> HttpServletRequest req =
>>> exchange.getIn().getBody(HttpServletRequest.class);
>>>
>>>
>>> Regards
>>> Wayne
>>>
>>> On Wed, Jan 20, 2010 at 9:02 AM, Wayne Keenan >> >wrote:
>>>
>>> Hi,
>>>>
>>>> I have a Jetty endpoint that when recieving a message will perform the
>>>> processing asynchronously and syncronously return a correlationId so the
>>>> client can come back later to another endpoint to see how processsing is
>>>> going.
>>>>
>>>> I found an example on the mailing list of how to pass the HttpSession
>>>> object using Java, but I can't seem to find out how
>>>> to reference or pass the HttpRequest using SpringDSL. What I have at
>>>> the
>>>> moment is:
>>>>
>>>>
>>>>
>>>>http://0.0.0.0:8080/endpoint"/>
>>>>
>>>>
>>>>${id}
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Is there a way to say 'pass the HTTP stuff through please Mr SEDA'?
>>>> Should I really be setting a header property to that of a HTTP Object?
>>>> How
>>>> do I obtain it?
>>>> Should I architect this differently?
>>>>
>>>> All the best,
>>>> Wayne
>>>>
>>>>
>>>
>>
>
Re: HTTP parameter bug (was passing the HTTPServletRequest from Jetty to a SEDA consumer in Spring DSL)
Hi,
Nope, I am POSTing binary data as the body with a content-type of '
application/octet-stream', and am sending additional parameters in the URI
Query that are not appearing as Camel headers.
Perhaps this is not 'best practice', and the body should be multipart MIME
encoded so it can be POST'ed as application/x-www-form-urlencoded, but AFAIK
what I'm currently doing isn't outlawed by HTTP.
Regards
Wayne
On Thu, Jan 21, 2010 at 12:55 AM, Willem Jiang wrote:
> Hi,
>
> Is your post request using "application/x-www-form-urlencoded" as the
> content-type ?
> If so , you should get the parameters from the message header.
>
>
> Willem
>
> Wayne Keenan wrote:
>
>> Hi,
>>
>> I believe I have found the trouble I am having. I think this bug still
>> exists in the 2.1.0 release:
>> http://issues.apache.org/activemq/browse/CAMEL-1806
>>
>> The docs says from: http://camel.apache.org/jetty.html says:
>>
>> *Camel also populates all request.parameter and request.headers. For
>> example, given a client request with the URL,
>> http://myserver/myserver?orderid=123, the exchange will contain a header
>> named orderid with the value 123. This feature was introduced in Camel
>> 1.5.*
>>
>> However, the header parameters are only set for GET, not PUT or POST.
>>
>> Regards
>> Wayne
>>
>>
>> On Wed, Jan 20, 2010 at 4:16 PM, Wayne Keenan > >wrote:
>>
>> Hi,
>>>
>>> Thanks for replying.
>>>
>>> On Wed, Jan 20, 2010 at 3:28 PM, Willem Jiang >> >wrote:
>>>
>>> Hi,
>>>>
>>>> Can you try to set the ID into the message header instead of the message
>>>> body ? In this way you can the Request object back :)
>>>>
>>>>
>>>>
>>>>>>http://0.0.0.0:8080/endpoint"/>
>>>>>>
>>>>>>
>>>>>> ${id}
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> You bean's method could
>>>> public String controller(@Header("id")String body, Exchange exchange) ;
>>>>
>>>>
>>>>
>>>> The request body contains base64 encoded POST I want.
>>>
>>> I can get to the body, url paramters and the ID ok without the
>>> intermediate
>>> SEDA route, in the bean I have:
>>>
>>>
>>>
>>> HttpServletRequest req =
>>> exchange.getIn().getBody(HttpServletRequest.class);
>>>
>>> def corrId = exchange.getIn().getMessageId()
>>>
>>> I also can get to the URL (not form encoded) parameters (e.g. the URL
>>> is:
>>> http://0.0.0.0:65503/endpoint?myParam=value) by using:
>>>
>>> def p1 = req?.getParameter('myParam')
>>>
>>>
>>>
>>> It's ony when I introduce the SEDA that the HttpServletRequest no longer
>>> exists, (I think), and I am unable to obtain the HTTP parameters from
>>> the
>>> URL
>>>
>>> Perhaps I should be copying the HTTP parameters to Camel message
>>> properties? That way my bean can be less dependent on the HTTP protocol.
>>>
>>> Is that something someone would be able to give me an example of please?
>>> Is there a built-in way to auto populate Camel message properties with
>>> HTTP
>>> properties
>>>
>>> Alternatively, sticking with HTTP aware bean,I just get null using:
>>>
>>> println exchange.getProperty(Exchange.HTTP_QUERY)
>>> or
>>> println exchange.getIn().getProperty(Exchange.HTTP_QUERY)
>>>
>>>
>>>
>>> Regards
>>> Wayne
>>>
>>>
>>>
>>> Willem
>>>>
>>>>
>>>> Wayne Keenan wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> Apologies, I didn't word my previous email very well; what I should
>>>>> have
>>>>> also mentioned for clarity is that if I do this:
>>>>>
>>>>>
>>>>> http://0.0.0.0:8080/endpoint"/>
>>>>>
>>>>>
>>>&
Re: HTTP parameter bug (was passing the HTTPServletRequest from Jetty to a SEDA consumer in Spring DSL)
Hi Willem, Thanks very much, I can confirm that with 2.2-SNAPSHOT I can obtain the URI QUERY parameters from the camel header(s) when POSTing content-type of application/octet-stream. I did notice that a HTTP PUT doesn't populate the headers with the URI Query parameter Regards Wayne On Fri, Jan 22, 2010 at 1:07 PM, Willem Jiang wrote: > Hi Wayne, > > I commit a patch of CAMEL-2386, please check out the last > camel-2.2-SNAPSHOT to verify it :) > > Willem > > > Willem Jiang wrote: > >> I just did a quick test on camel trunk, you can get the URL parameters by >> using the >> exchange.getIn().getHeader(Exchange.HTTP_QUERY) >> When you post the binary data with URI Query. >> >> I just took a look at camel-http and found we could parser the URL >> parameter for the post method. >> >> So I created a JIRA[1] and will submit a quick fix for it. >> >> [1] https://issues.apache.org/activemq/browse/CAMEL-2386 >> >> Willem >> >>
Re: Grails/Camel - pass queue message to HTTP POST?
On Tue, Jan 26, 2010 at 5:25 AM, kitplummer wrote:
>
> Ok, just thinking at this point...and I don't yet understand Camel well
> enough. So, I need some insight.
>
> What I want to do is use Camel to facilitate some back-end business logic
> in
> my Grails app. Here's the general idea. From my Grails app I send a block
> of text to a Route. I want this route to be configured to take in a block
> of raw text (seda:my.queue) and send my.queue as the body of an HTTP POST
> to
> an external service - and consume the returned body, sending it back to a
> Grails service. I have the last part figured, but missing the Camel guts.
>
> Here's where I'm starting:
>
> class JobRoute {
>def configure = {
>println "Setting JobRoute Camel Router..."
>from("seda:my.queue") {
>Exchange exchange =
> template.send("http://localhost:4567/jodmock";,
>new Processor() {
>process(exchange) {
>exchange.getIn().setHeader(Exchange.HTTP_METHOD,
> constant(org.apache.camel.component.http.HttpMethods.POST));
>}
>}
>);
>Message out = exchange.getOut();
>int responseCode =
> out.getHeader(HttpProducer.HTTP_RESPONSE_CODE, Integer.class);
>}
>}
> }
>
> The "new Processor() instantiation barfs during compile with:
>
> [groovyc] /Users/kplummer/Development/ts/grails-app/routes/JobRoute.groovy:
> 9: You cannot create an instance from the abstract interface
> 'org.apache.camel.Processor'.
> [groovyc] @ line 9, column 17.
> [groovyc]new Processor() {
> [groovyc]
>
>
try this:
class JobRoute extends RouteBuilder {
void configure {
println "Setting JobRoute Camel Router..."
from("seda:my.queue") {
Exchange exchange = template.send("http://localhost:4567/jodmock
",
[
process: { exchange ->
exchange.getIn().setHeader(Exchange.HTTP_METHOD,
constant(org.apache.camel.component.http.HttpMethods.POST));
}
] as Processor
);
Message out = exchange.getOut();
int responseCode =
out.getHeader(HttpProducer.HTTP_RESPONSE_CODE, Integer.class);
}
}
}
> And, I haven't figured out to get the my.queue to the contents of the In.
>
> Help!
>
> Thanks.
> Kit
> --
> View this message in context:
> http://old.nabble.com/Grails-Camel---pass-queue-message-to-HTTP-POST--tp27318113p27318113.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: HTTP parameter bug (was passing the HTTPServletRequest from Jetty to a SEDA consumer in Spring DSL)
On Mon, Jan 25, 2010 at 4:25 AM, Willem Jiang wrote: > Hi Wayne, > > I'm not sure we need to populate the headers for the HTTP PUT method. > Can you point me out if there any specification for it ? > > Willem > > > I looked at the RFC's for http 1.0 and 1.1, to me it doesn't appear to preclude using a 'query' in the URI for a PUT, or any other HTTP request type. http://www.ietf.org/rfc/rfc1945.txt http://www.w3.org/Protocols/rfc2616/rfc2616.html
Re: Questions about camel-jetty
On Tue, Feb 9, 2010 at 2:03 AM, Pete Mueller wrote: > > Hello all, > > I am currently working with the camel-jetty integration for hosting some > web > services. During my implementation, I've found a few "oddities" that I > thought I would post here before opening actual bug reports. (NOTE: I am > using Camel 2.0) > > 1. When an exchange is create from a Jetty endpoint, the BodyType (as > reported via TraceInterceptor) is org.mortbay.jetty.HttpParser.Input. > Processing this data allows me to call getBody(String.class) to get the > POST > contents or getBody(HttpServletRequest.class) to get the request object. > However, this is only available to the first processor after the "from" > element. Subsequent processor calls to getBody(HttpServletRequest.class) > return null, which seem to be caused because the BodyType was translated > to > a InputStreamCache somewhere. I've tried various methods of passing the > message in to the message out, but I cannot avoid this conversion and loss > of request object. Is this intended behavior? If so, how do I get the > request object back? > I think you are describing the same problem I found; a fix went into 2.2-snapshot: https://issues.apache.org/activemq/browse/CAMEL-2386 Regards Wayne > Thanks for all your help. > -pete > -- > View this message in context: > http://old.nabble.com/Questions-about-camel-jetty-tp27509400p27509400.html > Sent from the Camel - Users mailing list archive at Nabble.com. > >
issue with HTTP response content length being set to CXF request length - causing truncated responses.
Hi, I have run into an issue where the HTTP response message is being truncated to the exactly length of the incoming CXF request, i.e. response.contentLength seems to be being set to the request.contentLength, I have the following setup: 1. I am advertising a WSDL file via a CXF endpoint. 2. The route is from CXF to a back end WS via the HTTP component. 3. The backend service is a Tuscany SCA component, invoked via SOAP over HTTP. The Camel/CXF interceptor logging shows the entire message payload. Also, calling the backend service (3) directly using SOAPui functions correctly If I start adding characters to the request just to make it longer, e.g. just after , but it doesn't matter where, then for each character I add I see an additional character of the response that otherwise gets truncated. Versions: Camel 2.1.0 CXF 2.2.6 (tried 2.2.4 also ) Tuscany 1.6 (tried 1.5.1 also ) Java 1.6 MacOSX 10.6 The config is (lightly edited): http://localhost:8080/services/Service"; wsdlURL="file:service.wsdl" serviceName="a:Service" endpointName="a:ServicePort" xmlns:a="http://a.com";> http://camel.apache.org/schema/spring "> http://localhost:8086/services/Service"/> I have also tried specifying the 'bridgeEndpoint=true' option to the HTTP component URI thinking that may help, but the problem is still the same. Should I explicitly be fixing up the content length? if so how do I do that? All the best Wayne
Re: issue with HTTP response content length being set to CXF request length - causing truncated responses.
Deleting the content length header as the last action is a workaround. Should I raise thus as an issue? Regards Wayne On 1 Mar 2010, at 19:22, Wayne Keenan wrote: Hi, I have run into an issue where the HTTP response message is being truncated to the exactly length of the incoming CXF request, i.e. response.contentLength seems to be being set to the request.contentLength, I have the following setup: I am advertising a WSDL file via a CXF endpoint. The route is from CXF to a back end WS via the HTTP component. The backend service is a Tuscany SCA component, invoked via SOAP over HTTP. The Camel/CXF interceptor logging shows the entire message payload. Also, calling the backend service (3) directly using SOAPui functions correctly If I start adding characters to the request just to make it longer, e.g. just after , but it doesn't matter where, then for each character I add I see an additional character of the response that otherwise gets truncated. Versions: Camel 2.1.0 CXF 2.2.6 (tried 2.2.4 also ) Tuscany 1.6 (tried 1.5.1 also ) Java 1.6 MacOSX 10.6 The config is (lightly edited): http://localhost:8080/services/Service"; wsdlURL="file:service.wsdl" serviceName="a:Service" endpointName="a:ServicePort" xmlns:a="http://a.com";> http://camel.apache.org/schema/spring "> http://localhost:8086/services/Service"/> I have also tried specifying the 'bridgeEndpoint=true' option to the HTTP component URI thinking that may help, but the problem is still the same. Should I explicitly be fixing up the content length? if so how do I do that? All the best Wayne
Re: issue with HTTP response content length being set to CXF request length - causing truncated responses.
On Tue, Mar 2, 2010 at 3:35 AM, Willem Jiang wrote: > Hi > Can you check out the latest released Camel 2.2.0 ? > working on camel 2.2.0, CXF 2.2.6 on Mac10.6 Thanks, Wayne
Virtual/Proxy WebService component (request?) R
Hi, I have backend SCA components that is implemented in Java and the WSDL is automatically generated by the Apache Tuscany SCA container. I would like to be able to front access to my backend services using Camel. For this to function I would like to know it its possible to configure a (the CXF?) component to advertise the SCA generated WSDL (modifying the endpoint ports so not to expose the backed endpoint directly) and route thru Camel to the backend service. Thus, I could redirect/loadbalance or what ever without effecgting the client, Basically I want todo what Apache Synapse can do, but in Camel: http://wso2.org/library/189 It would be good if the component could do WSDL loading lazyly to account for situations whereby the SCA service has not started when the Camel route is started. (Like I have now :) ) All the best, Wayne
Re: Virtual/Proxy WebService component (request?) R
Hi, I tried the jetty/http combo but dont like the fact the WSDL service URL to the SCA component 'leaked' straight thru verbatim. The real client will be a b2b gateway that wont consume the WSDL directly, so not a problem. But for dev/testing I would like SOAPui to use the Camel fronted endpoint and not be given the backend endpoint serivce URL. The Synapse proxy rewrites the service endpoint. Regards Wayne On Fri, Mar 12, 2010 at 1:01 PM, Willem Jiang wrote: > Hi, > > Does you client need to use the service WSDL to generate the question > message? > If so, I'm afraid you still need to let camel-cxf know about the WSDL or > generate the artifact with WSDL. > Otherwise, you can leverage the camel-jetty and camel-http component to > route the request to backend system. > > Willem > > > > Wayne Keenan wrote: > >> Hi, >> >> >> I have backend SCA components that is implemented in Java and the WSDL is >> automatically generated by the Apache Tuscany SCA container. >> >> I would like to be able to front access to my backend services using >> Camel. >> >> For this to function I would like to know it its possible to configure a >> (the CXF?) component to advertise the SCA generated WSDL (modifying the >> endpoint ports so not to expose the backed endpoint directly) and route >> thru >> Camel to the backend service. Thus, I could redirect/loadbalance or what >> ever without effecgting the client, >> >> Basically I want todo what Apache Synapse can do, but in Camel: >> http://wso2.org/library/189 >> >> It would be good if the component could do WSDL loading lazyly to account >> for situations whereby the SCA service has not started when the Camel >> route >> is started. (Like I have now :) ) >> >> >> >> All the best, >> Wayne >> >> >
Re: Virtual/Proxy WebService component (request?) R
Hi, sorry that sounded like they have it why don't you... if I wanted to 'borrow' the code from Synapse, please could you suggest a Camel component that might be a good point to start from. CXF may on the surfaace be obvious, but without looking at it and knowing Synapse uses Axis2 I already feel like I'm up against it... Regards Wayne On Fri, Mar 12, 2010 at 2:16 PM, Wayne Keenan wrote: > Hi, > > I tried the jetty/http combo but dont like the fact the WSDL service URL to > the SCA component 'leaked' straight thru verbatim. > > The real client will be a b2b gateway that wont consume the WSDL directly, > so not a problem. But for dev/testing I would like SOAPui to use the Camel > fronted endpoint and not be given the backend endpoint serivce URL. > > The Synapse proxy rewrites the service endpoint. > > Regards > Wayne > > > On Fri, Mar 12, 2010 at 1:01 PM, Willem Jiang wrote: > >> Hi, >> >> Does you client need to use the service WSDL to generate the question >> message? >> If so, I'm afraid you still need to let camel-cxf know about the WSDL or >> generate the artifact with WSDL. >> Otherwise, you can leverage the camel-jetty and camel-http component to >> route the request to backend system. >> >> Willem >> >> >> >> Wayne Keenan wrote: >> >>> Hi, >>> >>> >>> I have backend SCA components that is implemented in Java and the WSDL is >>> automatically generated by the Apache Tuscany SCA container. >>> >>> I would like to be able to front access to my backend services using >>> Camel. >>> >>> For this to function I would like to know it its possible to configure a >>> (the CXF?) component to advertise the SCA generated WSDL (modifying the >>> endpoint ports so not to expose the backed endpoint directly) and route >>> thru >>> Camel to the backend service. Thus, I could redirect/loadbalance or what >>> ever without effecgting the client, >>> >>> Basically I want todo what Apache Synapse can do, but in Camel: >>> http://wso2.org/library/189 >>> >>> It would be good if the component could do WSDL loading lazyly to account >>> for situations whereby the SCA service has not started when the Camel >>> route >>> is started. (Like I have now :) ) >>> >>> >>> >>> All the best, >>> Wayne >>> >>> >> >
Re: Importing routes into camel (spring) context
Hi, You might want to look at springs classpath*: mechanism. I am using it to pull in in all the spring xml files that match a particular pattern fo my app; some spring files may have their own camelContext, so although you dont have a single camelContext you do get discrete config files. This may or may not fit your situation, e.g.: Regards Wayne On Tue, Mar 23, 2010 at 8:02 AM, Kevin Jackson wrote: > Hi, > > I don't think it's currently possible to have a single camelContext > and use the tag to pull in routing information into that > context. > > The usecase is that we have a single application with many routes, > each route is specific to an entity and I would prefer to keep the > entity specific information in a separate context file and import it > into the main camelContext. This would allow soft-deployment of code > and then activation of a route via deploying an entity specific > context. > > Is this something that may be possible in the future? > > Thanks, > Kev >
