April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11565) WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-11565?page=com.atlassian.jira.plugi... ] Bartosz Baranowski resolved WFLY-11565. --------------------------------------- Resolution: Out of Date > WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204 > ------------------------------------------------------------------------------------------- > > Key: WFLY-11565 > URL: https://issues.redhat.com/browse/WFLY-11565 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.0.Final > Reporter: Deepak Sahu > Assignee: Bartosz Baranowski > Priority: Major > Attachments: API.war > > > I am using WildFly Server 9.0.0 Final, Javax ws, Jersey for developing Rest APIs. For all the responses whose httpStatus code is 204, the wildfly server adds Transfer encoding Chunked in the response header, which is not correct as per the Rest Standards. Because of this behavior some of the RestAPI clients hang, as they keep waiting for the response (which is not at all there). > To verify the issue, I tried the same with Springboot instead of deploying the war in WildFly and the Response Header was not added with Transfer Encoding Chuncked. > Let me know if some other information is required to fix this issue, if this is already fixed is there any patch for this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5198) Infinite loop induced by backward chaining

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5198?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5198: -------------------------------- Sprint: (was: 2020 Week 13-15 (from Mar 23)) > Infinite loop induced by backward chaining > ------------------------------------------ > > Key: DROOLS-5198 > URL: https://issues.redhat.com/browse/DROOLS-5198 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.34.0.Final > Reporter: Ivan Zilotti > Assignee: Mario Fusco > Priority: Major > > I could not find an out-of-the-box mechanism in Drools for stopping loops induced by backward chaining. I've found some research e.g., [Avoiding Infinite Loops in Rule-Based Systems with Backward Chaining|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.38.8356...], indicating this is a recurring problem. > When undeterred, these loops cause an OutOfMemoryError. > I've already tried to: > * Find configuration options in Drools to limit the behavior, but apparently there are't any; > * Step through the code, trying to find ways to break the recursive behavior; > * Change my rules to check for possible loops but that resulted either in partial facts being added to working memory (WM) or computationally expensive logic. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5213) OOPath: cannot use ! in constraint with a boolean function

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5213?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5213: -------------------------------- Sprint: 2020 Week 13-15 (from Mar 23) > OOPath: cannot use ! in constraint with a boolean function > ---------------------------------------------------------- > > Key: DROOLS-5213 > URL: https://issues.redhat.com/browse/DROOLS-5213 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Edoardo Vacchi > Assignee: Mario Fusco > Priority: Major > Labels: drools-core > > reproducer: > https://github.com/evacchi/kogito-examples/blob/oopath-bug-not/onboarding... > build the subproject -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-5180. --------------------------------- Resolution: Explained Your versioning scheme breaks the lexicographic order. To clarify, in your example the version number {code} 10.23.2019-06-30-00 {code} comes lexicographically AFTER than {code} 04.02.2020-15-00-04 {code} and that's why maven (and then the kie-server) doesn't recognize the second as a newer version. If you want to use the date as version number use the format YYYY.MM.DD instead of the current DD.MM.YYYY and this should fix the problem. > 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)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13336) Add a "Smoke" JWT test case to use as a basis for further tests.

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13336: --------------------------------- Summary: Add a "Smoke" JWT test case to use as a basis for further tests. Key: WFLY-13336 URL: https://issues.redhat.com/browse/WFLY-13336 Project: WildFly Issue Type: Task Components: MP JWT, Test Suite Reporter: Ingo Weiss Assignee: Darran Lofthouse Fix For: 19.0.1.Final, 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[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)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5213) OOPath: cannot use ! in constraint with a boolean function

by Edoardo Vacchi (Jira)

Edoardo Vacchi created DROOLS-5213: -------------------------------------- Summary: OOPath: cannot use ! in constraint with a boolean function Key: DROOLS-5213 URL: https://issues.redhat.com/browse/DROOLS-5213 Project: Drools Issue Type: Bug Components: core engine Reporter: Edoardo Vacchi Assignee: Mario Fusco reproducer: https://github.com/evacchi/kogito-examples/blob/oopath-bug-not/onboarding... build the subproject -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[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)

6 years, 3 months

1
0
0 / 0

[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)

6 years, 3 months

1
0
0 / 0

[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)

6 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 April 2020