"jhalliday" wrote :
| I also have problems because some things are not happening in the right order. Before
either create or start is called on the transaction manager bean I see something that
depends on it being started. Huh? This does not follow my understanding of the lifecycle,
which is that dependent objects should not move into a state until everything they depend
on has achieved at least an equivalently advanced state. Does the required state need to
be specified explicitly on the CachedConnectionManager? Or perhaps this behaviour is
something to do with the CCM being an mbean whilst the TM is a bean?
| 14:22:54,750 ERROR [AbstractKernelController] Error installing to Start:
name=jboss.jca:service=CachedConnectionManager state=Create mode=Manual
| | java.lang.ExceptionInInitializerError
| | at
| | ...
| | Caused by: java.lang.RuntimeException: Unable to locate the transaction manager
| | at
| | ...
What does your implementation look like?
If you register it as an MBean you effectively get a duplicate lifecycle,
once from the registeration in the ServiceController and once from the
registration as a POJO.
The ServiceMBeanSupport works around this by only allowing create() to propogate
to createService() when it is not already done.
Stupid I know, but nobody has gotten around to fixing the
@JMX support to link the ServiceController lifecycle to the POJO one.
i.e. it shouldn't move to the create() state in the old JMX kernel until it moves
to the create() state in the MC (and then it should be a no-op in JMX).
i.e. The serviceController.start() in the code below shouldn't exist. Instead
the create/start/stop/destroy moves in the ServiceController should be
driven off the POJO lifecycle.
| server.registerMBean(mbean, objectName);
| catch (Exception e)
| catch (Exception t)
| log.debug("Error unregistering mbean", t);
| throw e;
| log.debug("Registered MBean " + objectName);
View the original post :
Reply to the post :