JMS Facade: delegates and containers

[ovidiu.feodorov]

Adrian,

I have made the first attempt to put together your the results of your work on delegates and containers with the core. The code is largely what you already committed into jboss.org.jms, with the observation that "jboss.org.jms" has become "jboss.org.messaging.jms".

There are two separate cases I am dealing with:

a) in-VM (or colocated), where the client-side connection delegate and the server-side connection delegate are directly linked. The client container's last interceptor in the chain forwards to the server container and they're in the same address space.

b) standard, where the client-side container and the server-side containers have remoting in between.

Currently I am concentrating on a) and I have several questions:

1) ConnectionDelegates: the interceptor stacks of the the client-side connection delegate and sever-side connection delegate contain identical standard interceptors (JMSExceptionInterceptor, LogInterceptor, ClosedInterceptor, etc). Is this your intention? In a colocated configuration, these interceptors are just duplicated, for example you'll get twice the logging you need.

2) org.jboss.messaging.jms.server.container.ServerConnectionInterceptor.invoke(): Do you really intend to return null when handling "createSession" or it is just an incomplete implementation? If this is your intention, who is supposed to call ServerContainerFactory.createSessionContainer()? The ServerFactoryInterceptor?

3) I assume that the ConnectionInterceptor and SessionInterceptor, which are supposed to do the heavy work, were just not implemented. Yet. I wasn't able to find them anywhere.

These questions are just to get the discussion started. I am working in parallel and I'll probably come with others, soon.



Thanks,
Ovidiu

[adrian.brock]

That implementation was incomplete. It was also based on an older version of
Bill's interceptors/proxy.

1) JMSException and log interceptors can be perVM in current aspect speak they
hold not state.
CloseInterceptor needs to be perInstance since it holds the flag as to whether
the object is closing/closed.

2) IIRC, I had most of the object construction (except for the inital implementation object
that was inside the ConnectionFactory bound into jndi) in the factory interceptor.

3) I only got as far as sending/receiving non-persistent messages.
I don't think I even committed the receiving messages processing?
I just wanted something to test the backend server and that the approach worked.

Although the approach worked, I wouldn't do it exactly the way I did it in the
prototype. There was a lot of hardwiring where I left some of the problems
(like external interceptor stack configuration) until later.