1 2 Previous Next 18 Replies Latest reply on Sep 26, 2016 8:43 AM by jthoennes Go to original post
      • 15. Re: JCA and Class Loading on WildFly 8.2.0/9.0.0CR2

        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

             BucketStore bucketStore;


        leads to


        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


        <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">



          <module name="deployment.jca-file-store.rar" />





        helps and the resource can be injected.


        Is this a (known) bug or my fault?


        Thanks, Jörg

        • 16. Re: JCA and Class Loading on WildFly 8.2.0/9.0.0CR2

          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.

          • 17. Re: JCA and Class Loading on WildFly 8.2.0/9.0.0CR2

            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 .

            • 18. Re: JCA and Class Loading on WildFly 8.2.0/9.0.0CR2

              Of course, I mean the API provided by the RAR. It is contained both in the RAR and the WAR.

              The error

              " 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

              Loading Requirements”.


              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 “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.


              1 2 Previous Next