[JBoss JIRA] (WFLY-12683) Exception with web.xml url-pattern
by James Perkins (Jira)
James Perkins created WFLY-12683:
------------------------------------
Summary: Exception with web.xml url-pattern
Key: WFLY-12683
URL: https://issues.jboss.org/browse/WFLY-12683
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 18.0.0.Final
Reporter: Frank Heldt
Assignee: Flavia Rainone
Defining and securing 2 folders in a war with similar names given this Exception on deployment:
{code}
12:38:37,994 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: org.jboss.msc.service.StartException in service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: WFLYSEC0012: Unable to start the JaccService service
at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:107)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.IllegalArgumentException: Invalid prefix pattern in URLPatternList
at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:308)
at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:160)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:303)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:64)
at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:86)
... 8 more
{code}
This is the corresponding part of the web.xml:
{code}
<security-constraint>
<web-resource-collection>
<web-resource-name>Area</web-resource-name>
<url-pattern>/area/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>role1</role-name>
<role-name>role2</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Area 51</web-resource-name>
<url-pattern>/area51/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>role1</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
{code}
Looks like this only happens when the url-pattern starts with the same characters (eg /area/* and /area51/*).
The same war under WildFly 17.0.1 works as expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4658) Executable model compilation fails with ClassCastException when using accumulate and additional constraint
by Martin Weiler (Jira)
[ https://issues.jboss.org/browse/DROOLS-4658?page=com.atlassian.jira.plugi... ]
Martin Weiler updated DROOLS-4658:
----------------------------------
Git Pull Request: https://github.com/kiegroup/drools/pull/2596
> Executable model compilation fails with ClassCastException when using accumulate and additional constraint
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4658
> URL: https://issues.jboss.org/browse/DROOLS-4658
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.28.0.Final
> Reporter: Martin Weiler
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
>
> A rule containing the following constraint:
> {noformat}
> when
> $customer : Customer( code == "RHT" )
> $max1 : Number() from accumulate(
> StockTick( company == $customer.code
> , $time : dueDate);
> max($time.getTime().getTime()))
> {noformat}
> fails with a ClassCastException when building with the executable model:
> {noformat}
> java.lang.ClassCastException: com.github.javaparser.ast.expr.NameExpr cannot be cast to com.github.javaparser.ast.expr.LambdaExpr
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$composeTwoBindings$4(AccumulateVisitorPatternDSL.java:67)
> at java.util.Optional.ifPresent(Optional.java:159)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.composeTwoBindings(AccumulateVisitorPatternDSL.java:64)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$null$1(AccumulateVisitorPatternDSL.java:53)
> at java.util.Optional.ifPresent(Optional.java:159)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$processNewBinding$3(AccumulateVisitorPatternDSL.java:53)
> at java.util.Optional.ifPresent(Optional.java:159)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.processNewBinding(AccumulateVisitorPatternDSL.java:44)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.classicAccumulate(AccumulateVisitor.java:129)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.visit(AccumulateVisitor.java:107)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:122)
> at org.drools.compiler.lang.descr.PatternDescr.accept(PatternDescr.java:272)
> at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit(AndVisitor.java:29)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:69)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule(ModelGenerator.java:176)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel(ModelGenerator.java:156)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages(ModelBuilderImpl.java:176)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules(ModelBuilderImpl.java:121)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildPackages(ModelBuilderImpl.java:71)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:108)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4658) Executable model compilation fails with ClassCastException when using accumulate and additional constraint
by Martin Weiler (Jira)
Martin Weiler created DROOLS-4658:
-------------------------------------
Summary: Executable model compilation fails with ClassCastException when using accumulate and additional constraint
Key: DROOLS-4658
URL: https://issues.jboss.org/browse/DROOLS-4658
Project: Drools
Issue Type: Bug
Components: core engine, executable model
Affects Versions: 7.28.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
A rule containing the following constraint:
{noformat}
when
$customer : Customer( code == "RHT" )
$max1 : Number() from accumulate(
StockTick( company == $customer.code
, $time : dueDate);
max($time.getTime().getTime()))
{noformat}
fails with a ClassCastException when building with the executable model:
{noformat}
java.lang.ClassCastException: com.github.javaparser.ast.expr.NameExpr cannot be cast to com.github.javaparser.ast.expr.LambdaExpr
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$composeTwoBindings$4(AccumulateVisitorPatternDSL.java:67)
at java.util.Optional.ifPresent(Optional.java:159)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.composeTwoBindings(AccumulateVisitorPatternDSL.java:64)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$null$1(AccumulateVisitorPatternDSL.java:53)
at java.util.Optional.ifPresent(Optional.java:159)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$processNewBinding$3(AccumulateVisitorPatternDSL.java:53)
at java.util.Optional.ifPresent(Optional.java:159)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.processNewBinding(AccumulateVisitorPatternDSL.java:44)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.classicAccumulate(AccumulateVisitor.java:129)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.visit(AccumulateVisitor.java:107)
at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:122)
at org.drools.compiler.lang.descr.PatternDescr.accept(PatternDescr.java:272)
at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit(AndVisitor.java:29)
at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:69)
at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule(ModelGenerator.java:176)
at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel(ModelGenerator.java:156)
at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages(ModelBuilderImpl.java:176)
at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules(ModelBuilderImpl.java:121)
at org.drools.modelcompiler.builder.ModelBuilderImpl.buildPackages(ModelBuilderImpl.java:71)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:108)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4659) Executable model compilation fails with ClassCastException when using accumulate and additional constraint
by Martin Weiler (Jira)
Martin Weiler created DROOLS-4659:
-------------------------------------
Summary: Executable model compilation fails with ClassCastException when using accumulate and additional constraint
Key: DROOLS-4659
URL: https://issues.jboss.org/browse/DROOLS-4659
Project: Drools
Issue Type: Bug
Components: core engine, executable model
Affects Versions: 7.28.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
A rule containing the following constraint:
{noformat}
when
$customer : Customer( code == "RHT" )
$max1 : Number() from accumulate(
StockTick( company == $customer.code
, $time : dueDate);
max($time.getTime().getTime()))
{noformat}
fails with a ClassCastException when building with the executable model:
{noformat}
java.lang.ClassCastException: com.github.javaparser.ast.expr.NameExpr cannot be cast to com.github.javaparser.ast.expr.LambdaExpr
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$composeTwoBindings$4(AccumulateVisitorPatternDSL.java:67)
at java.util.Optional.ifPresent(Optional.java:159)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.composeTwoBindings(AccumulateVisitorPatternDSL.java:64)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$null$1(AccumulateVisitorPatternDSL.java:53)
at java.util.Optional.ifPresent(Optional.java:159)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.lambda$processNewBinding$3(AccumulateVisitorPatternDSL.java:53)
at java.util.Optional.ifPresent(Optional.java:159)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitorPatternDSL.processNewBinding(AccumulateVisitorPatternDSL.java:44)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.classicAccumulate(AccumulateVisitor.java:129)
at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.visit(AccumulateVisitor.java:107)
at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:122)
at org.drools.compiler.lang.descr.PatternDescr.accept(PatternDescr.java:272)
at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit(AndVisitor.java:29)
at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:69)
at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule(ModelGenerator.java:176)
at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel(ModelGenerator.java:156)
at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages(ModelBuilderImpl.java:176)
at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules(ModelBuilderImpl.java:121)
at org.drools.modelcompiler.builder.ModelBuilderImpl.buildPackages(ModelBuilderImpl.java:71)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:108)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12655) Exception with web.xml url-pattern
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12655?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12655:
---------------------------------
Description:
Defining and securing 2 folders in a war with similar names given this Exception on deployment:
{code}
12:38:37,994 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: org.jboss.msc.service.StartException in service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: WFLYSEC0012: Unable to start the JaccService service
at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:107)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.IllegalArgumentException: Invalid prefix pattern in URLPatternList
at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:308)
at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:160)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:303)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:64)
at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:86)
... 8 more
{code}
This is the corresponding part of the web.xml:
{code}
<security-constraint>
<web-resource-collection>
<web-resource-name>Area</web-resource-name>
<url-pattern>/area/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>role1</role-name>
<role-name>role2</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Area 51</web-resource-name>
<url-pattern>/area51/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>role1</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
{code}
Looks like this only happens when the url-pattern starts with the same characters (eg /area/* and /area51/*).
The same war under WildFly 17.0.1 works as expected.
was:
Defining and securing 2 folders in a war with similar names given this Exception on deployment:
12:38:37,994 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: org.jboss.msc.service.StartException in service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: WFLYSEC0012: Unable to start the JaccService service
at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:107)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.IllegalArgumentException: Invalid prefix pattern in URLPatternList
at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:308)
at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:160)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:303)
at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:64)
at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:86)
... 8 more
This is the corresponding part of the web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>Area</web-resource-name>
<url-pattern>/area/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>role1</role-name>
<role-name>role2</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Area 51</web-resource-name>
<url-pattern>/area51/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>role1</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Looks like this only happens when the url-pattern starts with the same characters (eg /area/* and /area51/*).
The same war under WildFly 17.0.1 works as expected.
> Exception with web.xml url-pattern
> ----------------------------------
>
> Key: WFLY-12655
> URL: https://issues.jboss.org/browse/WFLY-12655
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 18.0.0.Final
> Reporter: Frank Heldt
> Assignee: Flavia Rainone
> Priority: Major
>
> Defining and securing 2 folders in a war with similar names given this Exception on deployment:
> {code}
> 12:38:37,994 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: org.jboss.msc.service.StartException in service jboss.deployment.unit."java-web-project.war".jboss.security.jacc: WFLYSEC0012: Unable to start the JaccService service
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:107)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: Invalid prefix pattern in URLPatternList
> at javax.security.jacc.api@2.0.0.Final//javax.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:308)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
> at javax.security.jacc.api(a)2.0.0.Final//javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:160)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:303)
> at org.wildfly.extension.undertow@18.0.0.Final//org.wildfly.extension.undertow.security.jacc.WarJACCService.createPermissions(WarJACCService.java:64)
> at org.jboss.as.security@18.0.0.Final//org.jboss.as.security.service.JaccService.start(JaccService.java:86)
> ... 8 more
> {code}
> This is the corresponding part of the web.xml:
> {code}
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area</web-resource-name>
> <url-pattern>/area/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> <role-name>role2</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Area 51</web-resource-name>
> <url-pattern>/area51/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>role1</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> {code}
> Looks like this only happens when the url-pattern starts with the same characters (eg /area/* and /area51/*).
> The same war under WildFly 17.0.1 works as expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Flavia Rainone reassigned WFWIP-160:
------------------------------------
Assignee: Richard Opalka (was: Flavia Rainone)
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months