May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5342) Default value of "drools.lambda.introspector.cache.size" for externalized lambda

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5342: ----------------------------------------- Summary: Default value of "drools.lambda.introspector.cache.size" for externalized lambda Key: DROOLS-5342 URL: https://issues.redhat.com/browse/DROOLS-5342 Project: Drools Issue Type: Task Components: executable model Affects Versions: 7.37.0.Final Reporter: Toshiya Kobayashi Assignee: Luca Molteni Regarding the cache size default value of LambdaIntrospector.methodFingerprintsMap, If "drools.externaliseCanonicalModelLambda" option is not enabled, the cache is frequently used so it will not likely retain old classloaders. So the default value '32' would be fine. If "drools.externaliseCanonicalModelLambda" option is enabled, the cache is used in rare occasions: A) Lambda for binding variable (DROOLS-5328) B) Lambda which ExecModelLambdaPostProcessor failed to externalize (DROOLS-5329) So one build may use only a few entries in a cache Map. Then, the cache eventually may retain several old classloaders after multiple builds. Generally, the classloader leak issue is prioritized over build time performance benefit so '0' is the good default value when externaliseCanonicalModelLambda is enabled. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13482) Exclude legacy feature packs from the legacy feature pack license generation

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13482?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13482: ------------------------------------ Priority: Minor (was: Major) > Exclude legacy feature packs from the legacy feature pack license generation > ---------------------------------------------------------------------------- > > Key: WFLY-13482 > URL: https://issues.redhat.com/browse/WFLY-13482 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > The license file generation for the galleon feature pack excludes the feature packs themselves, but the legacy feature pack generation does not. That leads to pointless diffs between dists generated from the two f-ps. So exclude the legacy f-ps the same way as is done with galleon. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13482) Exclude legacy feature packs from the legacy feature pack license generation

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13482: --------------------------------------- Summary: Exclude legacy feature packs from the legacy feature pack license generation Key: WFLY-13482 URL: https://issues.redhat.com/browse/WFLY-13482 Project: WildFly Issue Type: Task Components: Build System Reporter: Brian Stansberry Assignee: Brian Stansberry The license file generation for the galleon feature pack excludes the feature packs themselves, but the legacy feature pack generation does not. That leads to pointless diffs between dists generated from the two f-ps. So exclude the legacy f-ps the same way as is done with galleon. -- 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 Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13426?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13426: -------------------------------- Description: Currently, WildFly uses JBoss Marshalling to marshal user objects (session attributes, SFSB instances, etc.) 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 was: 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 > 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, etc.) 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-13426) Optimize marshalling in clustering subsystems using ProtoStream

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13426?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFLY-13426: ------------------------------------- [~brian.stansberry] Yes, this is an opt-in behavior. An application that wishes to use ProtoStream can annotate objects using ProtoStream annotations (and compile using org.infinispan.protostream:protostream-processor, which will auto-generate protobuf schemas, marshallers, and SerializationContextInitializers) and/or these can be provided manually. To determine which marshalling implementation to use for a given module/deployment, the WF integration code will look for service provider implementations of SerializationContextInitializer on the deployment classpath. If any exist, then we will use ProtoStream marshalling. If none exist, we fallback to JBoss Marshalling. > 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] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Thomas Darimont updated JGRP-2477: ---------------------------------- Description: Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. When an external jgroups stack configuration file is used: See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... and was removed in later versions. Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter could be added back. I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. was: Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. When an external jgroups stack configuration file is used: See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... and was removed in later versions. Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter could be added back. I created two pull requests to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, as well as the 4.x branch. > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Thomas Darimont commented on JGRP-2477: --------------------------------------- The PR can be cleanly applied to current master (62db751) as well as the 4.x branch (7790fc8). > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created two pull requests to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, as well as the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Thomas Darimont updated JGRP-2477: ---------------------------------- Git Pull Request: https://github.com/belaban/JGroups/pull/491 > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3, 5.0.0.Beta1 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created two pull requests to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, as well as the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

Thomas Darimont created JGRP-2477: ------------------------------------- Summary: Reintroduce support for configuring a JChannel via URL Key: JGRP-2477 URL: https://issues.redhat.com/browse/JGRP-2477 Project: JGroups Issue Type: Enhancement Affects Versions: 5.0.0.Beta1, 4.2.3 Reporter: Thomas Darimont Assignee: Bela Ban Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. When an external jgroups stack configuration file is used: See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... and was removed in later versions. Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter could be added back. I created two pull requests to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, as well as the 4.x branch. -- 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 Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5341?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5341: -------------------------------- Sprint: 2020 Week 22-24 (from May 25) (was: 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

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