[JBoss JIRA] (WFLY-5658) Improve the subsystem test schema test coverage
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5658?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5658:
-----------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/1250)
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFLY-5658
> URL: https://issues.jboss.org/browse/WFLY-5658
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.CR4
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 10.0.0.Final
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5042) Two persistence.xml in two EJB projects within one EAR don't work
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5042?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-5042 at 11/16/15 4:57 PM:
--------------------------------------------------------------
Martin,
I tried to recreate with the [latest nightly build|https://developer.jboss.org/thread/224262] and could not. Prior to running, I updated the standalone.xml example datasource, to zujcvsdb (same as you did I believe):
{quote}
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
.
.
.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" 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"/>
</subsystem>
{quote}
Let me know if you still see the same failure with the nightly WildFly build. Apologies for taking so long to look at this.
was (Author: smarlow):
Martin,
I tried to recreate with the [latest nightly build|https://developer.jboss.org/thread/224262] and could not. Prior to running, I updated the standalone.xml example datasource, to zujcvsdb (same as you did I believe):
{quote}
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
.
.
.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" 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"/>
</subsystem>
{quote}
Let me know if you still see the same issue, otherwise, I will close this.
> Two persistence.xml in two EJB projects within one EAR don't work
> ------------------------------------------------------------------
>
> Key: WFLY-5042
> URL: https://issues.jboss.org/browse/WFLY-5042
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.0.Final
> Reporter: Martin Rauscher
> Assignee: Scott Marlow
>
> We have an EAR containing a JAR in /lib and two EJBs and one WAR each referencing the JAR. The rest of the dependencies is: WAR->EJB1->EJB2.
> If each of the EJB JARs has its own persistence.xml the EAR cannot be deployed anymore to WildFly. (It worked on WebSphere)
> This works fine as long as no persistence.xml exists. As soon as each EJB gets its own persistence.xml (in our full project they point to different DSs) we're not able to deploy anymore.
> Wildfly doesn't seem to be able to resolve dependencies between modules as soon as there are two persistence.xml's. Despite the (repro) project doesn't even use it (yet). If you remove the persistence.xml's the project works fine. From the error (see below) it looks like the services defined in EJB1 try to use the persistence unit defined in EJB2 despite there not being any kind of reference.
> Repro on [GitHub|https://github.com/Hades32/wildfly-issues].
> Forum discussion [here|https://developer.jboss.org/thread/261445], including logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5042) Two persistence.xml in two EJB projects within one EAR don't work
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5042?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-5042 at 11/16/15 4:56 PM:
--------------------------------------------------------------
Martin,
I tried to recreate with the [latest nightly build|https://developer.jboss.org/thread/224262] and could not. Prior to running, I updated the standalone.xml example datasource, to zujcvsdb (same as you did I believe):
{quote}
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
.
.
.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" 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"/>
</subsystem>
{quote}
Let me know if you still see the same issue, otherwise, I will close this.
was (Author: smarlow):
Martin,
I tried to recreate with the [latest nightly build|https://developer.jboss.org/thread/224262] and could not. Prior to running, I updated the standalone.xml ExampleDS, to zujcvsdb refer to the test datasource:
{quote}
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
.
.
.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" 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"/>
</subsystem>
{quote}
I believe that you made the same configuration changes as mentioned in [https://github.com/Hades32/wildfly-issues].
> Two persistence.xml in two EJB projects within one EAR don't work
> ------------------------------------------------------------------
>
> Key: WFLY-5042
> URL: https://issues.jboss.org/browse/WFLY-5042
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.0.Final
> Reporter: Martin Rauscher
> Assignee: Scott Marlow
>
> We have an EAR containing a JAR in /lib and two EJBs and one WAR each referencing the JAR. The rest of the dependencies is: WAR->EJB1->EJB2.
> If each of the EJB JARs has its own persistence.xml the EAR cannot be deployed anymore to WildFly. (It worked on WebSphere)
> This works fine as long as no persistence.xml exists. As soon as each EJB gets its own persistence.xml (in our full project they point to different DSs) we're not able to deploy anymore.
> Wildfly doesn't seem to be able to resolve dependencies between modules as soon as there are two persistence.xml's. Despite the (repro) project doesn't even use it (yet). If you remove the persistence.xml's the project works fine. From the error (see below) it looks like the services defined in EJB1 try to use the persistence unit defined in EJB2 despite there not being any kind of reference.
> Repro on [GitHub|https://github.com/Hades32/wildfly-issues].
> Forum discussion [here|https://developer.jboss.org/thread/261445], including logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5042) Two persistence.xml in two EJB projects within one EAR don't work
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5042?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-5042 at 11/16/15 4:54 PM:
--------------------------------------------------------------
Martin,
I tried to recreate with the [latest nightly build|https://developer.jboss.org/thread/224262] and could not. Prior to running, I updated the standalone.xml ExampleDS, to zujcvsdb refer to the test datasource:
{quote}
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
.
.
.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" 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"/>
</subsystem>
{quote}
I believe that you made the same configuration changes as mentioned in [https://github.com/Hades32/wildfly-issues].
was (Author: smarlow):
Martin,
I tried to recreate with the latest nightly build and could not. Prior to running, I updated the standalone.xml ExampleDS, to zujcvsdb refer to the test datasource:
{quote}
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
.
.
.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" 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"/>
</subsystem>
{quote}
I believe that you made the same configuration changes as mentioned in [https://github.com/Hades32/wildfly-issues].
> Two persistence.xml in two EJB projects within one EAR don't work
> ------------------------------------------------------------------
>
> Key: WFLY-5042
> URL: https://issues.jboss.org/browse/WFLY-5042
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.0.Final
> Reporter: Martin Rauscher
> Assignee: Scott Marlow
>
> We have an EAR containing a JAR in /lib and two EJBs and one WAR each referencing the JAR. The rest of the dependencies is: WAR->EJB1->EJB2.
> If each of the EJB JARs has its own persistence.xml the EAR cannot be deployed anymore to WildFly. (It worked on WebSphere)
> This works fine as long as no persistence.xml exists. As soon as each EJB gets its own persistence.xml (in our full project they point to different DSs) we're not able to deploy anymore.
> Wildfly doesn't seem to be able to resolve dependencies between modules as soon as there are two persistence.xml's. Despite the (repro) project doesn't even use it (yet). If you remove the persistence.xml's the project works fine. From the error (see below) it looks like the services defined in EJB1 try to use the persistence unit defined in EJB2 despite there not being any kind of reference.
> Repro on [GitHub|https://github.com/Hades32/wildfly-issues].
> Forum discussion [here|https://developer.jboss.org/thread/261445], including logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5042) Two persistence.xml in two EJB projects within one EAR don't work
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5042?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5042:
------------------------------------
Martin,
I tried to recreate with the latest nightly build and could not. Prior to running, I updated the standalone.xml ExampleDS, to zujcvsdb refer to the test datasource:
{quote}
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
.
.
.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/com/daimler/vs3/zujcvsdb" 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"/>
</subsystem>
{quote}
I believe that you made the same configuration changes as mentioned in [https://github.com/Hades32/wildfly-issues].
> Two persistence.xml in two EJB projects within one EAR don't work
> ------------------------------------------------------------------
>
> Key: WFLY-5042
> URL: https://issues.jboss.org/browse/WFLY-5042
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.0.Final
> Reporter: Martin Rauscher
> Assignee: Scott Marlow
>
> We have an EAR containing a JAR in /lib and two EJBs and one WAR each referencing the JAR. The rest of the dependencies is: WAR->EJB1->EJB2.
> If each of the EJB JARs has its own persistence.xml the EAR cannot be deployed anymore to WildFly. (It worked on WebSphere)
> This works fine as long as no persistence.xml exists. As soon as each EJB gets its own persistence.xml (in our full project they point to different DSs) we're not able to deploy anymore.
> Wildfly doesn't seem to be able to resolve dependencies between modules as soon as there are two persistence.xml's. Despite the (repro) project doesn't even use it (yet). If you remove the persistence.xml's the project works fine. From the error (see below) it looks like the services defined in EJB1 try to use the persistence unit defined in EJB2 despite there not being any kind of reference.
> Repro on [GitHub|https://github.com/Hades32/wildfly-issues].
> Forum discussion [here|https://developer.jboss.org/thread/261445], including logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1134) A java.lang.Error in Stage.DONE can lead to hangs
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1134:
----------------------------------------
Summary: A java.lang.Error in Stage.DONE can lead to hangs
Key: WFCORE-1134
URL: https://issues.jboss.org/browse/WFCORE-1134
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.1.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha1
As part of investigating https://bugzilla.redhat.com/show_bug.cgi?id=1259767 I've looked into general handling of situations when java.lang.Error is thrown during management operation execution.
Handling prior to Stage.DONE looks ok, with the error caught, logged and the failure-description on the response set. But if the error happens after commit or during rollback, it isn't always properly triggering a response. In the intra-domain case the remote node that has the problem tries to send a failure response to the calling HC, but uses the wrong request id, resulting in that response being dropped and the calling HC continuing to wait.
A post-commit Error seems pretty unlikely. A rollback error seems more possible, as a rollback may involve installing significant numbers of services.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5689) EJB subsystem security domain mapping
by Farah Juma (JIRA)
Farah Juma created WFLY-5689:
--------------------------------
Summary: EJB subsystem security domain mapping
Key: WFLY-5689
URL: https://issues.jboss.org/browse/WFLY-5689
Project: WildFly
Issue Type: Feature Request
Components: EJB
Reporter: Farah Juma
Assignee: Farah Juma
Fix For: 11.0.0.Alpha1
Allow the EJB subsystem to declare which Elytron security domains it uses.
Sample configuration:
{code:xml}
<security-domains default="ApplicationDomain">
<security-domain name="ApplicationDomain" alias="MyDomain"/>
<security-domain name="ManagementDomain"/>
</security-domains>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months