• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

ResourceAdapter issues on Wildfly

 
Ranch Hand
Posts: 160
IntelliJ IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good Day Folks

I'm busy migrating an application from JBoss 4.2.3 to Wildfly 8.1, and I'm stuck on a resource adapter issue. The system that I'm working on talks to another system, via a provided resource adapter. I've configured my resource-adapter in my standalone-full.xml file, and I've taken the provided .rar archive (the same one that we used for JBoss 4.2.3) and put it in my deployments directory.

When my server starts up, I can see that Wildfly is trying to deploy the resource adapter, but halfway through, it depends blows up in the ManagedConnectionFactory implementation that is packaged in my .rar. Since the .rar has been provided to us, I don't actually have the original source code for it - I only have a decompiled view in my IDE that I can use to debug. Based on what I can see, Wildfly uses a class called org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService to deploy the resource adapter. In doing so, it instantiates the javax.resource.spi.ResourceAdapter implementation in the .rar, and then ends up calling createConnectionFactory(ConnectionManager paramConnectionManager) on our ManagedConnectionFactory implementation, via createObjectsAndInjectValue(URL url, String deploymentName, File root, ClassLoader cl, Connector cmd, IronJacamar ijmd, org.jboss.jca.common.api.metadata.resourceadapter.ResourceAdapter raxml) on AbstractResourceAdapterDeploymentService (all of this is done by Wildfly while trying to deploy). However, the implementation assumes that a javax.resource.spi.BootstrapContext would already have been set on the resource adapter when this method is invoked. The code sets the bootstrap context from the start(BootstrapContext ctx) method on the resource adapter implementation class.

Based on logging output, JBoss 4.2.3 creates the ResourceAdapter implementation instance, and immediately thereafter calls its start(BootstrapContext ctx) method. Wildfly, on the other hand, instantiates the ResourceAdapter, but it doesn't call the start(...) method - which means that the bootstrap context isn't initialized by the time that the createConnectionFactory(...) method tries to use it - and ultimately, it results in a NullPointerException.

I realise that his is quite an involved problem, and it probably won't be easy to come up with an answer, but I've been struggling for a couple of days already, so I was hoping that someone might have an answer. How can I get Wildfly to start the resource adapter immediately after creating it?

Thanks,
Riaan

(Apologies if my formatting looks bad - I tried to highlight the classes that relate to my issue)
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Riaan, good job, you seem to have done a good amount of investigation into this already and that now narrows the issue down to figuring out what the right behaviour is. I am not an expert on resource adapters, so I don't have an answer to this, but I suggest you download the JCA 1.6 spec from here http://download.oracle.com/otndocs/jcp/connector_architecture-1.6-fr-eval-oth-JSpec/ and read through some of the relevant chapters in it. I think you'll find the answer to your question in there. If you don't, then feel free to post back here.
 
Riaan Nel
Ranch Hand
Posts: 160
IntelliJ IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jaikiran Pai wrote:Riaan, good job, you seem to have done a good amount of investigation into this already and that now narrows the issue down to figuring out what the right behaviour is. I am not an expert on resource adapters, so I don't have an answer to this, but I suggest you download the JCA 1.6 spec from here http://download.oracle.com/otndocs/jcp/connector_architecture-1.6-fr-eval-oth-JSpec/ and read through some of the relevant chapters in it. I think you'll find the answer to your question in there. If you don't, then feel free to post back here.



Thanks Jaikiran, that spec was useful. I read chapter 5 (Lifecycle Management), and it largely confirmed what I expected. It makes reference to the start(BootstrapContext ctx) method, although I couldn't find anything that explicitly dictates the order in which events should happen prior to starting the resource adapter. I went back to Wildfly's AbstractResourceAdapterDeploymentService, and after a bit of deep diving into the code, I found that it will start the resource adapter only after creating the managed connection factory (which fails, because the implementation that we had depended on the resource adapter being started already). It is invoked reflectively, so it was a bit tricky to find it - which is probably why I missed it the first time round.

The sequence of events seems to differ from JBoss 4.2.3, but I wouldn't call it a bug - like I said, the spec doesn't seem to explicitly state what should happen prior to the resource adapter being started. Eventually, I ended up having to decompile the managed connection factory and resource adapter implementations in the RAR that I had, move some code around, recompile the classes and stick them back into the archive. That seems to have done the trick, although it is a bit of a hack.

Cheers,
Riaan
reply
    Bookmark Topic Watch Topic
  • New Topic