[JBoss JIRA] (WFLY-6990) web.xml unprotected url pattern "/" overrides role protected "/*" pattern
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-6990:
--------------------------------------------------
Summary: web.xml unprotected url pattern "/" overrides role protected "/*" pattern
Key: WFLY-6990
URL: https://issues.jboss.org/browse/WFLY-6990
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Reporter: Guillermo González de Agüero
Assignee: Stuart Douglas
Attachments: security-example-1.0-SNAPSHOT.war
Given the following web.xml
{code:java}
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Unprotected</web-resource-name>
<url-pattern>/</url-pattern>
</web-resource-collection>
</security-constraint>
<security-role>
<role-name>admin</role-name>
</security-role>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Protected area</realm-name>
</login-config>
</web-app>
{code}
A login prompt is expected when accessing /any-page.jsp since "/*" requires the "admin" role. Instead, every page seems to be unprotected, due to the unchecked "/" pattern specified below. Payara/GlassFish and Tomcat show the expected behaviour.
If no role is allowed (<auth-constraint /> for the /*), every page is forbidden as expected.
I've attached a WAR that reproduces the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/23/16 11:53 AM:
-----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
- as well as OSGi problems, I suspect
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
- as well as OSGi problems, I suspect
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
- {{XmlBeans}}
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/23/16 11:52 AM:
-----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
- as well as OSGi problems, I suspect
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
- {{XmlBeans}}
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
- Currently looking at (apache) {{XmlBeans}}
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld commented on DROOLS-355:
---------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
- Currently looking at (apache) {{XmlBeans}}
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld reassigned DROOLS-355:
-------------------------------------
Assignee: Marco Rietveld (was: Petr Široký)
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6989) Java deadlock with IdleRemover thread
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-6989?page=com.atlassian.jira.plugin.... ]
Stefano Maestri reassigned WFLY-6989:
-------------------------------------
Assignee: Stefano Maestri (was: Jesper Pedersen)
> Java deadlock with IdleRemover thread
> -------------------------------------
>
> Key: WFLY-6989
> URL: https://issues.jboss.org/browse/WFLY-6989
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Environment: Java 8 b102 64-bit on Linux
> Using Oracle 12.c with Oracle thin client drivers.
> Reporter: David Rothenberger
> Assignee: Stefano Maestri
>
> We have had two Java deadlock issues involving the IdleRemover thread.
> We are using the following datasource definition:
> Data source definition:
> {code:xml}
> <datasource jndi-name="java:/EntomoNonTxDS" pool-name="EntomoNonTxDS" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@//somehost:1541/somethingelse</connection-url>
> <driver>ojdbc6.jar</driver>
> <pool>
> <max-pool-size>200</max-pool-size>
> <allow-multiple-users>true</allow-multiple-users>
> </pool>
> <timeout>
> <idle-timeout-minutes>5</idle-timeout-minutes>
> </timeout>
> <validation>
> <validate-on-match>true</validate-on-match>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
> </validation>
> </datasource>
> {code}
> The information from Java relevant to the deadlock:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "WorkflowMgr":
> waiting for ownable synchronizer 0x00000002d37eb7f0, (a java.util.concurrent.locks.ReentrantLock$FairSync),
> which is held by "IdleRemover"
> "IdleRemover":
> waiting to lock monitor 0x00007eff4c0a80e8 (object 0x00000002d280e6f0, a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri),
> which is held by "WorkflowMgr"
> "WorkflowMgr":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000002d37eb7f0> (a java.util.concurrent.locks.ReentrantLock$FairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.internalRegisterPool(IdleRemover.java:184)
> at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.registerPool(IdleRemover.java:166)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:184)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306)
> - locked <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:590)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:162)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:73)
> ...
> "IdleRemover":
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.emptyManagedConnectionPool(AbstractPool.java:454)
> - waiting to lock <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1034)
> at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6989) Java deadlock with IdleRemover thread
by David Rothenberger (JIRA)
David Rothenberger created WFLY-6989:
----------------------------------------
Summary: Java deadlock with IdleRemover thread
Key: WFLY-6989
URL: https://issues.jboss.org/browse/WFLY-6989
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.0.0.Final
Environment: Java 8 b102 64-bit on Linux
Using Oracle 12.c with Oracle thin client drivers.
Reporter: David Rothenberger
Assignee: Jesper Pedersen
We have had two Java deadlock issues involving the IdleRemover thread.
We are using the following datasource definition:
Data source definition:
{code:xml}
<datasource jndi-name="java:/EntomoNonTxDS" pool-name="EntomoNonTxDS" enabled="true" use-java-context="true">
<connection-url>jdbc:oracle:thin:@//somehost:1541/somethingelse</connection-url>
<driver>ojdbc6.jar</driver>
<pool>
<max-pool-size>200</max-pool-size>
<allow-multiple-users>true</allow-multiple-users>
</pool>
<timeout>
<idle-timeout-minutes>5</idle-timeout-minutes>
</timeout>
<validation>
<validate-on-match>true</validate-on-match>
<valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
<stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/>
<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
</validation>
</datasource>
{code}
The information from Java relevant to the deadlock:
{noformat}
Found one Java-level deadlock:
=============================
"WorkflowMgr":
waiting for ownable synchronizer 0x00000002d37eb7f0, (a java.util.concurrent.locks.ReentrantLock$FairSync),
which is held by "IdleRemover"
"IdleRemover":
waiting to lock monitor 0x00007eff4c0a80e8 (object 0x00000002d280e6f0, a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri),
which is held by "WorkflowMgr"
"WorkflowMgr":
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000002d37eb7f0> (a java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.internalRegisterPool(IdleRemover.java:184)
at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.registerPool(IdleRemover.java:166)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:184)
at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191)
at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306)
- locked <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:590)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:162)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:73)
...
"IdleRemover":
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.emptyManagedConnectionPool(AbstractPool.java:454)
- waiting to lock <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1034)
at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275)
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)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months