I seem to have a related issue trying to get Adam Biens connectorz example running (Project connectorZ--Lean JCA 1.6 File Store : Adam Bien's Weblog).
The RAR deploys fine and registers the connection factory in the JNDI name space:
18:16:43,824 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) CdMeta: <connection-definition><managedconnectionfactory-class>org.connectorz.files.store.GenericManagedConnectionFactory</managedconnectionfactory-class><config-property><description>The root folder of the file store</description><config-property-name>rootDirectory</config-property-name><config-property-type>java.lang.String</config-property-type><config-property-value>./store/</config-property-value><config-property-ignore>false</config-property-ignore><config-property-supports-dynamic-updates>true</config-property-supports-dynamic-updates><config-property-confidential>false</config-property-confidential></config-property><connectionfactory-interface>org.connectorz.files.BucketStore</connectionfactory-interface><connectionfactory-impl-class>org.connectorz.files.store.FileBucketStore</connectionfactory-impl-class><connection-interface>org.connectorz.files.Bucket</connection-interface><connection-impl-class>org.connectorz.files.store.FileBucket</connection-impl-class></connection-definition>
18:16:43,826 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) ConnectionDefinitions: 1
18:16:43,827 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) Activating: <connection-definition class-name="org.connectorz.files.store.GenericManagedConnectionFactory" jndi-name="java:/jca/files" enabled="true" use-java-context="true" pool-name="BucketStore" use-ccm="true" sharable="true" enlistment="true" connectable="false"></connection-definition>
18:16:43,829 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) jca-file-store.rar: #GenericManagedConnectionFactory.setLogWriter
18:16:43,835 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) jca-file-store.rar: #GenericManagedConnectionFactory.createConnectionFactory,1
18:16:43,835 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) jca-file-store.rar: #FileBucketStore
18:16:43,835 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-8) WFLYJCA0007: Registered connection factory java:/jca/files
18:16:44,210 INFO [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "jca-file-store.rar" (runtime-name : "jca-file-store.rar")
and the deployment of the WAR also works because it has its own copy of the api.jar:
18:24:21,721 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 73) WFLYUT0021: Registered web context: /jca-file-client
18:24:21,806 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "jca-file-client.war" (runtime-name : "jca-file-client.war")
But the client part WAR file cannot inject the resource if I access the client using REST:
@Resource(lookup = "java:/jca/files") // modified from Adam Biens version
18:30:22,848 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /jca-file-client/v1/files/a.txt: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBException: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Can not set org.connectorz.files.BucketStore field com.abien.filestore.FilesResource.bucketStore to org.connectorz.files.store.FileBucketStore
Because the naming are the same I suspect the class-loaders differ. The api.jar is contained in both the RAR and the WAR file. But I remove it from the WAR it will not picked up from the RAR as it should.
Adding to WEB-INF/jboss-deployment-structure.xml
<module name="deployment.jca-file-store.rar" />
helps and the resource can be injected.
Is this a (known) bug or my fault?
You should remove all your API JARs from all your deployments. They are provided by the container. Assuming you mean the EE API.
If you mean the API that the RAR provides that should not be in the WAR. That should probably be in the RAR as well.
I can only tell you what I did and what worked for me. Phillippe might be right as well. my rar in one case has actually the api.jar inside it and there is no other references to it so there is only one class loader that actually holds it. What i did was, for the ear files or war files which need to reference to that jar i made a jboss-deployment-decriptor.xml and put deployment.myapp.rar as a dependencies. this works fine as well..
I have other rars and they are just empty. they only have ra.xml in them in this case they use a library api.jar but that library is located inside an ear. so its available to the jar and wars inside.
so you can use either way i think.
What i mean is that there is only one api.jar in the whole wildfly. you just need to work with that. Dont add it in two places or you can actually get SomeconnectorIntrospec cannot be cast to SomeconnectorIntrospec .
Of course, I mean the API provided by the RAR. It is contained both in the RAR and the WAR.
" Can not set org.connectorz.files.BucketStore field com.abien.filestore.FilesResource.bucketStore to org.connectorz.files.store.FileBucketStore"
indicates that the class-loaders differ because the interface definitions come from different API jars loaded by different class-loaders.
But I add the module dependency this error disappears because only one API jar is loaded (I guess the one from the RAR file).
Now I could of course remove the API jar from the WAR file -- but leaving it works as well.
The issue here is that this behaviour is against the JCA 1.7 spec, the explicit module dependency should not be needed.
Are you aware of any bug in that area? Or should I file a WildFly bug to track this down?
Excerpt from JCA 1.7 specification
■ When a standalone resource adapter RARis deployed, the resource adapter may
be made available to all Java EE applications in the application server. The
application server, however, must makethe standalone resource adapter RAR
available to applications that meet the requirements listed in Section 20.3 “Class
20.3 Class Loading Requirements
This specification does not define the exact arrangement or hierarchy of classloaders
that must be used by a container. Thissection of the specification defines the
requirements in terms of what applications must have visibility to a resource adapter
A resource adapter RAR packaged within a Java EE application EAR, as specified in
Section 18.104.22.168 “Requirements” above, must be made available only to the Java EE
application with which it is packaged.
The requirements below specify the applications that must have visibility to a
standalone resource adapter RAR.
■ If an application references a resource using a deployment descriptor entry or a
corresponding annotation, and that resourceis supplied by a standalone resource
adapter, that standalone resource adapter must be made available to the
■ If an application references an extension using the Extension Mechanism
Architecture (see the section titled “Library Support” in the “Application
Assembly and Deployment” chapter of the “Java Platform, Enterprise Edition
(Java EE) Specification, version 7” on page E-1) and a jar file within a standalone
resource adapter supplies that extension, the standalone resource adapter must be
made available to the application.
■ If a standalone resource adapter is configured to deliver messages to a messagedriven bean in an application, the standalone resource adapter must be made
available to the application.
■ Even lacking such a reference, it must be possible for the Deployer to configure an
application so that any particular standalone resource adapter is available to the
An application that satisfy the requirements can portably assume the visibility of the
corresponding standalone resource adapter RAR. An application server may choose
to make all deployed standalone resource adapter RARs available to all applications.