January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14288) Smallrye-JWT MP-Config-Property Resolution within EARs or Multideployments

by Tran Minh Do (Jira)

Tran Minh Do created WFLY-14288: ----------------------------------- Summary: Smallrye-JWT MP-Config-Property Resolution within EARs or Multideployments Key: WFLY-14288 URL: https://issues.redhat.com/browse/WFLY-14288 Project: WildFly Issue Type: Feature Request Affects Versions: 22.0.0.Beta1, 19.1.0.Final Reporter: Tran Minh Do Assignee: Brian Stansberry h1. Summary Using MP-JWT in one of multiple WARs disables all other WARs h2. Details Multi-War Example Layout {code:java} wildfly L war1 L microprofile-config.properties L public.pem L war2 {code} EAR Example Layout {code:java} wildfly L ear L war1 L microprofile-config.properties L public.pem L war2{code} *{{war1}}* is configured to use *{{smallrye-jwt}}* via *{{@LoginConfig}}* and it is working by defining the properties *{{mp.jwt.verify.publickey.location}}* and *{{mp.jwt.verify.issuer}}*. If *{{war2}}* is accessed an exception is thrown for missing said properties. {code:java} ERROR \[io.undertow.request\] (default task-1) UT005023: Exception handling request to /war2/: java.lang.IllegalStateException: JWTAuthContextInfo has not been initialized. Please make sure that either 'mp.jwt.verify.publickey' or 'mp.jwt.verify.publickey.location' properties are set. at io.smallrye.jwt//io.smallrye.jwt.config.JWTAuthContextInfoProvider.lambda$throwException$0(JWTAuthContextInfoProvider.java:430) {code} Original Issue on Smallrye Github https://github.com/smallrye/smallrye-jwt/issues/360 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5932) NullPointerException at NativeJavaCompiler when using JRE

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5932?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5932: -------------------------------------- Description: If you use JRE instead of JDK, ToolProvider.getSystemJavaCompiler() returns null and will result in NPE later. https://github.com/kiegroup/drools/blob/996e8f40dec9f25650dfb0457eb09bad3... Probably should add a null check and throw an error message, something like "Cannot perform native java compilation: could not find the System's Java compiler. Maybe install a JDK?" FYI) https://groups.google.com/g/optaplanner-dev/c/2UkiCjPua5w/m/BebSTW0zCAAJ https://stackoverflow.com/questions/2543439/null-pointer-exception-while-... https://stackoverflow.com/questions/65682295/course-timetabling-and-confe... was: If you use JRE instead of JDK, ToolProvider.getSystemJavaCompiler() returns null and will result in NPE later. https://github.com/kiegroup/drools/blob/996e8f40dec9f25650dfb0457eb09bad3... Probably should add a null check and throw an error message, something like "Cannot perform native java compilation: could not find the System's Java compiler. Maybe install a JDK?" FYI) https://groups.google.com/g/optaplanner-dev/c/2UkiCjPua5w/m/BebSTW0zCAAJ https://stackoverflow.com/questions/2543439/null-pointer-exception-while-... > NullPointerException at NativeJavaCompiler when using JRE > ---------------------------------------------------------- > > Key: DROOLS-5932 > URL: https://issues.redhat.com/browse/DROOLS-5932 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.48.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > If you use JRE instead of JDK, ToolProvider.getSystemJavaCompiler() returns null and will result in NPE later. > https://github.com/kiegroup/drools/blob/996e8f40dec9f25650dfb0457eb09bad3... > Probably should add a null check and throw an error message, something like "Cannot perform native java compilation: could not find the System's Java compiler. Maybe install a JDK?" > FYI) > https://groups.google.com/g/optaplanner-dev/c/2UkiCjPua5w/m/BebSTW0zCAAJ > https://stackoverflow.com/questions/2543439/null-pointer-exception-while-... > https://stackoverflow.com/questions/65682295/course-timetabling-and-confe... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5198) Ignore Eclipse Transformer transformation failures caused by duplicate class files in input archive

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-5198?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-5198: ------------------------------------- Issue Type: Enhancement (was: Feature Request) > Ignore Eclipse Transformer transformation failures caused by duplicate class files in input archive > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-5198 > URL: https://issues.redhat.com/browse/WFCORE-5198 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > Labels: EE9 > Fix For: 14.0.0.Beta4, 14.0.0.Final > > > See https://issues.redhat.com/browse/WFLY-14014 + https://github.com/wildfly/wildfly-core/pull/4392 for more details. > The idea is to handle the following failure during bytecode transformation which doesn't support duplicate classes currently. We will use untransformed application content: > {code} > 2020-10-23 14:40:42,445 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "servlet_plu_singlethreadmodel_web.war")]): java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: Error occured during transformation. Error code 3 > at org.wildfly.galleon.plugin.transformer.BataviaTransformer.transform(BataviaTransformer.java:55) > at org.wildfly.galleon.plugin.transformer.JakartaTransformer.transform(JakartaTransformer.java:98) > at org.wildfly.ee8to9.transformer.DeploymentTransformer.transform(DeploymentTransformer.java:40) > at org.jboss.as.server.deployment.DeploymentAddHandler.addFromContentAdditionParameter(DeploymentAddHandler.java:220) > at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:137) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:1005) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:744) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:468) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1415) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:431) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:248) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:304) [wildfly-elytron-auth-server-1.13.1.Final.jar:1.13.1.Final] > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270) [wildfly-elytron-auth-server-1.13.1.Final.jar:1.13.1.Final] > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:248) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient.executeInModelControllerCl(ModelControllerClientFactoryImpl.java:259) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient.lambda$runOperation$0(ModelControllerClientFactoryImpl.java:249) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:63) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.SecurityActions$InVmActions$2.lambda$runInVm$0(SecurityActions.java:162) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_191] > at org.jboss.as.controller.SecurityActions$InVmActions$2.runInVm(SecurityActions.java:162) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.SecurityActions.runInVm(SecurityActions.java:49) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient.runOperation(ModelControllerClientFactoryImpl.java:249) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient.access$600(ModelControllerClientFactoryImpl.java:114) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient$2.run(ModelControllerClientFactoryImpl.java:203) [wildfly-controller-14.0.0.Beta1.jar:14.0.0.Beta1] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_191] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_191] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_191] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_191] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_191] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_191] > at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_191] > at org.jboss.threads.JBossThread.run(JBossThread.java:513) [jboss-threads-2.4.0.Final.jar:2.4.0.Final] > Caused by: java.lang.RuntimeException: java.io.IOException: Error occured during transformation. Error code 3 > at org.wildfly.extras.transformer.eclipse.ArchiveTransformerImpl.transform(ArchiveTransformerImpl.java:98) > at org.wildfly.galleon.plugin.transformer.BataviaTransformer.transform(BataviaTransformer.java:65) > at org.wildfly.galleon.plugin.transformer.BataviaTransformer.transform(BataviaTransformer.java:40) > ... 31 more > Caused by: java.io.IOException: Error occured during transformation. Error code 3 > at org.wildfly.extras.transformer.eclipse.ArchiveTransformerImpl.transform(ArchiveTransformerImpl.java:117) > at org.wildfly.extras.transformer.eclipse.ArchiveTransformerImpl.transform(ArchiveTransformerImpl.java:96) > ... 33 more > 2020-10-23 14:40:52,491 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) WFLYDS0004: Found servlet_plu_srattributeevent_web.war in deployment directory. To trigger deployment create a file called servlet_plu_srattributeevent_web.war.dodeploy > 2 > {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14287) NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable

