Added https://issues.apache.org/activemq/browse/SM-1169 to track this issue.
Bruce Snyder wrote:
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
