On Nov 16, 2007 8:11 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > The work on the 4.x http components is not stalled afaik. > The code they mentionned is in a branch, but the trunk has full support for > async http requests. > They have released a new alpha version quite recently and it has just been > promoted as a TLP this week. > > Quoting http://www.apachenews.org/archives/001068.html > HttpCore NIO extensions can be used to build > asynchronous HTTP services based on non-blocking I/O model capable of > handling a great number of simultaneous connections with just a few I/O > threads. > > I really don't know what the web page you found refers too, but I suppose it > is outdated or refers to a dead branch without any relationship with the > current trunk. > > I've used HttpCore to implement a component in camel and it works well. The > only thing is that the api are not locked yet, which means it may require > work when we upgrade to the next version. > > An option to consider would be to use camel to implement the > HttpProviderEndpoint.
That's exactly what I'm thinking as I read your whole reply. > > ACTION 2: Refactor the HttpProviderEndpoint to use JHC > > > > ServiceMix 4.x: > > In ServiceMix 4.x, the overall plan involves refactoring the entire > > container from the ground up. Much work has already taken place toward > > this effort, mostly by Guillaume Nodet (see > > > > https://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0 > > ). > > So far the idea for HTTP support in SMX 4 is to use the Apache Camel > > HTTP component (this still needs to be discussed further in order to > > figure out how the Apache CXF SE will work with both HTTP and JMS > > endpoints, but this is a separate topic for another discussion). > > > The idea is to avoid code duplication between camel / servicemix and provide > a single way to configure transports (thereby removing the need for this > thread in smx 4.x). > In my opinion, we will have the JBI 1.0 compatibility layer in smx 4, so > that we have backward compatibility with smx 3.x (to the extent of the JBI > specification). > For new applications, we should focus on using camel transports (this > includes the camel-jhc component i talked about), and for soap support > provided by cxf, we should use > the soap: protocol provided by camel-cxf which can be backed by any other > camel transport. > So currently, if you write > from("soap:jhc:http://localhost:8080/myservice";).to(...) > in camel, it will create an http server side socket using HttpCore, and add > soap processing using CXF. > That way, we should not have to deal with CXF transport at all and only use > the camel HTTP transport provided by HttpCore (hopefully we can switch it to > be the default transport for http in camel at some point, so that the need > for the jhc: prefix will disapear). > > This is my view on how to solve the transport problem in Smx 4, but there I > still don't see how we can get rid of all the other http transport > duplication in smx 3 (especially the CXF one). Then why don't we just make use of the Camel HTTP transport now for SMX 3 for the HttpProviderEndpoint? Is there anything preventing us from doing this now? We still need to create a document on the wiki explaining the HTTP mess. Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
