January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4793) Upgrade WildFly Elytron to 1.11.0.CR5

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4793?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4793: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Upgrade WildFly Elytron to 1.11.0.CR5 > ------------------------------------- > > Key: WFCORE-4793 > URL: https://issues.redhat.com/browse/WFCORE-4793 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4484) Support SSH authentication for Git persistence

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4484?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4484: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Support SSH authentication for Git persistence > ---------------------------------------------- > > Key: WFCORE-4484 > URL: https://issues.redhat.com/browse/WFCORE-4484 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Reporter: Farah Juma > Assignee: Ashley Abdel-Sayed > Priority: Major > Labels: EAP-CD19 > Fix For: 11.0.0.Beta7 > > > Currently Elytron only supports authentication for HTTP(s) URLS so there is no way to connect to a SSH git server to pull/push configuration history -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4794) Upgrade Elytron Web to 1.7.0.CR4

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4794?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4794: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Upgrade Elytron Web to 1.7.0.CR4 > -------------------------------- > > Key: WFCORE-4794 > URL: https://issues.redhat.com/browse/WFCORE-4794 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12945) Migrate undertow subsystem to new MSC value API

by Richard Opalka (Jira)

[ https://issues.redhat.com/browse/WFLY-12945?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFLY-12945: ---------------------------------- Fix Version/s: 19.0.0.Beta1 > Migrate undertow subsystem to new MSC value API > ----------------------------------------------- > > Key: WFLY-12945 > URL: https://issues.redhat.com/browse/WFLY-12945 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12945) Migrate undertow subsystem to new MSC value API

by Richard Opalka (Jira)

Richard Opalka created WFLY-12945: ------------------------------------- Summary: Migrate undertow subsystem to new MSC value API Key: WFLY-12945 URL: https://issues.redhat.com/browse/WFLY-12945 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Reporter: Richard Opalka Assignee: Richard Opalka -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4795) Make timeout of ManagedExplodedContentServitor configurable

by Jo Vandermeeren (Jira)

Jo Vandermeeren created WFCORE-4795: --------------------------------------- Summary: Make timeout of ManagedExplodedContentServitor configurable Key: WFCORE-4795 URL: https://issues.redhat.com/browse/WFCORE-4795 Project: WildFly Core Issue Type: Enhancement Components: Server Reporter: Jo Vandermeeren Assignee: Jeff Mesnil The [ManagedExplodedContentServitor |https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/ManagedExplodedContentServitor.java] deletes previously staged exploded managed WARs before deploying again from the repository. This class uses a latch to wait 60 seconds before failing the deployment with a StartException. On a Windows VM deleting an exploded WAR can take a long time, especially with Virus scanning enabled. It would be appreciated if this timeout was either increased or configurable. We now had to work around this issue by manually deleting the _standalone/data/managed-exploded_ directory and its contents before booting WildFly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David commented on DROOLS-4909: --------------------------------------- Thank you very much, this is it, now no more looping within our reference knowledge base :) I was wondering, why this limitation has been introduced after 7.20.0.Final ? As it was working fine previously ? Performance considerations ? > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png, toto.drl > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Paul Ferraro resolved WFWIP-290. -------------------------------- Resolution: Done Fixed. > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ] Jean Francois Denise updated WFCORE-4785: ----------------------------------------- Description: Boot server, connect CLI and reload. On a complex standalone.xml configuration, I can see 150+ PathAddress being leaked. As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). Attached heapdump, server.log and configuration used (reduced standalone.xml). server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. server.log contains stacktrace of PathAddress allocation. You will notice: 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. 4) We have 3 remaining PathAddress 149, 600 and 789 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. So we have a leak of 1 PathAddress instance, instance 149. was: Boot server, connect CLI and reload. As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). Attached heapdump, server.log and configuration used (reduced standalone.xml). server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. server.log contains stacktrace of PathAddress allocation. You will notice: 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. 4) We have 3 remaining PathAddress 149, 600 and 789 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. So we have a leak of 1 PathAddress instance, instance 149. > PathAddress leaked on reload > ---------------------------- > > Key: WFCORE-4785 > URL: https://issues.redhat.com/browse/WFCORE-4785 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jean Francois Denise > Assignee: Jeff Mesnil > Priority: Major > Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml > > > Boot server, connect CLI and reload. > On a complex standalone.xml configuration, I can see 150+ PathAddress being leaked. > As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). > Attached heapdump, server.log and configuration used (reduced standalone.xml). > server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. > server.log contains stacktrace of PathAddress allocation. > You will notice: > 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. > 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. > 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. > 4) We have 3 remaining PathAddress 149, 600 and 789 > 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. > So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Fabio Burzigotti commented on WFWIP-290: ---------------------------------------- Tanks [~pferraro], I fixed the TS accordingly. This issue can be considered as resolved in the above mentioned version of the feature branch. > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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