camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Consuming from a http endpoint
Date Tue, 28 Aug 2007 19:29:11 GMT
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 <james.strachan@gmail.com> wrote:
> On 8/23/07, Nicky Sandhu <nickysandhu@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

Mime
View raw message