May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5341) ExecutionResultImpl not properly serialized in JSon Response

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5341?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5341: -------------------------------- Sprint: 2020 Week 19-21 (from May 4) > ExecutionResultImpl not properly serialized in JSon Response > ------------------------------------------------------------ > > Key: DROOLS-5341 > URL: https://issues.redhat.com/browse/DROOLS-5341 > Project: Drools > Issue Type: Bug > Affects Versions: 7.29.0.Final > Reporter: Steve Davidson > Assignee: Mario Fusco > Priority: Major > Labels: drools, kie, kie-server > Attachments: KieIssueDemo.tbz > > > When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "ExecutionResultImpl" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} > This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "execution-results" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13426) Optimize marshalling in clustering subsystems using ProtoStream

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13426?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13426: ----------------------------------------- [~pferraro] In the case of arbitrary application types how does this work? Is it expected that applications will provide .proto files and/or use the protostream annotations? So, essentially an opt-in kind of thing? > Optimize marshalling in clustering subsystems using ProtoStream > --------------------------------------------------------------- > > Key: WFLY-13426 > URL: https://issues.redhat.com/browse/WFLY-13426 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 19.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Currently, WildFly uses JBoss Marshalling to marshal user objects (session attributes, SFSB instances) for the purposes of replication and persistence. > Protostream (developed by the Infinispan team) offers several advantages over JBoss Marshalling. > * Lower memory footprint (marshalling schemas are built during compilation time) > ** Marshalling is granular, thus avoiding lots of large buffer copying > * Faster marshalling - as it does not rely on reflection > * Produces generally smaller replication payloads (see https://docs.google.com/spreadsheets/d/1f6FlXqxX7dYm44naHZfqLc5TjqlmscIdG... ) > * Resolves security concerns due to JBM's reliance on reflection and Java serialization inherently permitting arbitrary execution of rogue code > * JBoss Marshalling is effectively in maintenance mode -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13481) Upgrade wildfly-transaction-client to 1.1.12.Final

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-13481?page=com.atlassian.jira.plugi... ] Tomasz Adamski updated WFLY-13481: ---------------------------------- Description: Release diff: https://github.com/wildfly/wildfly-transaction-client/compare/1.1.11.Fina... > Upgrade wildfly-transaction-client to 1.1.12.Final > -------------------------------------------------- > > Key: WFLY-13481 > URL: https://issues.redhat.com/browse/WFLY-13481 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB, Transactions > Affects Versions: 19.1.0.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Priority: Critical > > Release diff: https://github.com/wildfly/wildfly-transaction-client/compare/1.1.11.Fina... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13481) Upgrade wildfly-transaction-client to 1.1.12.Final

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-13481: ------------------------------------- Summary: Upgrade wildfly-transaction-client to 1.1.12.Final Key: WFLY-13481 URL: https://issues.redhat.com/browse/WFLY-13481 Project: WildFly Issue Type: Component Upgrade Components: EJB, Transactions Affects Versions: 19.1.0.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13386) Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13386?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13386: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/13285 (was: https://github.com/wildfly/wildfly/pull/13222) > Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' " > ---------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13386 > URL: https://issues.redhat.com/browse/WFLY-13386 > Project: WildFly > Issue Type: Bug > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Priority: Major > Fix For: 20.0.0.Beta1 > > > When a timer is reloaded for the first time in other node there are no listeners attached to it causing this problem (only in cluster environments with db timers) > {code} > 2020-04-15 16:43:57,733 WARN [org.jboss.as.ejb3.timer] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=33170e5f-3b34-4503-8796-9b5e6871c074) from its persistent state: java.lang.NullPointerException > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:851) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13447) Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13447?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13447: --------------------------------------- Fix Version/s: 20.0.0.Beta1 Assignee: Masafumi Miura (was: Flavia Rainone) Resolution: Done > Undertow request failure happens due to "IllegalArgumentException: Comparison method violates its general contract!" when many filter-ref are defined > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13447 > URL: https://issues.redhat.com/browse/WFLY-13447 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 19.1.0.Final > Reporter: Masafumi Miura > Assignee: Masafumi Miura > Priority: Major > Fix For: 20.0.0.Beta1 > > Attachments: generate-cli.sh, test.cli > > > When many filter-ref are defined (theoretically more than 32 filter-ref are defined), Undertow has a possibility fail to process a request with the following ERROR: > {code} > ERROR [io.undertow.request] (default I/O-12) UT005071: Undertow request failed HttpServerExchange{ GET /}: java.lang.IllegalArgumentException: Comparison method violates its general contract! > at java.util.TimSort.mergeLo(TimSort.java:777) > at java.util.TimSort.mergeAt(TimSort.java:514) > at java.util.TimSort.mergeCollapse(TimSort.java:441) > at java.util.TimSort.sort(TimSort.java:245) > at java.util.Arrays.sort(Arrays.java:1512) > at java.util.ArrayList.sort(ArrayList.java:1462) > at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:93) > at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:174) > at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:263) > at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:430) > at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54) > at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78) > at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49) > at org.wildfly.extension.undertow.Server$DefaultHostHandler.handleRequest(Server.java:190) > at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211) > at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:102) > at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370) > at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255) > at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) > {code} > The IllegalArgumentException happens when Java's TimSort algorithm happens to detect inconsistency in the comparison. This happens because [the comparator implementation for sorting filter-ref|https://github.com/wildfly/wildfly/blob/19.1.0.Final/undertow/...] does not follow the contract for comparison. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5341) ExecutionResultImpl not properly serialized in JSon Response

