Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-9585

Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name

    XMLWordPrintable

Details

    Description

      We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used. But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.

      We have in the ejb-jar.xml

        <enterprise-beans>
    <session>
        <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
        <resource-ref>
            <res-ref-name>jdbc/RMDataSource</res-ref-name>
            <res-type>javax.sql.DataSource</res-type>
            <res-auth>Container</res-auth>
        </resource-ref>
        <persistence-context-ref>
            <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
        </persistence-context-ref>
    </session>

      and in jboss-ejb3.xml

        <jboss:enterprise-beans>
    <jboss:ejb>
        <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
        <resource-ref>
            <res-ref-name>jdbc/RMDataSource</res-ref-name>
            <res-type>javax.sql.DataSource</res-type>
            <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
        </resource-ref>
    </jboss:ejb>

      the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.

      But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"

      If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.

      Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.

      Attachments

        Issue Links

          is related to

          Bug - A problem that impairs or prevents the functions of the product. WFLY-14025 Unable to remove the default datasource binding from the ee subsystem

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              tadamski@redhat.com Tomasz Adamski
              lamshing Shing Lam (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: