On 8/23/07, Nicky Sandhu <[EMAIL PROTECTED]> 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/
