cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Transport API (setMessageObserver)
Date Thu, 28 Sep 2006 13:16:21 GMT

> The logic at work here is a transport-level endpoint (e.g. a HTTP
> listener) should never exist in isolation. In order to start 
> receiving messages, the transport must know *a priori* what 
> to do with these messages. That's why we don't have discrete 
> APIs for Destination activation and MessageObserver 
> registration, i.e. the one is pretty much useless without the other.

Of course if the particular transport allows the listener infrastructure
to be set up in advance without actually receiving any messages, then of
course this could be optionally done by the DestinationFactory or in the
Destination ctor, in advance of the first call to setMessageObserver().

For example, the JMS transport could set up the JMS connection, session,
message receiver etc. all in advance, and just defer the first
MessageReceiver.receive() call until a MessageObserver is registered. As
it happens, the CXF JMS transport isn't implemented this way.

Similarly we could have implemented HTTP to create the Jetty HttpServer
up-front, but not actually called setListener() and start() until a
MessageObserver is registered.

/Eoghan

Mime
View raw message