[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Shing Lam edited comment on WFLY-9585 at 12/12/17 3:11 AM:
-----------------------------------------------------------
I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.
we have a datasource to standalone.xml
{{ <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
<connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;characterEncoding=utf8</connection-url>
<driver>com.mysql</driver>
<security>
<security-domain>encrypted-mysqlds-rm_uat</security-domain>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</datasource>}}
If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
if default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.
standalone.xml
{{ <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}
In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection.
was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 42 kB), the older ones are obsolete.
we have a datasource to standalone.xml
{{ <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
<connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;characterEncoding=utf8</connection-url>
<driver>com.mysql</driver>
<security>
<security-domain>encrypted-mysqlds-rm_uat</security-domain>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</datasource>}}
If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
if default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.
standalone.xml
{{ <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}
In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection.
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
> Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> 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
> {code: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>
> {code}
> and in jboss-ejb3.xml
> {code: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>
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Shing Lam edited comment on WFLY-9585 at 12/12/17 3:08 AM:
-----------------------------------------------------------
I have trimmed down the essential minimum of our project to illustrate the issue.
we have a datasource to standalone.xml
{{ <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
<connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;characterEncoding=utf8</connection-url>
<driver>com.mysql</driver>
<security>
<security-domain>encrypted-mysqlds-rm_uat</security-domain>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</datasource>}}
If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
if default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.
standalone.xml
{{ <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}
In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection.
was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue.
we have a datasource to standalone.xml
<datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
<connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;characterEncoding=utf8</connection-url>
<driver>com.mysql</driver>
<security>
<security-domain>encrypted-mysqlds-rm_uat</security-domain>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</datasource>
If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
if default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.
standalone.xml
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection.
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
> Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> 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
> {code: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>
> {code}
> and in jboss-ejb3.xml
> {code: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>
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Shing Lam commented on WFLY-9585:
---------------------------------
I have trimmed down the essential minimum of our project to illustrate the issue.
we have a datasource to standalone.xml
<datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
<connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;characterEncoding=utf8</connection-url>
<driver>com.mysql</driver>
<security>
<security-domain>encrypted-mysqlds-rm_uat</security-domain>
</security>
<validation>
<validate-on-match>false</validate-on-match>
<background-validation>false</background-validation>
</validation>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</datasource>
If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
if default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.
standalone.xml
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection.
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
> Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> 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
> {code: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>
> {code}
> and in jboss-ejb3.xml
> {code: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>
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Shing Lam updated WFLY-9585:
----------------------------
Attachment: jboss-lookup.zip
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
> Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> 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
> {code: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>
> {code}
> and in jboss-ejb3.xml
> {code: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>
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Shing Lam updated WFLY-9585:
----------------------------
Attachment: jBossLookup-ear-0.0.1-SNAPSHOT.ear
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
> Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip
>
>
> 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
> {code: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>
> {code}
> and in jboss-ejb3.xml
> {code: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>
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Shing Lam updated WFLY-9585:
----------------------------
Attachment: jBosslookup.zip
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
> Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip
>
>
> 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
> {code: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>
> {code}
> and in jboss-ejb3.xml
> {code: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>
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Shing Lam (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Shing Lam updated WFLY-9585:
----------------------------
Attachment: jBossLookup-ear-0.0.1-SNAPSHOT.ear
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
> Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip
>
>
> 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
> {code: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>
> {code}
> and in jboss-ejb3.xml
> {code: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>
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-3054) getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
by Alec Henninger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3054?page=com.atlassian.jira.plugin.... ]
Alec Henninger commented on WFLY-3054:
--------------------------------------
FWIW I believe this can be roughly solved by waiting for the "javax.management.builder.initial" system property to be set before calling ManagementFactory.getPlatformMBeanServer(). jboss-modules sets it programmatically, and if the platform MBeanServer is initialized too soon, it won't be created using the custom builder: https://github.com/jboss-modules/jboss-modules/blob/1.x/src/main/java/org...
> getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
> ------------------------------------------------------------------------------------
>
> Key: WFLY-3054
> URL: https://issues.jboss.org/browse/WFLY-3054
> Project: WildFly
> Issue Type: Enhancement
> Components: JMX
> Affects Versions: JBoss AS7 7.1.1.Final
> Reporter: dpocock
> Assignee: Kabir Khan
> Labels: jboss
>
> JMXetric is a management agent JAR loaded using the JVM argument
> java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....
> In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:
> ManagementFactory.getPlatformMBeanServer()
> This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole
> As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.
> However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.
> The 1.0.6 release of jmxetric will include the workaround by default. The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5
> jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.
> Also covered in jmxetric github:
> https://github.com/ganglia/jmxetric/issues/9
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9609) Avoid unnecessary marshalling of AddressableNode wherever possible
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-9609:
----------------------------------
Summary: Avoid unnecessary marshalling of AddressableNode wherever possible
Key: WFLY-9609
URL: https://issues.jboss.org/browse/WFLY-9609
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 11.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Serialization of an AddressableNode requires an additional 7 or 19 bytes (depending on whether the corresponding bind address is IPv4 or IPv6) as well as the logical name as a UTF-8 string; all on top of the 16 bytes required to serialize the JGroups/Infinispan address.
In most cases, this is completely unnecessary, as the Node can always be recreated from the address via a NodeFactory<Address>.
Known offenders are:
* org.wildfly.clustering.server.registry.CacheRegistry which stores the Node as a cache key.
* org.wildfly.clustering.server.provider.CacheServiceProviderRegistry which stores a Set<Node> as a cache value.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3019) The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3019:
---------------------------------------
Okay done, WFCORE-3454. I'll just fix it there and we can look at this later. Full should be okay, but I will double check that PR.
> The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3019
> URL: https://issues.jboss.org/browse/WFCORE-3019
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: James Perkins
> Fix For: 4.0.0.Alpha5
>
>
> For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own.
> The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack.
> So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP.
> Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months