anonymous wrote : It's my understanding that, e.g. in ServerConnectionDelegate.createSession, the object returned is a dynamic proxy that (internally) references an instance of JMSInvocation handler that's been constructed in that method. This instance holds a reference to the interceptor stack and a few other things, and is serialized back to the client. | In JB4 it's this class (called Container in JB4) that maintains the hierarchy.
That is correct. It's called JMSInvocationHandler because this is what it implements: java.lang.reflect.InvocationHandler. However, it is a container, since it "contains" the client-side interceptor stack. Since you mentioned this name several time, I am wondering whether we should rename it "JMSClientContainer". Anyway, it's a simple refactoring. If at least one more person starts refering to it as "container", I probably will :). anonymous wrote : Do I need to worry about server side close for MessageProducer and MessageConsumer? I.e is there any that needs to be done on close() for these objects in the server side delegates? ServerProducerDelegate itself does not need any clean-up on close() at this point. The Messaging Core destinations that receive messages from such endpoints do not care (do not have a reference to it). The only thing that is needed is to remove the producer delegate from the session's map. However, situation is different for Consumers. In a way, they are the equivalent of a ServerProducerDelegate, on the receiving side. They are not called ServerConsumerDelegate because they don't implement ConsumerDelegate, there is no need for that, all "ConsumerDelegate-ish" behavior is taking care of by interceptors: see ReceiverInterceptor on client-side and AsynchronousDeliveryInterceptor on the server-side. Here, there is need for clean-up: when a Consumer is closed, it must be de-registered from Messaging Core destination it is connected to. So far, I see ServerSessionDelegate doing this, in a method symmetrical to createConsumer(), that is called by a server-side CloseInterceptor. The current design is a little bit asymetrical and not exactly ellegant, but I would wait a little bit more to see if other needs arise, then maybe refactor. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872715#3872715 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3872715 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