by Steve Davidson (Jira)

[ https://issues.redhat.com/browse/DROOLS-5341?page=com.atlassian.jira.plug... ] Steve Davidson commented on DROOLS-5341: ---------------------------------------- MIght be related to DROOLS-5309 > ExecutionResultImpl not properly serialized in JSon Response > ------------------------------------------------------------ > > Key: DROOLS-5341 > URL: https://issues.redhat.com/browse/DROOLS-5341 > Project: Drools > Issue Type: Bug > Affects Versions: 7.29.0.Final > Reporter: Steve Davidson > Assignee: Mario Fusco > Priority: Major > Labels: drools, kie, kie-server > Attachments: KieIssueDemo.tbz > > > When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "ExecutionResultImpl" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} > This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "execution-results" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13256) Upgrade bouncycastle to 1.65.0

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13256?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13256: ----------------------------------------- [~aabdelsa] Can you send up a PR with the upgrade and the TS changes we've talked about? You, me, [~jim.ma], [~dlofthouse] can decide whether to merge the PR but it's better to have it so we can put it in 20.0.0.Beta1 if we want it. > Upgrade bouncycastle to 1.65.0 > ------------------------------ > > Key: WFLY-13256 > URL: https://issues.redhat.com/browse/WFLY-13256 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Server > Reporter: Bartosz Spyrko-Smietanko > Assignee: Brian Stansberry > Priority: Blocker > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > Attachments: handshake-error.log, handshake-success.log > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12510) Update usages of wildfly-credential-reference_1_0.xsd to the new wildfly-credential-reference_1_1.xsd for new schemas

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12510?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-12510: --------------------------------------- Assignee: Farah Juma (was: Jeff Mesnil) Resolution: Done I believe this is done. > Update usages of wildfly-credential-reference_1_0.xsd to the new wildfly-credential-reference_1_1.xsd for new schemas > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12510 > URL: https://issues.redhat.com/browse/WFLY-12510 > Project: WildFly > Issue Type: Task > Components: Management > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > Fix For: 20.0.0.Beta1 > > > With WFCORE-4150, the WildFly Core's urn:jboss:domain:13.0 namespace now references wildfly-credential-reference_1_1.xsd. > WildFly full tests that any schemas that we shipped is up to date with the latest urn:jboss:domain:13.0 namespace in StandardConfigsXMLValidationUnitTestCase tests. > However when this test resolves urn:jboss:domain:13.0, it also resolve urn:wildfly:credential-reference:1.1 and then the test fails because subsystems schemas that references urn:wildfly:credential-reference:1.0 are incorrectly considered not updated. > Released schemas must not be updated with urn:wildfly:credential-reference:1.1 as they are already out in the open. > However every new schemas that will be released with WildFly 20 must ensure that they will updated their references from urn:wildfly:credential-reference:1.0 to urn:wildfly:credential-reference:1.1. > I'll create separate WFLY issues for each involved component as they may update their schemas at different time during the development of WildFly 20. > There is no need to update the schema just for this reference change but if the schema is updated for another reason, then the reference to urn:wildfly:credential-reference MUST be updated -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12510) Update usages of wildfly-credential-reference_1_0.xsd to the new wildfly-credential-reference_1_1.xsd for new schemas

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12510?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-12510: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/12538 (was: https://github.com/wildfly/wildfly/pull/13204) > Update usages of wildfly-credential-reference_1_0.xsd to the new wildfly-credential-reference_1_1.xsd for new schemas > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12510 > URL: https://issues.redhat.com/browse/WFLY-12510 > Project: WildFly > Issue Type: Task > Components: Management > Reporter: Farah Juma > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 20.0.0.Beta1 > > > With WFCORE-4150, the WildFly Core's urn:jboss:domain:13.0 namespace now references wildfly-credential-reference_1_1.xsd. > WildFly full tests that any schemas that we shipped is up to date with the latest urn:jboss:domain:13.0 namespace in StandardConfigsXMLValidationUnitTestCase tests. > However when this test resolves urn:jboss:domain:13.0, it also resolve urn:wildfly:credential-reference:1.1 and then the test fails because subsystems schemas that references urn:wildfly:credential-reference:1.0 are incorrectly considered not updated. > Released schemas must not be updated with urn:wildfly:credential-reference:1.1 as they are already out in the open. > However every new schemas that will be released with WildFly 20 must ensure that they will updated their references from urn:wildfly:credential-reference:1.0 to urn:wildfly:credential-reference:1.1. > I'll create separate WFLY issues for each involved component as they may update their schemas at different time during the development of WildFly 20. > There is no need to update the schema just for this reference change but if the schema is updated for another reason, then the reference to urn:wildfly:credential-reference MUST be updated -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 May 2020