From: genman <do-...@jb...> - 2005-10-07 20:06:14
|
"ad...@jb..." wrote : | Yes, I'm hoping the inflow adapter will have a lot more pluggable components | the JMSContainerInvoker is pretty rigid in terms of changing implementation/policy. :-( | This is going away, at least for the default configuration for 4.0? I'd rather not have to try to deal with the JMSContainerInvoker "ad...@jb..." wrote : | The current inflow rar still uses ConnectionConsumer/ServerSessionPool | but I would prefer it to use JMS vendor specific plugins that will be capable of | a lot more optimizations and behaviours/features (including workarounds for known | "broken" vendors who only provide full behaviour through vendor specific api). | | If I only had time to work on it... :-) | I believe Tim Fox is going to work on some of this for the new JBoss Messaging? I thought JBoss Messaging was working on just the JMS implementation, not the EJB container and JCA 1.5 adaptor. And if I work on anything it'd be for the new .rar. I was thinking that the org.jboss.resource.adapter.jms.inflow.DLQHandler had a fairly decent interface. Perhaps I would do the following: | /** | * An interface for inflow message Handling. | */ | public interface InflowHandler | { | | /** | * Set up the handler. | * @throws Exception for any setup failure | */ | void setup(JmsActivation activation) throws Exception; | | /** | * Tear down the handler. | */ | void teardown(); | | /** | * Handles the message, return true if the message should not be further processed. | */ | boolean handle(Message msg); | | /** | * Notification that the message was delivered | */ | void messageDelivered(Message msg); | | } | I would probably make DLQHandler a subclass of InflowHandler and change the signatures slightly. The activation parameters would include a list of classes. What do you think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3899931#3899931 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3899931 |