You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Nicky Sandhu <ni...@hotmail.com> on 2007/08/22 23:34:46 UTC
Consuming from a http endpoint
HttpComponent creates an embedded jetty server. This seems to be different
from the stated aim of the component which is to represent http endpoints
(not "host" them). Am I missing the point?
Consuming external http resources is not possible as the
createMethod(Exchange exchange) method in HttpProducer can never result in a
return of GetMethod(uri).
So going to back to the route I have to represent www.google.com as a
endpoint and then consume from it, it should send back the contents of the
get request to http://www.google.com. If I produce to it, it should be able
send a post request to the url with the contents of the message... OR is
that too restful and needs another component ?
from("http://www.google.com").to("direct:a")
or is there some other component to achieve the above?
--
View this message in context: http://www.nabble.com/Consuming-from-a-http-endpoint-tf4314211s22882.html#a12283406
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Consuming from a http endpoint
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I have separated out jetty into it's own component. Perhaps someone
will want to take a stab at implementing a polling http consumer??
On 8/24/07, James Strachan <ja...@gmail.com> wrote:
> On 8/23/07, Nicky Sandhu <ni...@hotmail.com> wrote:
> > James.Strachan wrote:
> > > I've just patched trunk to lazily create the Jetty server. Also you
> > > could try using just the HttpComponent rather than the
> > > HttpJettyComponent if you prefer (which never starts Jetty) to only
> > > support client side HTTP
> > >
> > How do I do that? Something like context.addComponent("http",new
> > HttpComponent()) ?
>
> Yep. If you're using spring, just create the bean called "http" in the
> spring context. If you're not using Spring, just do the same with a
> JNDI context (or your code above works too)
>
>
> > James.Strachan wrote:
> > >
> > > From reading the source again - it looks like a GetMethod is used,
> > > unless the body of the Message can be converted to a valid
> > > RequestEntity. Does this always generate POSTs for you?
> > >
> >
> > I read the source as well. It seems that there are multiple returns from
> > HttpProducer.createRequestEntity and none of them returns null...so
> > createMethod never returns a GetMethod(uri)? Maybe I shouldn't debug compute
> > mentally :confused:
>
> LOL. You're right; I'd misread the code when I was doing a mental
> debug :). I've just patched the code and added a HttpGetTest to ensure
> we do actually do a GET if there is no body present.
>
>
> > James.Strachan wrote:
> > >
> > > Another option is to provide some default HTTP operation on the
> > > endpoint as configuration; or as a header/property on the exchange
> > > maybe?
> > >
> > Not sure how you would accomplish this as http:// uri shares the same syntax
> > as URI. E.g. how would you know that
> > http://myurl/myaction?myparam1=x&http_comp_param1=y , the url runs from
> > http://myurl/myaction?myparam1=x and the second param is intended for the
> > http component.
> >
> >
> > This is I guess a limitation of specifying everything on the URI ...
>
> Yeah - thats a great point. For HTTP I guess the query parameters
> should remain on the underlying URI & be part of the HTTP URL.
>
>
> > James.Strachan wrote:
> > >
> > > Maybe we need to separate out the http-client component from the
> > > servlet/server side? Another option is to use another component to do
> > > the polling; something like...
> > >
> > > from("timer:foo?period=5000").to("http://www.google.com", "direct:a")
> > >
> >
> > This would work for me, but it still points to the fact that by starting a
> > server when creating an endpoint,
>
> Note that currently a server is only started if you consume from the
> http endpoint. Though really I'm thinking it'd be better if we
> separate out the jetty stuff from the http client stuff to avoid
> confusion.
> https://issues.apache.org/activemq/browse/CAMEL-120
>
>
> > Camel is doing more than integration (EIP
> > stuff) and starting to host services.
> > Is that the intention of Camel or is
> > the intention that Camel interfaces with endpoints (of certain component)
> > and produce/consume from it?
>
> Camel doesn't want to be an app server or full ESB; we've Spring, web
> apps, OSGi and ServiceMix for those kinds of things. So ideally camel
> would just interface with endpoints of a certain component.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Consuming from a http endpoint
Posted by James Strachan <ja...@gmail.com>.
On 8/24/07, James Strachan <ja...@gmail.com> wrote:
> On 8/23/07, Nicky Sandhu <ni...@hotmail.com> wrote:
> > James.Strachan wrote:
> > > Another option is to provide some default HTTP operation on the
> > > endpoint as configuration; or as a header/property on the exchange
> > > maybe?
> > >
> > Not sure how you would accomplish this as http:// uri shares the same syntax
> > as URI. E.g. how would you know that
> > http://myurl/myaction?myparam1=x&http_comp_param1=y , the url runs from
> > http://myurl/myaction?myparam1=x and the second param is intended for the
> > http component.
> >
> >
> > This is I guess a limitation of specifying everything on the URI ...
>
> Yeah - thats a great point. For HTTP I guess the query parameters
> should remain on the underlying URI & be part of the HTTP URL.
FWIW you could do something like...
from("timer:foo?period=5000").
setHeader("org.apache.camel.http.method", "GET").
to("http://www.google.com", "direct:a");
i.e. customize the message exchange in the DSL
--
James
-------
http://macstrac.blogspot.com/
Re: Consuming from a http endpoint
Posted by James Strachan <ja...@gmail.com>.
On 8/23/07, Nicky Sandhu <ni...@hotmail.com> wrote:
> James.Strachan wrote:
> > I've just patched trunk to lazily create the Jetty server. Also you
> > could try using just the HttpComponent rather than the
> > HttpJettyComponent if you prefer (which never starts Jetty) to only
> > support client side HTTP
> >
> How do I do that? Something like context.addComponent("http",new
> HttpComponent()) ?
Yep. If you're using spring, just create the bean called "http" in the
spring context. If you're not using Spring, just do the same with a
JNDI context (or your code above works too)
> James.Strachan wrote:
> >
> > From reading the source again - it looks like a GetMethod is used,
> > unless the body of the Message can be converted to a valid
> > RequestEntity. Does this always generate POSTs for you?
> >
>
> I read the source as well. It seems that there are multiple returns from
> HttpProducer.createRequestEntity and none of them returns null...so
> createMethod never returns a GetMethod(uri)? Maybe I shouldn't debug compute
> mentally :confused:
LOL. You're right; I'd misread the code when I was doing a mental
debug :). I've just patched the code and added a HttpGetTest to ensure
we do actually do a GET if there is no body present.
> James.Strachan wrote:
> >
> > Another option is to provide some default HTTP operation on the
> > endpoint as configuration; or as a header/property on the exchange
> > maybe?
> >
> Not sure how you would accomplish this as http:// uri shares the same syntax
> as URI. E.g. how would you know that
> http://myurl/myaction?myparam1=x&http_comp_param1=y , the url runs from
> http://myurl/myaction?myparam1=x and the second param is intended for the
> http component.
>
>
> This is I guess a limitation of specifying everything on the URI ...
Yeah - thats a great point. For HTTP I guess the query parameters
should remain on the underlying URI & be part of the HTTP URL.
> James.Strachan wrote:
> >
> > Maybe we need to separate out the http-client component from the
> > servlet/server side? Another option is to use another component to do
> > the polling; something like...
> >
> > from("timer:foo?period=5000").to("http://www.google.com", "direct:a")
> >
>
> This would work for me, but it still points to the fact that by starting a
> server when creating an endpoint,
Note that currently a server is only started if you consume from the
http endpoint. Though really I'm thinking it'd be better if we
separate out the jetty stuff from the http client stuff to avoid
confusion.
https://issues.apache.org/activemq/browse/CAMEL-120
> Camel is doing more than integration (EIP
> stuff) and starting to host services.
> Is that the intention of Camel or is
> the intention that Camel interfaces with endpoints (of certain component)
> and produce/consume from it?
Camel doesn't want to be an app server or full ESB; we've Spring, web
apps, OSGi and ServiceMix for those kinds of things. So ideally camel
would just interface with endpoints of a certain component.
--
James
-------
http://macstrac.blogspot.com/
Re: Consuming from a http endpoint
Posted by Nicky Sandhu <ni...@hotmail.com>.
James.Strachan wrote:
>
>
> I've just patched trunk to lazily create the Jetty server. Also you
> could try using just the HttpComponent rather than the
> HttpJettyComponent if you prefer (which never starts Jetty) to only
> support client side HTTP
>
How do I do that? Something like context.addComponent("http",new
HttpComponent()) ?
James.Strachan wrote:
>
> From reading the source again - it looks like a GetMethod is used,
> unless the body of the Message can be converted to a valid
> RequestEntity. Does this always generate POSTs for you?
>
I read the source as well. It seems that there are multiple returns from
HttpProducer.createRequestEntity and none of them returns null...so
createMethod never returns a GetMethod(uri)? Maybe I shouldn't debug compute
mentally :confused:
James.Strachan wrote:
>
> Another option is to provide some default HTTP operation on the
> endpoint as configuration; or as a header/property on the exchange
> maybe?
>
Not sure how you would accomplish this as http:// uri shares the same syntax
as URI. E.g. how would you know that
http://myurl/myaction?myparam1=x&http_comp_param1=y , the url runs from
http://myurl/myaction?myparam1=x and the second param is intended for the
http component.
This is I guess a limitation of specifying everything on the URI ...
James.Strachan wrote:
>
> Maybe we need to separate out the http-client component from the
> servlet/server side? Another option is to use another component to do
> the polling; something like...
>
> from("timer:foo?period=5000").to("http://www.google.com", "direct:a")
>
This would work for me, but it still points to the fact that by starting a
server when creating an endpoint, Camel is doing more than integration (EIP
stuff) and starting to host services. Is that the intention of Camel or is
the intention that Camel interfaces with endpoints (of certain component)
and produce/consume from it?
--
View this message in context: http://www.nabble.com/Consuming-from-a-http-endpoint-tf4314211s22882.html#a12300478
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Consuming from a http endpoint
Posted by James Strachan <ja...@gmail.com>.
On 8/22/07, Nicky Sandhu <ni...@hotmail.com> wrote:
> HttpComponent creates an embedded jetty server. This seems to be different
> from the stated aim of the component which is to represent http endpoints
> (not "host" them). Am I missing the point?
Thats an oversight really. We started the consumer side first; then
added the producer side. There's no real reason you should have to
start an embedded Jetty server if you are just using the client side
of HTTP.
I've just patched trunk to lazily create the Jetty server. Also you
could try using just the HttpComponent rather than the
HttpJettyComponent if you prefer (which never starts Jetty) to only
support client side HTTP
> Consuming external http resources is not possible as the
> createMethod(Exchange exchange) method in HttpProducer can never result in a
> return of GetMethod(uri).
>From reading the source again - it looks like a GetMethod is used,
unless the body of the Message can be converted to a valid
RequestEntity. Does this always generate POSTs for you?
Another option is to provide some default HTTP operation on the
endpoint as configuration; or as a header/property on the exchange
maybe?
> So going to back to the route I have to represent www.google.com as a
> endpoint and then consume from it, it should send back the contents of the
> get request to http://www.google.com. If I produce to it, it should be able
> send a post request to the url with the contents of the message... OR is
> that too restful and needs another component ?
>
> from("http://www.google.com").to("direct:a")
>
> or is there some other component to achieve the above?
There's some confusion here between Camel's producer/consumer model
and HTTP GET/POST.
In Camel terms making a POST/GET on a http URI is using the producer
side. So you could do this today using the CamelTemplate for example.
Normally...
from(foo).to(bar)
basically means create a consumer of foo; then when it receives a
message send it on to bar for processing.
In this case we want to poll "http://www.google.com" and send a
message to "direct:a"; so I guess this is another kind of HTTP
consumer; a polling http client.
Maybe we need to separate out the http-client component from the
servlet/server side? Another option is to use another component to do
the polling; something like...
from("timer:foo?period=5000").to("http://www.google.com", "direct:a")
--
James
-------
http://macstrac.blogspot.com/
Re: Consuming from a http endpoint
Posted by James Strachan <ja...@gmail.com>.
On 8/23/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Doh.. sorry I had not noticed that!
No worries :) My bad for not documenting it :)
--
James
-------
http://macstrac.blogspot.com/
Re: Consuming from a http endpoint
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Doh.. sorry I had not noticed that!
On 8/23/07, James Strachan <ja...@gmail.com> wrote:
> On 8/22/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > If you want to post or get data from an http endpoint you are sending
> > data to it... I makes sense you need a http component that can
> > produce to the endpoint. So you need a route that looks like:
> >
> > from("direct:a").to("http://www.google.com");
> >
> > But right now our HTTP component does not implement the producer part.
> > If someone wants to take a stab at implementing it please let me know.
> > I might be able to guide you down the right path.
>
> FWIW there is a HttpProducer which uses commons httpclient. The
> HttpRouteTest test case sends to a http endpoint (using
> commons-httpclient) then consumes from the endpoint using the embedded
> jetty server
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Consuming from a http endpoint
Posted by James Strachan <ja...@gmail.com>.
On 8/22/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> If you want to post or get data from an http endpoint you are sending
> data to it... I makes sense you need a http component that can
> produce to the endpoint. So you need a route that looks like:
>
> from("direct:a").to("http://www.google.com");
>
> But right now our HTTP component does not implement the producer part.
> If someone wants to take a stab at implementing it please let me know.
> I might be able to guide you down the right path.
FWIW there is a HttpProducer which uses commons httpclient. The
HttpRouteTest test case sends to a http endpoint (using
commons-httpclient) then consumes from the endpoint using the embedded
jetty server
--
James
-------
http://macstrac.blogspot.com/
Re: Consuming from a http endpoint
Posted by Hiram Chirino <hi...@hiramchirino.com>.
If you want to post or get data from an http endpoint you are sending
data to it... I makes sense you need a http component that can
produce to the endpoint. So you need a route that looks like:
from("direct:a").to("http://www.google.com");
But right now our HTTP component does not implement the producer part.
If someone wants to take a stab at implementing it please let me know.
I might be able to guide you down the right path.
Regards,
Hiram
On 8/22/07, Nicky Sandhu <ni...@hotmail.com> wrote:
>
> HttpComponent creates an embedded jetty server. This seems to be different
> from the stated aim of the component which is to represent http endpoints
> (not "host" them). Am I missing the point?
>
> Consuming external http resources is not possible as the
> createMethod(Exchange exchange) method in HttpProducer can never result in a
> return of GetMethod(uri).
>
> So going to back to the route I have to represent www.google.com as a
> endpoint and then consume from it, it should send back the contents of the
> get request to http://www.google.com. If I produce to it, it should be able
> send a post request to the url with the contents of the message... OR is
> that too restful and needs another component ?
>
> from("http://www.google.com").to("direct:a")
>
> or is there some other component to achieve the above?
>
> --
> View this message in context: http://www.nabble.com/Consuming-from-a-http-endpoint-tf4314211s22882.html#a12283406
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com