Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of chirino@gmail.com designates
 209.85.162.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=ZHUvkW92snMsqIeN6hb6Tkq/Z3OE5sOYdA37p8C9BvmpeTmnW83Nheirhd8spyIRzGgP3esoQI+RMbUUL3zQaM0SVxo5kFmWSVKeQx0aRURHr9up7Bk4vtAPLtO6ZbhLipWxAqWCm7yrWBZSjxKpyt+rCrN66fe6CuDYY3c4rjU=
Message-ID: <af2843cd0708281229w5ef8d11bk9ab0a072fe019413@mail.gmail.com>
Date: Tue, 28 Aug 2007 15:29:11 -0400
From: "Hiram Chirino" <hiram@hiramchirino.com>
Sender: chirino@gmail.com
To: camel-user@activemq.apache.org
Subject: Re: Consuming from a http endpoint
In-Reply-To: <ec6e67fd0708240143g6629c688y650be7e752a7252a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <12283406.post@talk.nabble.com>
	 <ec6e67fd0708230702h1f492edenfecf643e57a7d21d@mail.gmail.com>
	 <12300478.post@talk.nabble.com>
	 <ec6e67fd0708240143g6629c688y650be7e752a7252a@mail.gmail.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 <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