Getting a WorkManager in JBoss EAP 6.3 for Multithreading

[Robert Corcoran]

We are migrating our Java web application to run on JBoss EAP 6. We are currently running on JBoss EAP 5.2. In order to not have to create Java threads directly, we implemented the following code in 5.2 (via the jboss-j2se.jar):
MBeanServer server = MBeanServerLocator.locateJBoss();
return (javax.resource.spi.work.WorkManager)server.getAttribute(new ObjectName("jboss.jca:service=WorkManager"), "Instance");

 

Apparently, though, with Jboss EAP 6.x,  we can no longer get a WorkManager via an MBean.

 

I have noticed that there is an IronJacamar module within the JBoss 6 modules directory. I was wondering if we could get a WorkManager via org.jboss.jca..core.api.workmanager.WorkManager and WorkManagerImpl classes, or do we need to write or generate a custom resource adapter?

As a test, I added the IronJacamar modules to our EAR's MANIFEST.MF (Dependencies: org.jboss.ironjacamar.api, org.jboss.ironjacamar.impl)  and tried some simple code to get a work manager: WorkManager wm = new WorkManagerImpl(). I know this is simplistuc, and anyway I ended up with a null pointer exception when calling  workManager.scheduleWork(work). But I wonder if anyone can tell me if I am heading in the right direction with the approach of leveraging the IronJacamar JBoss module to get a WorkManager for the purposes of multithreading? Or do we have to download the IronJacamar implementation of the Java EE Connector Architecture 1.7 and work with that instead?. 

 

Thanks very much,

Bob

[Stefano Maestri]

Hi,

yes you can't get workmanager from MBean anymore, but you can get it from Service registry. Something like:

final ServiceRegistry registry = context.getServiceRegistry(true);

final ServiceName wmServiceName = ConnectorServices.WORKMANAGER_SERVICE.append(name);


final ServiceController<?> wmController = registry.getService(wmServiceName);

final WorkManager wm = (WorkManager) wmController.getValue();

Where name is the name of workmanager set in jca element in standalone/domain xml. Name used for default workmanager is just "defaul".

Let me know if it solve your problem

regards

S.

[Robert Corcoran]

Hi Stefano,

Thanks for your reply. Regarding context.getServiceRegistry, can you tell me how to define the 'context' variable?

[Stefano Maestri]

Hi Bob,

thinking again to your case, my suggestion isn't probalby the best one. To do what I was suggestion you should hack too much wildfly, because that context is available only during deployment, so you should hack deployment. Forget this, and have a look there:

https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/workmanager/LongRunningThreadsCheckTestCase.java

In this test case we are getting workmanager from an adminobject (but the same could be done from a connectionDefinition) looking up it through jndi, that is probably much more convenient for you operating, if I well understood, from a web application.

If it doesn't help, please provide me a bit more context and I'll try to figure out aomething else

regards

S.

[Robert Corcoran]

Hi Stefano,

I've actually gone in the direction of creating an IronJacamar resource adapter to get a WorkManager. It is being successfully deployed in JBoss 6.3. It seems to be  working correctly. When I set breakpoints and start the server in debug mode, I can see, among other things, an org.jboss.as.connector.services.workmanager.NamedWorkManager object being set in the WorkResourceAdapter class.

The issue I'm having now is I can't get an instance of WorkConnectionFactory injected into my application. The variable is always null.  I am trying it this way:

@Resource(mappedName = "java:/eis/WorkManager") 

private WorkConnectionFactory connectionFactory; 

The ironjacamar.xml file looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<ironjacamar>

  <connection-definitions>

    <connection-definition 

     class-name="org.jboss.jca.core.workmanager.rars.dwm.WorkManagedConnectionFactory" 

     jndi-name="java:/eis/WorkManager"/>

  </connection-definitions>

</ironjacamar>

I arbitrarily put a static constant in the WorkConnectionFactoryImpl () class for testing purposes, and can access it from my application code (log.info(WorkConnectionFactoryImpl.test)). So the EAR is able to access the resource adapter. It's just that I can't get an injected instance of WorkConnectionFactory (into my POJO).

I've also written a test case (modeled on the helloWorld test case included in the samples) that works fine - it does inject a WorkConnectionFactory object using the same approach as mentioned above.

Thanks,

Bob

[Stefano Maestri]

Hi,

can you try with a standard jndi lookup? Just to understand if WM is correctly deployed and exposed to jndi and the problem is on injection.

regards

S.

[Robert Corcoran]

Hi Stefano,

I took your advice and did a standard jndi lookup. Something interesting is happening now on the following line of code:

WorkManagerConnectionFactory wcf = (WorkManagerConnectionFactory) ctx.lookup("java:/eis/WorkManagerConnectionFactory");

If I set a breakpoint on that line and right click/inspect just the context lookup (without the cast), I can see the fully populated WorkManagerConnectionFactoryImpl object. However, when I add the cast to the lookup, the following error occurs: could not resolve type: com.[ourcompanyname].resourceadapter.workmanager.WorkManagerConnectionFactory, and, of course, when stepping to the next line an exception occurs. To recap, we are deploing the .rar file along with our EAR.

So, next I decided to try implementing the resource adapter as a JBoss custom module. I started from scratch and used the IronJacamar code generator, which is great. After adding the requisite work manager code, I added the workmanager  resource adapter elements to the resource adapter subsystem in standalone-full.xml, and created the custom module with the just the workmanager.jar, the IronJacamar.xml, the ra,xml and the new module.xml file. The strange thing is we ended getting the exact same error as mentioned above. I should note that we have other custom modules, like security and our Oracle data source that are working well.

So then I decided to make the resource adapter a global module (just adding a line in the global modules subsystem) and moving the workmanager module folders to the root folder. And now it works!

So,we are going with the JBoss module approach. We would rather run it as a custom module, but we can live with the global module approach.

Thanks again for all your help.

Bob

.