-
1. Re: migrating from ServiceMBeanSupport
alesj Nov 27, 2007 6:11 PM (in response to jhalliday)"jhalliday" wrote:
The software is used standalone as well as in JBossAS. Internally we will continue to use MBeans as that's easiest for the standalone version. The JBossAS integration previously called ServiceMBeanSupport.getServer() to get an MBeanServer for use internally. What is the equivalent call in MC (or AS5.0)?
MC is all about POJOs.
So there is no direct link to MBeanServer or other MC internals.
But you can simply get that injected - @Inject or via XML.
It's up to your bean. ;-)"jhalliday" wrote:
We previously used NotificationListener to register such that a method on our bean is invoked when some other bean (jboss.system:type=Server) entered a specified state (running). Is there a way to wire such a thing in MC? It's not quite the same as requiring the other bean to be started before our bean. Indeed, such a solution is not viable as we must start earlier. The BarrierController seems close to what I need but the example is old - is this functionality still present in MC? (http://wiki.jboss.org/wiki/Wiki.jsp?page=BarrierController)
You can use different dependency mechanisms. From the one's that already exist - depend, demand - or you can easily write your own.
Or there is also KernelEventListener - http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/spi/event/ - if that's what suites you best.
e.g.<bean name="mybean" class="org.jboss.acme.FooBar"> <demands state="Start">jboss.system:type=Server</demand> </bean>
-
2. Re: migrating from ServiceMBeanSupport
alesj Nov 27, 2007 7:13 PM (in response to jhalliday)In this e.g. case 'jboss.system:type=Server' must already be installed in order for 'mybean' demand dependency to be satisfied - to pass Start state.
-
3. Re: migrating from ServiceMBeanSupport
jhalliday Nov 28, 2007 4:23 AM (in response to jhalliday)Thanks Ales
For the MBeanServer, I've opted to try injecting. That should work, but I can't figure out the correct xml.<mbean name="jboss:service=TransactionManager" code="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> <constructor> <parameter type="javax.management.MBeanServer"> <inject bean="JMXKernel" property="mbeanServer"/></parameter>
does not work, the parameter elements are not seen. Scott suggested<arg type="javax.management.MBeanServer"><inject bean="JMXKernel" property="mbeanServer"/></arg>
instead, which does not work either ("Missing 'value' attribute in constructor arg"). That leaves me stuck, as I can't figure out the syntax for injecting to an attribute in the xml.
For the notifications, there does not appear any way to specify what I want in xml. I'll either have to split my bean into two or link it against the event listener code. -
4. Re: migrating from ServiceMBeanSupport
starksm64 Nov 28, 2007 4:50 AM (in response to jhalliday)Injection would be done via an attribute like:
<mbean name="jboss:service=TransactionManager" code="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> ... <attribute name="MBeanServer"><inject bean="JMXKernel" property="mbeanServer"/></attribute> </mbean>
-
5. Re: migrating from ServiceMBeanSupport
jhalliday Nov 28, 2007 5:44 AM (in response to jhalliday)Scott
That value is write once i.e. I want it set through the constructor, not exposed as a setter on the bean. Are you saying that's not possible currently?
Thanks -
6. Re: migrating from ServiceMBeanSupport
alesj Nov 28, 2007 12:56 PM (in response to jhalliday)"jhalliday" wrote:
Are you saying that's not possible currently?
Looking at the code:
- http://anonsvn.jboss.org/repos/jbossas/trunk/system-jmx/src/main/org/jboss/system/metadata/ServiceMetaDataParser.java
looks like you currently cannot do injection with constructor (see parseConstructor method). -
7. Re: migrating from ServiceMBeanSupport
jhalliday Nov 29, 2007 5:59 AM (in response to jhalliday)Fair enough. So I can't do much of my setup in the service constructor, as I don't have the information yet at that time. I need to do the work in the start method instead. That's actually less effort for me, as it's how things currently work.
The problem with that is: many other services depend on the transaction manager. As far as I can tell, under the old pre-MC semantics, depends meant 'ensure the other service has started'. As a result, work the transaction manager does in the start method would be finished before anything that depends on it was executed. Under MC, depends seems to mean 'ensure the service I depend on has reached at least the same point in the lifecycle as the one I'm transitioning to' by default.
As a result, some services are being instantiated and failing because they actually depend on the transaction manager having been started, not just created. Moving the work of transaction manager setup into its service constructor would have fixed that, but it's not an option. The only alternative I see is to change the depends clause of all the things that depend on the transaction manager, such that they explicitly require it to be started. That's somewhat less elegant than I was hoping for. -
8. Re: migrating from ServiceMBeanSupport
alesj Nov 29, 2007 7:05 AM (in response to jhalliday)"jhalliday" wrote:
Fair enough. So I can't do much of my setup in the service constructor, as I don't have the information yet at that time. I need to do the work in the start method instead. That's actually less effort for me, as it's how things currently work.
btw: what's stopping you from using MC beans instead of mbeans, if you're already migrating"jhalliday" wrote:
The problem with that is: many other services depend on the transaction manager. As far as I can tell, under the old pre-MC semantics, depends meant 'ensure the other service has started'. As a result, work the transaction manager does in the start method would be finished before anything that depends on it was executed. Under MC, depends seems to mean 'ensure the service I depend on has reached at least the same point in the lifecycle as the one I'm transitioning to' by default.
Previous depend was/is like this:
A depends on B --> B created, then A could be created, B started, A could start
And this is still the same:
From ServiceDependencyMetaDatavisitor.addDependency(new LifecycleDependencyItem(name, other, ControllerState.CREATE)); visitor.addDependency(new LifecycleDependencyItem(name, other, ControllerState.START));
From MC's AbstractDependencyMetaDataDependencyItem item = new LifecycleDependencyItem(context.getName(), ControllerState.CREATE); visitor.addDependency(item); item = new LifecycleDependencyItem(context.getName(), ControllerState.START); visitor.addDependency(item);
-
9. Re: migrating from ServiceMBeanSupport
jhalliday Nov 29, 2007 7:37 AM (in response to jhalliday)ok, so I must be doing something wrong then. I take a class that previously extended ServiceMBeanSupport. I change it so it no longer does so. I change startService() to start(). I drop it into the app server and hey presto, thing that depend upon it break.
12:29:28,517 INFO [JMXKernel] Legacy JMX core initialized
12:29:41,350 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/
12:29:43,385 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,type=local state=Create mode=Manual requiredState=Installed
javax.naming.NameNotFoundException: TransactionManager not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:542)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:550)
at org.jnp.server.NamingServer.getObject(NamingServer.java:556)
at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at org.jboss.invocation.local.LocalInvoker.startService(LocalInvoker.java:77)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299)
If I'm reading that trace right, the name=jboss:service=invoker,type=local bean is being started and running into problems because start() has not yet been called on the transaction manager bean. I think there is some mismatch here between the lifecycle that occured under ServiceMBeanSupport. vs. the one I get with MC. -
10. Re: migrating from ServiceMBeanSupport
alesj Nov 29, 2007 7:44 AM (in response to jhalliday)"jhalliday" wrote:
I change it so it no longer does so. I change startService() to start().
What about createService() --> create()? -
11. Re: migrating from ServiceMBeanSupport
jhalliday Nov 29, 2007 7:53 AM (in response to jhalliday)I don't have a createService/create method. Besides, the invoker bean is moving into the run state, which means the transaction manger should have had start() called on it? It does not seem to get that call. I can add a create() to see if that gets called, but I'm not clear what help that would be.
-
12. Re: migrating from ServiceMBeanSupport
jhalliday Nov 29, 2007 7:56 AM (in response to jhalliday)hmm, create() does not get called either. Is it possible there is something odd with lifecycle callbacks to mbeans?
-
13. Re: migrating from ServiceMBeanSupport
alesj Nov 29, 2007 8:04 AM (in response to jhalliday)Can you post this XML.
-
14. Re: migrating from ServiceMBeanSupport
jhalliday Nov 29, 2007 8:08 AM (in response to jhalliday)<mbean name="jboss:service=TransactionManager" code="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> <property name="transactionTimeout">300</property> <property name="ObjectStoreDir">${jboss.server.data.dir}/tx-object-store</property> </mbean>