[JBoss JIRA] (WFLY-6201) Servlet feature pack domain template missing other-server-group
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6201?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-6201:
--------------------------------
Workaround Description:
Launch the embedded host controller in CLI:
{code}
${JBOSS_HOME}/bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-host-controller
[domain@embedded /] /server-group=other-server-group:add(socket-binding-group=standard-sockets, profile=default)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
[domain@embedded /] stop-embedded-host-controller
{code}
If using with the wildfly-maven-plugin the following configuration will fix it. Note this only works with version {{1.1.0.Alpha6}} of the plugin
{code:xml}
<!-- Workaround for WFLY-6201 to allow tests to run with the servlet container only -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<executions>
<execution>
<id>fix-servlet</id>
<phase>test-compile</phase>
<goals>
<goal>start</goal>
<goal>execute-commands</goal>
<goal>shutdown</goal>
</goals>
<configuration>
<server-type>DOMAIN</server-type>
<jboss-home>${jboss.home}</jboss-home>
<server-args>
<server-arg>--admin-only</server-arg>
</server-args>
<stdout>${project.build.testOutputDirectory}${file.separator}admin-only-config.log</stdout>
<execute-commands>
<fail-on-error>false</fail-on-error>
<commands>
<command>/server-group=other-server-group:add(socket-binding-group=standard-sockets, profile=default)</command>
</commands>
</execute-commands>
</configuration>
</execution>
</executions>
</plugin>
{code}
was:
Launch the embedded host controller in CLI:
{code}
${JBOSS_HOME}/bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-host-controller
[domain@embedded /] /server-group=other-server-group:add(socket-binding-group=standard-sockets, profile=default)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
[domain@embedded /] stop-embedded-host-controller
{code}
If using with the wildfly-maven-plugin the following configuration will fix it. Note this only works with version {{1.1.0.Alpha6}} of the plugin
{code:xml}
<!-- Workaround for WFLY-6201 to allow tests to run with the servlet container only -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<executions>
<execution>
<id>fix-servlet</id>
<phase>test-compile</phase>
<goals>
<goal>start</goal>
<goal>execute-commands</goal>
<goal>shutdown</goal>
</goals>
<configuration>
<server-type>DOMAIN</server-type>
<jboss-home>${jboss.home}</jboss-home>
<server-args>
<server-arg>--admin-only</server-arg>
</server-args>
<stdout>${project.build.testOutputDirectory}${file.separator}admin-only-config.log</stdout>
<execute-commands>
<fail-on-error>false</fail-on-error>
<commands>
<command>/server-group=other-server-group:add(socket-binding-group=standard-sockets, profile=default</command>
</commands>
</execute-commands>
</configuration>
</execution>
</executions>
</plugin>
{code}
> Servlet feature pack domain template missing other-server-group
> ---------------------------------------------------------------
>
> Key: WFLY-6201
> URL: https://issues.jboss.org/browse/WFLY-6201
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 10.1.0.Final
>
>
> The current domain template from the servlet-feature-pack is missing the {{other-server-group}} configuration causing a failure to boot.
> {code}
> [Host Controller] 09:58:51,179 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0369: Required capabilities are not available:
> [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> [Host Controller] 09:58:51,181 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6201) Servlet feature pack domain template missing other-server-group
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6201?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-6201:
--------------------------------
Workaround Description:
Launch the embedded host controller in CLI:
{code}
${JBOSS_HOME}/bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-host-controller
[domain@embedded /] /server-group=other-server-group:add(socket-binding-group=standard-sockets, profile=default)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
[domain@embedded /] stop-embedded-host-controller
{code}
If using with the wildfly-maven-plugin the following configuration will fix it. Note this only works with version {{1.1.0.Alpha6}} of the plugin
{code:xml}
<!-- Workaround for WFLY-6201 to allow tests to run with the servlet container only -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<executions>
<execution>
<id>fix-servlet</id>
<phase>test-compile</phase>
<goals>
<goal>start</goal>
<goal>execute-commands</goal>
<goal>shutdown</goal>
</goals>
<configuration>
<server-type>DOMAIN</server-type>
<jboss-home>${jboss.home}</jboss-home>
<server-args>
<server-arg>--admin-only</server-arg>
</server-args>
<stdout>${project.build.testOutputDirectory}${file.separator}admin-only-config.log</stdout>
<execute-commands>
<fail-on-error>false</fail-on-error>
<commands>
<command>/server-group=other-server-group:add(socket-binding-group=standard-sockets, profile=default</command>
</commands>
</execute-commands>
</configuration>
</execution>
</executions>
</plugin>
{code}
> Servlet feature pack domain template missing other-server-group
> ---------------------------------------------------------------
>
> Key: WFLY-6201
> URL: https://issues.jboss.org/browse/WFLY-6201
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 10.1.0.Final
>
>
> The current domain template from the servlet-feature-pack is missing the {{other-server-group}} configuration causing a failure to boot.
> {code}
> [Host Controller] 09:58:51,179 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0369: Required capabilities are not available:
> [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> [Host Controller] 09:58:51,181 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6216) Servlet feature pack domain template missing other-server-group
by James Perkins (JIRA)
James Perkins created WFLY-6216:
-----------------------------------
Summary: Servlet feature pack domain template missing other-server-group
Key: WFLY-6216
URL: https://issues.jboss.org/browse/WFLY-6216
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Reporter: James Perkins
Assignee: James Perkins
Fix For: 10.1.0.Final
The current domain template from the servlet-feature-pack is missing the {{other-server-group}} configuration causing a failure to boot.
{code}
[Host Controller] 09:58:51,179 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0369: Required capabilities are not available:
[Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
[Host Controller] 09:58:51,181 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1340:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.1.0.CR2
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
> Proposed structure:
> Resources are at address /host-exclude=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * host-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * excluded-extensions
> * active-server-groups
> * active-socket-binding-groups
> The excluded-extensions attribute is a list of extension names the resources that (/extension=X) the DC should hide from the target hosts. Generally because the hosts will not have the necessary extension modules in their installation.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* excluded from the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be hidden; all others of these types will be hidden. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the server groups listed in active-server-groups is not the complete set of sbgs needed on servers running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
>
> Adding a new group to active-server-groups or active-socket-binding-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data. A reload or restart of the slave or master causes a reconnect.
> Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in in the ignored-resources elements host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand. If a slave has ignored-resources explicitly configured, that information will be used in managing that slave, in combination with any matching configuration in a host-exclude. However, the related ignore-unused-configuration setting added in WildFly Core (not present in EAP 6) will be handled differently.
> A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC as to what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'excluded-extensions' data *will* be used for the slave.
> An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6185) "org.jboss.vfs.VirtualFilePermission" by some tests in TS with security manager
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6185?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet reassigned WFLY-6185:
---------------------------------------
Assignee: Hynek Švábek (was: ehsavoie Hugonnet)
> "org.jboss.vfs.VirtualFilePermission" by some tests in TS with security manager
> -------------------------------------------------------------------------------
>
> Key: WFLY-6185
> URL: https://issues.jboss.org/browse/WFLY-6185
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Hynek Švábek
>
> Some tests fails due to java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" while run with security manager enabled.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
> * org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
> *How to reproduce*
> * ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
> * ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
> *Stacktrace*
> {code}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
> at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
> at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
> at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
> at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
> at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6215) SessionSynchronization callbacks allow concurrent access to SFSB
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6215?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated WFLY-6215:
-------------------------------
Summary: SessionSynchronization callbacks allow concurrent access to SFSB (was: SessionSynchronization allows concurrent access to SFSB)
> SessionSynchronization callbacks allow concurrent access to SFSB
> ----------------------------------------------------------------
>
> Key: WFLY-6215
> URL: https://issues.jboss.org/browse/WFLY-6215
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Ryan Emerson
> Attachments: wfly_reproducer.tar.gz
>
>
> Issue first encountered by customer in EAP5 (JBPAPP-11239).
> Assume a local SFSB, B1, with container managed transactions and a calling SFSB, B2, which has bean managed transactions. B1 implements the SessionSynchronization interface.
> When B2's bean managed transaction timesout whilst executing B1.exampleMethod(), B2's transaction aborts and the transaction reaper thread calls B1.afterCompletion(). However, the original worker thread that was executing B1.exampleMethod() continues to execute B1.exampleMethod() until it has completed. Hence it is possible for the B1 SFSB to be accessed concurrently.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5549) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5549?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-5549:
-------------------------------------
In this case I specifically added entitymanager to the pom by hand.
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-5549
> URL: https://issues.jboss.org/browse/WFLY-5549
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: carlos feria
> Assignee: Scott Marlow
>
> 10:06:35,545 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.persistenceunit."********": org.jboss.msc.service.StartException in service jboss.persistenceunit."*******": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.dom4j.DocumentFactory.getInstance(DocumentFactory.java:97)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:33)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:27)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.workWithClassLoader(ClassLoaderServiceImpl.java:342)
> at org.hibernate.internal.util.xml.XMLHelper.<init>(XMLHelper.java:26)
> at org.hibernate.envers.boot.internal.EnversServiceImpl.initialize(EnversServiceImpl.java:115)
> at org.hibernate.envers.boot.internal.AdditionalJaxbMappingProducerImpl.produceAdditionalMappings(AdditionalJaxbMappingProducerImpl.java:99)
> at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:288)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:770)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:797)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> 10:06:35,552 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "cooperativa-1.0.0.Final.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory"}}
> 10:06:35,732 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "cooperativa-1.0.0.Final.war" (runtime-name : "cooperativa-1.0.0.Final.war")
> 10:06:35,733 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6215) SessionSynchronization allows concurrent access to SFSB
by Ryan Emerson (JIRA)
Ryan Emerson created WFLY-6215:
----------------------------------
Summary: SessionSynchronization allows concurrent access to SFSB
Key: WFLY-6215
URL: https://issues.jboss.org/browse/WFLY-6215
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.0.0.Final
Reporter: Ryan Emerson
Attachments: wfly_reproducer.tar.gz
Issue first encountered by customer in EAP5 (JBPAPP-11239).
Assume a local SFSB, B1, with container managed transactions and a calling SFSB, B2, which has bean managed transactions. B1 implements the SessionSynchronization interface.
When B2's bean managed transaction timesout whilst executing B1.exampleMethod(), B2's transaction aborts and the transaction reaper thread calls B1.afterCompletion(). However, the original worker thread that was executing B1.exampleMethod() continues to execute B1.exampleMethod() until it has completed. Hence it is possible for the B1 SFSB to be accessed concurrently.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months