March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3697) Instance ProjectModel class without need of reflection in quicksilver

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3697?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-3697. --------------------------------- Resolution: Done > Instance ProjectModel class without need of reflection in quicksilver > --------------------------------------------------------------------- > > Key: DROOLS-3697 > URL: https://issues.jboss.org/browse/DROOLS-3697 > Project: Drools > Issue Type: Enhancement > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3696) Make quicksilver/shamrock integration example to work with plain drl

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3696?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-3696. --------------------------------- Resolution: Done > Make quicksilver/shamrock integration example to work with plain drl > -------------------------------------------------------------------- > > Key: DROOLS-3696 > URL: https://issues.jboss.org/browse/DROOLS-3696 > Project: Drools > Issue Type: Task > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4356) CLI, logging completion traces shouldn't be WARN

by Jean-Francois Denise (Jira)

Jean-Francois Denise created WFCORE-4356: -------------------------------------------- Summary: CLI, logging completion traces shouldn't be WARN Key: WFCORE-4356 URL: https://issues.jboss.org/browse/WFCORE-4356 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise These traces should be DEBUG level. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3726) Prepare for F2F Meeting

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3726?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3726: ----------------------------------- Sprint: 2019 Week 08-10 > Prepare for F2F Meeting > ----------------------- > > Key: DROOLS-3726 > URL: https://issues.jboss.org/browse/DROOLS-3726 > Project: Drools > Issue Type: Task > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > Work on presentation for meeting, document on knative -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3726) F2F Meeting

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3726?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3726: ----------------------------------- Summary: F2F Meeting (was: Prepare for F2F Meeting) > F2F Meeting > ----------- > > Key: DROOLS-3726 > URL: https://issues.jboss.org/browse/DROOLS-3726 > Project: Drools > Issue Type: Task > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > Work on presentation for meeting, document on knative -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3726) Prepare for F2F Meeting

by Edoardo Vacchi (Jira)

Edoardo Vacchi created DROOLS-3726: -------------------------------------- Summary: Prepare for F2F Meeting Key: DROOLS-3726 URL: https://issues.jboss.org/browse/DROOLS-3726 Project: Drools Issue Type: Task Reporter: Edoardo Vacchi Assignee: Edoardo Vacchi Work on presentation for meeting, document on knative -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-854) Fallback to FORM authentication when an invalid kerberos token is used

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/SECURITY-854?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-854: -------------------------------------------------- Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1133098|https://bugzilla.redhat.com/show_bug.cgi?id=1133098] from NEW to CLOSED > Fallback to FORM authentication when an invalid kerberos token is used > ---------------------------------------------------------------------- > > Key: SECURITY-854 > URL: https://issues.jboss.org/browse/SECURITY-854 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Reporter: Derek Horton > Assignee: Darran Lofthouse > Priority: Major > Fix For: Negotiation_2_3_4_Final > > > Negotiation will not fallback to FORM authentication if the client has a kerberos token from a different KDC than what JBoss is configured to use. > This results in the user getting presented with a 401 error and no way to login. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11691) Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts

by jaikiran pai (Jira)

[ https://issues.jboss.org/browse/WFLY-11691?page=com.atlassian.jira.plugin... ] jaikiran pai resolved WFLY-11691. --------------------------------- Fix Version/s: 16.0.0.Final Resolution: Done > Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts > --------------------------------------------------------------------------------------------- > > Key: WFLY-11691 > URL: https://issues.jboss.org/browse/WFLY-11691 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: jaikiran pai > Assignee: Stuart Douglas > Priority: Major > Fix For: 16.0.0.Final > > > More than one users[1][2] have reported that they are seeing odd timeout issues with HTTP(S) calls in their applications. Based on the discussion in those threads, I believe there are 2 issues here, one in Undertow and one in WildFly. > In Undertow, I believe there's a bug which when using HTTP 1.1, in some cases, ends up marking an in-progress request as timed out (based on the value set for no-request-timeout). Thread[1] has more details on how to reproduce such a case, but like I note in that thread, I don't think the cipher suites is what's causing this. I haven't found the time to create a simpler reproducible application for that one yet and I haven't yet created a Undertow JIRA for it. > In WildFly, I think the default value of 60 seconds for no-request-timeout on the HTTP(s) listeners, is arbitrary and even too low. IMO, this probably should default to -1 (i.e. no specific timeout) and let the users decide what value makes sense in their setup. > [1] https://developer.jboss.org/thread/279379 > [2] https://developer.jboss.org/thread/279261 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11691) Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts

by jaikiran pai (Jira)

[ https://issues.jboss.org/browse/WFLY-11691?page=com.atlassian.jira.plugin... ] jaikiran pai commented on WFLY-11691: ------------------------------------- I have verified this against the recently released WildFly 16.0.0.Final and I can no longer reproduce this issue there. So it does appear to me that this got fixed as part of: >>I highly suspect that the fix that Stuart Douglas did for https://issues.jboss.org/browse/UNDERTOW-1486 will solve this part of the problem. My minimal investigation into this issue had led me to suspect that the open listener was being triggered twice in this case. > Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts > --------------------------------------------------------------------------------------------- > > Key: WFLY-11691 > URL: https://issues.jboss.org/browse/WFLY-11691 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: jaikiran pai > Assignee: Stuart Douglas > Priority: Major > > More than one users[1][2] have reported that they are seeing odd timeout issues with HTTP(S) calls in their applications. Based on the discussion in those threads, I believe there are 2 issues here, one in Undertow and one in WildFly. > In Undertow, I believe there's a bug which when using HTTP 1.1, in some cases, ends up marking an in-progress request as timed out (based on the value set for no-request-timeout). Thread[1] has more details on how to reproduce such a case, but like I note in that thread, I don't think the cipher suites is what's causing this. I haven't found the time to create a simpler reproducible application for that one yet and I haven't yet created a Undertow JIRA for it. > In WildFly, I think the default value of 60 seconds for no-request-timeout on the HTTP(s) listeners, is arbitrary and even too low. IMO, this probably should default to -1 (i.e. no specific timeout) and let the users decide what value makes sense in their setup. > [1] https://developer.jboss.org/thread/279379 > [2] https://developer.jboss.org/thread/279261 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4239) WARN if system-property is already set and is being overridden

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/WFCORE-4239?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-4239: ------------------------------------------------- Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1654454|https://bugzilla.redhat.com/show_bug.cgi?id=1654454] from ASSIGNED to POST > WARN if system-property is already set and is being overridden > -------------------------------------------------------------- > > Key: WFCORE-4239 > URL: https://issues.jboss.org/browse/WFCORE-4239 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brad Maxwell > Assignee: Chao Wang > Priority: Major > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > WARN if system-property is already set and is being overridden > If user sets a system property using the java opts or on the command line and the same system property is defined in the standalone.xml, then the standalone.xml value overrides that passed on the commandline/JAVA_OPTS, a warning would be useful as looking at the logs (and ps), it shows value1 passed on the command line and nothing indicating that the value was changed later. > JAVA_OPTS="$JAVA_OPTS -Dmy.system.property=value1" > {code} > <system-properties> > <property name="my.system.property" value="value2"/> > </system-properties> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 March 2019