I've converted the old JMSContainerInvoker in jboss-head to use the
JCA 1.5 inbound resource adapter.
* 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.