[JBoss JIRA] (WFLY-13335) JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
by Ingo Weiss (Jira)
Ingo Weiss created WFLY-13335:
---------------------------------
Summary: JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
Key: WFLY-13335
URL: https://issues.redhat.com/browse/WFLY-13335
Project: WildFly
Issue Type: Bug
Components: MP JWT
Affects Versions: 19.0.0.Final
Reporter: Ingo Weiss
Assignee: Darran Lofthouse
Fix For: 19.0.1.Final, 20.0.0.Beta1
When starting a Microprofile application utilizing the {{org.eclipse.microprofile.auth.LoginConfig}} annotation, a {{NullPointerException}} is thrown if the annotation does not declare the {{realmName}} property.
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) {} MSC000001: Failed to start service jboss.deployment.unit."example.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."example.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "example.war"
at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
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(Unknown Source)
Caused by: java.lang.NullPointerException
at org.wildfly.extension.microprofile.jwt-smallrye@19.0.0.Final//org.wildfly.extension.microprofile.jwt.smallrye.JwtActivationProcessor.deploy(JwtActivationProcessor.java:80)
at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
... 8 more
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5148) [DMN Designer] Copy/Paste is not working
by Valentino Pellegrino (Jira)
[ https://issues.redhat.com/browse/DROOLS-5148?page=com.atlassian.jira.plug... ]
Valentino Pellegrino reassigned DROOLS-5148:
--------------------------------------------
Assignee: Valentino Pellegrino (was: Daniel José dos Santos)
> [DMN Designer] Copy/Paste is not working
> ----------------------------------------
>
> Key: DROOLS-5148
> URL: https://issues.redhat.com/browse/DROOLS-5148
> Project: Drools
> Issue Type: Bug
> Reporter: Guilherme Gomes
> Assignee: Valentino Pellegrino
> Priority: Major
> Labels: drools-tools
> Attachments: demo.gif
>
>
> Ctrl + C / Ctrl + V is not working on DMN editor. When users try to copy and paste a node, the name and the boxed expression are not copied:
> !demo.gif|width=600!
> h5. Acceptance criteria
> The copy/paste feature must work for text annotations, BKMs, decisions, Inputs, knowledge sources, and decision services.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-12725) ajp huge header
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-12725?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty edited comment on WFLY-12725 at 4/3/20 2:19 AM:
--------------------------------------------------------------------
[~leon.soxuan] Can you provide me the steps to recreate this issue?
was (Author: rchakrab):
[~leon.soxuan] Can you provide me steps to recreate this issue?
> ajp huge header
> ---------------
>
> Key: WFLY-12725
> URL: https://issues.redhat.com/browse/WFLY-12725
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 18.0.0.Final
> Environment: windows7
> Reporter: zai xuan
> Assignee: Flavia Rainone
> Priority: Major
> Labels: headers, long
>
> There are long headers in the AJP connection, resulting in errors.
> ++++++++++++++++++++
> 12:44:37,327 ERROR [io.undertow.request] (default I/O-1) UT005001: An exception
> occurred processing the request: java.lang.ArrayIndexOutOfBoundsException: 16
> at io.undertow.server.protocol.ajp.AjpRequestParser.headers(AjpRequestPa
> rser.java:490)
> at io.undertow.server.protocol.ajp.AjpRequestParser.parseString(AjpReque
> stParser.java:536)
> at io.undertow.server.protocol.ajp.AjpRequestParser.parse(AjpRequestPars
> er.java:353)
> at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
> stener.java:169)
> at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
> stener.java:56)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java
> :92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(R
> eadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> ++++++++++++++++++++
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-12725) ajp huge header
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-12725?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty commented on WFLY-12725:
--------------------------------------------
[~leon.soxuan] Can you provide me steps to recreate this issue?
> ajp huge header
> ---------------
>
> Key: WFLY-12725
> URL: https://issues.redhat.com/browse/WFLY-12725
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 18.0.0.Final
> Environment: windows7
> Reporter: zai xuan
> Assignee: Flavia Rainone
> Priority: Major
> Labels: headers, long
>
> There are long headers in the AJP connection, resulting in errors.
> ++++++++++++++++++++
> 12:44:37,327 ERROR [io.undertow.request] (default I/O-1) UT005001: An exception
> occurred processing the request: java.lang.ArrayIndexOutOfBoundsException: 16
> at io.undertow.server.protocol.ajp.AjpRequestParser.headers(AjpRequestPa
> rser.java:490)
> at io.undertow.server.protocol.ajp.AjpRequestParser.parseString(AjpReque
> stParser.java:536)
> at io.undertow.server.protocol.ajp.AjpRequestParser.parse(AjpRequestPars
> er.java:353)
> at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
> stener.java:169)
> at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
> stener.java:56)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java
> :92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(R
> eadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> ++++++++++++++++++++
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year
by Minal Bhalodi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ]
Minal Bhalodi reopened DROOLS-5180:
-----------------------------------
I added in comments, I am able to reproduce this issue
> Kie-scanner update container API doesn't refresh container with latest jar after new year
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-5180
> URL: https://issues.redhat.com/browse/DROOLS-5180
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.18.0.Final
> Reporter: Minal Bhalodi
> Assignee: Mario Fusco
> Priority: Critical
>
> We are using kie-server as a stand alone application. we use kie scanner to update kie container when there is a new DRL file in our .m2 folder.
> we don't have scanner polling but we use Scanner update container API to update kie container.
> Every year when date changes after new year, we are facing issue where kie scanner is not able to update container with latest jar in m2 with new year date.
> When we check the container version it shows latest with new year date but internally kie is still using old jar.
> We fixed this issue with create container API instead update container.
> kie-server-spring-boot-starter-drools :7.18.0.Final
> Please let me know if this issue is already fixed or discussed before or if you need more details.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year
by Minal Bhalodi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ]
Minal Bhalodi commented on DROOLS-5180:
---------------------------------------
I am able to reproduce this problem.
1)First in .m2 folder first I added jar with version name person-10.23.2019-06-30-00.jar and started kie server.
Kie-server created container with jar version 10.23.2019-06-30-00.
2)While server was running, I added person-10.23.2019-20-30-00.jar and kie container was updated with latest jar. Though I was adding this jar manually in S3, I also updated maven-metadata-local.xml manually to modify release and version with person-10.23.2019-20-30-00.jar
3)Then again without stopping server, I added person-04.02.2020-15-00-04.jar and updated release and version in maven-metadata-local.xml. This time kie server was not updated with version 04.02.2020-15-00-04.
our maven-metadata-local.xml
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId><value></groupId>
<artifactId><value></artifactId>
<versioning>
<release>10.23.2019-20-30-00</release>
<versions>
<version>10.23.2019-06-30-00</version>
<version>04.02.2020-15-00-04</version>
<version>10.23.2019-20-30-00</version>
</versions>
<lastUpdated>1585869333000</lastUpdated>
</versioning>
</metadata>
I don't sample code to reproduce this issue but if you can share a sample code where kie-server updates container in reference to .m2 folder then I might be able to reproudce this issue there
> Kie-scanner update container API doesn't refresh container with latest jar after new year
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-5180
> URL: https://issues.redhat.com/browse/DROOLS-5180
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.18.0.Final
> Reporter: Minal Bhalodi
> Assignee: Mario Fusco
> Priority: Critical
>
> We are using kie-server as a stand alone application. we use kie scanner to update kie container when there is a new DRL file in our .m2 folder.
> we don't have scanner polling but we use Scanner update container API to update kie container.
> Every year when date changes after new year, we are facing issue where kie scanner is not able to update container with latest jar in m2 with new year date.
> When we check the container version it shows latest with new year date but internally kie is still using old jar.
> We fixed this issue with create container API instead update container.
> kie-server-spring-boot-starter-drools :7.18.0.Final
> Please let me know if this issue is already fixed or discussed before or if you need more details.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5212) Latest Drools-compiler version has dependency of xstream-1.4.11.1.jar which causing HIGH vulnerability CVE-2013-7285
by Priti Rane (Jira)
Priti Rane created DROOLS-5212:
----------------------------------
Summary: Latest Drools-compiler version has dependency of xstream-1.4.11.1.jar which causing HIGH vulnerability CVE-2013-7285
Key: DROOLS-5212
URL: https://issues.redhat.com/browse/DROOLS-5212
Project: Drools
Issue Type: Enhancement
Reporter: Priti Rane
Assignee: Mario Fusco
All drools compiler versions after 7.21.0.Final are using xstream version 1.14.11.1. We are using anchore engine for vulnerability scan and it is giving HIGH vulnerability CVE-2013-7285 - https://nvd.nist.gov/vuln/detail/CVE-2013-7285. There is a workaround to implement the security framework. However we are using kie-ci jar which has the drools-compiler dependency. So to resolve this , we have to implement the workaround in drools-compiler source code and build the jar and use it. But this solution is not maintainable.
Is there any plans to implement the security framework in next version of drools-compiler ?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13322) Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13322?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13322:
-----------------------------------------
IMO any further enhancement related to installing a different JSF impl should involve a Galleon feature pack.
^^^ is a very hand-wavy statement but generally our provisioning strategy should be Galleon.
> Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-13322
> URL: https://issues.redhat.com/browse/WFLY-13322
> Project: WildFly
> Issue Type: Enhancement
> Components: JSF
> Reporter: Brad Maxwell
> Assignee: Farah Juma
> Priority: Major
>
> Currently to configure a different JSF Implementation in a module, these steps below are followed:
> 1. $ mkdir -p modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION
> 2. Copy the wildfly-jsf-injection and weld-core-jsf JAR files from EAP_HOME/modules/system/layers/base/org/jboss/as/jsf-injection/main/ to the modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION/ subdirectory.
> For initial setup, the jars that need to be copied may be from modules/system/layers/base/org/jboss/as/jsf-injection/main or if an Update is applied, then it should be from the latest dir of the form system/layers/base/.overlays/layer-base-jboss-eap-7.2.z.CP/org/jboss/as/jsf-injection/main
> After a new Update, if a bug gets fixed in the jars, then the user needs to copy the updated jars into their custom module.
> It would be better if the user can just create a module with their jars and depend on the org/jboss/as/jsf-injection module and then the JSF subsystem make it work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months