by Radoslav Ivanov (Jira)

Radoslav Ivanov created WFLY-14287: -------------------------------------- Summary: NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable Key: WFLY-14287 URL: https://issues.redhat.com/browse/WFLY-14287 Project: WildFly Issue Type: Bug Affects Versions: 21.0.1.Final Reporter: Radoslav Ivanov Assignee: Brian Stansberry Could you please add missing dependencies in Bouncycastle modules? Problem (we got): {code:java} Caused by: java.lang.NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList (Module "org.bouncycastle.bcpg" version 1.66.00.0 from local module loader @1d1f7216 (finder: local module finder @423e4cbb (roots: /data/avoka/transact/manager/server/modules,/data/avoka/transact/manager/server/modules/system/layers/base))): org/bouncycastle/util/Iterable {code} Solution (adding dependency from bcpg to bcprov modules solves the issue): {code:java} modules\system\layers\base\org\bouncycastle\bcpg\main\module.xml{code} {code:java} <dependencies> <module name="org.bouncycastle.bcprov" export="true" services="export"/> </dependencies> {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2069) JWT token validation uses int instead of long for the dates: exp (expiration) and nbf

by Chris Dolphy (Jira)

[ https://issues.redhat.com/browse/ELY-2069?page=com.atlassian.jira.plugin.... ] Chris Dolphy updated ELY-2069: ------------------------------ Description: JwtValidator is reading the exp and nbf field as a Java int instead of long: [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. was: JwtValidator is reading the exp field as a Java int instead of long: [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. > JWT token validation uses int instead of long for the dates: exp (expiration) and nbf > ------------------------------------------------------------------------------------- > > Key: ELY-2069 > URL: https://issues.redhat.com/browse/ELY-2069 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Chris Dolphy > Assignee: Darran Lofthouse > Priority: Major > > JwtValidator is reading the exp and nbf field as a Java int instead of long: > [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] > This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2069) JWT token validation uses int instead of long for the dates: exp (expiration) and nbf

by Chris Dolphy (Jira)

[ https://issues.redhat.com/browse/ELY-2069?page=com.atlassian.jira.plugin.... ] Chris Dolphy updated ELY-2069: ------------------------------ Summary: JWT token validation uses int instead of long for the dates: exp (expiration) and nbf (was: JWT token validation uses int instead of long for the expiration (exp) value) > JWT token validation uses int instead of long for the dates: exp (expiration) and nbf > ------------------------------------------------------------------------------------- > > Key: ELY-2069 > URL: https://issues.redhat.com/browse/ELY-2069 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Chris Dolphy > Assignee: Darran Lofthouse > Priority: Major > > JwtValidator is reading the exp field as a Java int instead of long: > [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] > This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2069) JWT token validation uses int instead of long for the expiration (exp) value

by Chris Dolphy (Jira)

Chris Dolphy created ELY-2069: --------------------------------- Summary: JWT token validation uses int instead of long for the expiration (exp) value Key: ELY-2069 URL: https://issues.redhat.com/browse/ELY-2069 Project: WildFly Elytron Issue Type: Feature Request Reporter: Chris Dolphy Assignee: Darran Lofthouse JwtValidator is reading the exp field as a Java int instead of long: [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14286) Infinispan should enable JMX registration when jmx capability is present

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14286?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14286: -------------------------------- Summary: Infinispan should enable JMX registration when jmx capability is present (was: Infinispan should enable JMX registration when statistics-enabled=true and jmx capability is present) > Infinispan should enable JMX registration when jmx capability is present > ------------------------------------------------------------------------ > > Key: WFLY-14286 > URL: https://issues.redhat.com/browse/WFLY-14286 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.1.Final, 21.0.2.Final, 22.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14286) Infinispan should enable JMX registration when statistics-enabled=true and jmx capability is present

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-14286: ----------------------------------- Summary: Infinispan should enable JMX registration when statistics-enabled=true and jmx capability is present Key: WFLY-14286 URL: https://issues.redhat.com/browse/WFLY-14286 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 22.0.0.Beta1, 21.0.2.Final, 20.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14189) The RunAs annotation doesn't work in EJBs with Elytron

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14189?page=com.atlassian.jira.plugi... ] Brian Stansberry closed WFLY-14189. ----------------------------------- > The RunAs annotation doesn't work in EJBs with Elytron > ------------------------------------------------------ > > Key: WFLY-14189 > URL: https://issues.redhat.com/browse/WFLY-14189 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 21.0.0.Final > Reporter: Alessandro Moscatelli > Assignee: Diana Vilkolakova > Priority: Major > Labels: ejb, elytron, regression, runas, security, startup > Attachments: standalone-full-ha.new.xml, test.zip > > > Role is not correctly assigned when using @RunAs annotation and Elytron Security Domain. Everything works correctly with legacy picketbox Security Domain. > Wildfly is configured to use default "other" application-security-domain, also using default security domain ApplicationDomain. > This exception is rised when deploying the application. > Caused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowedCaused by: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract void org.visiontech.test.TestInterface.test() of bean: Test2 is not allowed at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.security.JaccInterceptor.hasPermission(JaccInterceptor.java:120) > Test/Sample project: [^test.zip] -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2021