2 Replies Latest reply on Oct 11, 2007 12:12 PM by Weston M. Price

    JBAS-4517 - "Removal" of JMSContainerInvoker in head

    Adrian Brock Master

      I've converted the old JMSContainerInvoker in jboss-head to use the
      JCA 1.5 inbound resource adapter.

      This involved:

      * Changing the JMSContainerInvoker class to just be a hardwired version
      of an inflow mdb deployment. i.e. it now extends the JBossJMSMessageEndpointFactory

      * Added support for start/stopDelivery() to the JBossMessageEndpointFactory

      * Added the old JMSContainerInvoker JMX notifications to the JmsActivation

      * Completing the mapping of the old DLQ config in the JBossJMSMessageEndpointFactory

      * While I was there, I did some work on making the MessageEndpointInterceptor
      and the JmsActivation a bit more thread safe


      1) I haven't written the tests for the start/stopDelivery() of the normal inflow
      container. We also need a "deliveryActive" configuration for
      the inflow invoker-proxy-binding config so you can deploy an inflow MDB
      in the inactive state.

      2) The start/stopDelivery() tests of the JMSContainerInvoker are failing for
      topics. I think this relates to the startDelivery() being asynch so the
      initialization of topic subscription is racing with the send()? But need to verify this.

      3) The JmsActivationSpec has no support for DLQ "time-to-live"
      this needs adding the jms inbound resource adapter for backwards compatibility

      4) There are some methods in the JMSContainerInvoker JMX interface
      that are not implemented. Not sure if we want to support these since the
      the profile service is probably a better way to do what this doing?

      5) There is no longer any support for createJBossMQDestination().
      If we really want to support this (I don't :-) then it should be some kind of a plugin
      to the jms resource adapter (maybe a factory class passed into the activation spec?)

      6) The restartJMS() test is not implemented for JBoss Messaging, something
      I'll take up in the jms forum.
      All these tests were very broken in jboss-head anyway! :-(

      7) I kept the old JMSContainerInvoker notifications names for backwards
      compatibility, e.g. org.jboss.ejb.plugins.jms.CONNECTING, rather than

      8) The support for the old JMSContainerInvoker notifications is a hack.
      It's based on the JBossMessageEndpointFactory implementing
      JBossNotificationBroadcasterSupport (something the EJB3 container
      doesn't do!). This needs doing in a better way.