January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7986) Add some exclusions to the 'org.wildfly.extension.elytron' module.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7986?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7986: ----------------------------------- Priority: Critical (was: Major) > Add some exclusions to the 'org.wildfly.extension.elytron' module. > ------------------------------------------------------------------ > > Key: WFLY-7986 > URL: https://issues.jboss.org/browse/WFLY-7986 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > Likely to be something like: - > {{ > <exports> > <exclude path="org/wildfly/extension/elytron/ElytronExtension"/> > <exclude path="org/wildfly/extension/elytron/_private"/> > <exclude path="org/wildfly/extension/elytron/capabilities"/> > </exports> > }} > Although capabilities also needs to be double checked, this may be moved and hidden using standard Java visibility modifiers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7986) Add some exclusions to the 'org.wildfly.extension.elytron' module.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7986?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7986: ----------------------------------- Description: Likely to be something like: - bq. <exports> bq. <exclude path="org/wildfly/extension/elytron/ElytronExtension"/> bq. <exclude path="org/wildfly/extension/elytron/_private"/> bq. <exclude path="org/wildfly/extension/elytron/capabilities"/> bq. </exports> Although capabilities also needs to be double checked, this may be moved and hidden using standard Java visibility modifiers. was: Likely to be something like: - {{ <exports> <exclude path="org/wildfly/extension/elytron/ElytronExtension"/> <exclude path="org/wildfly/extension/elytron/_private"/> <exclude path="org/wildfly/extension/elytron/capabilities"/> </exports> }} Although capabilities also needs to be double checked, this may be moved and hidden using standard Java visibility modifiers. > Add some exclusions to the 'org.wildfly.extension.elytron' module. > ------------------------------------------------------------------ > > Key: WFLY-7986 > URL: https://issues.jboss.org/browse/WFLY-7986 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > Likely to be something like: - > bq. <exports> > bq. <exclude path="org/wildfly/extension/elytron/ElytronExtension"/> > bq. <exclude path="org/wildfly/extension/elytron/_private"/> > bq. <exclude path="org/wildfly/extension/elytron/capabilities"/> > bq. </exports> > Although capabilities also needs to be double checked, this may be moved and hidden using standard Java visibility modifiers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7986) Add some exclusions to the 'org.wildfly.extension.elytron' module.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7986: -------------------------------------- Summary: Add some exclusions to the 'org.wildfly.extension.elytron' module. Key: WFLY-7986 URL: https://issues.jboss.org/browse/WFLY-7986 Project: WildFly Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 Likely to be something like: - {{ <exports> <exclude path="org/wildfly/extension/elytron/ElytronExtension"/> <exclude path="org/wildfly/extension/elytron/_private"/> <exclude path="org/wildfly/extension/elytron/capabilities"/> </exports> }} Although capabilities also needs to be double checked, this may be moved and hidden using standard Java visibility modifiers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2237) Upgrade Undertow to 1.4.9

by Paul Ferraro (JIRA)

Paul Ferraro created WFCORE-2237: ------------------------------------ Summary: Upgrade Undertow to 1.4.9 Key: WFCORE-2237 URL: https://issues.jboss.org/browse/WFCORE-2237 Project: WildFly Core Issue Type: Component Upgrade Affects Versions: 3.0.0.Alpha22 Reporter: Paul Ferraro Containing fix for https://issues.jboss.org/browse/UNDERTOW-976 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ] Paul Ferraro reopened WFLY-5932: -------------------------------- Reopening per downstream. > Invalidating a session of an SSO on a different node than where the session was created does not logout the user > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5932 > URL: https://issues.jboss.org/browse/WFLY-5932 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > > See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate): > * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2 > Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected): > * Access A1, authenticate, invalidate session on A1, access A1 > * Access A1, authenticate, access A2, invalidate session on A1, access A1 > Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-5932: ---------------------------------- Assignee: Paul Ferraro (was: Stuart Douglas) > Invalidating a session of an SSO on a different node than where the session was created does not logout the user > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5932 > URL: https://issues.jboss.org/browse/WFLY-5932 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > > See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate): > * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2 > Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected): > * Access A1, authenticate, invalidate session on A1, access A1 > * Access A1, authenticate, access A2, invalidate session on A1, access A1 > Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7985) Where modules are specified in the Elytron subsystem configuration can we perform a private API check?

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7985: -------------------------------------- Summary: Where modules are specified in the Elytron subsystem configuration can we perform a private API check? Key: WFLY-7985 URL: https://issues.jboss.org/browse/WFLY-7985 Project: WildFly Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 Similar to: - org.jboss.as.server.moduleservice.ModuleLoadService Although there may be limitations as a custom public module may be added that depends on a private module. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-900) CredentialSource equals and hashCode

by David Lloyd (JIRA)

David Lloyd created ELY-900: ------------------------------- Summary: CredentialSource equals and hashCode Key: ELY-900 URL: https://issues.jboss.org/browse/ELY-900 Project: WildFly Elytron Issue Type: Bug Components: Credentials Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1421) Support multi-argument accumulate functions

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-1421: ---------------------------------------- Summary: Support multi-argument accumulate functions Key: DROOLS-1421 URL: https://issues.jboss.org/browse/DROOLS-1421 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 6.5.0.Final Reporter: Geoffrey De Smet Assignee: Mario Fusco I'd like to be able to do this: {code} accumulate( TaskAssignment($person : person, $duration : duration); $b : loadBalance($person, $duration) ) {code} This loadBalance function basically does sqrt(sum(squared(sum($duration) per $person))), so it cannot be split up into 2 separate accumulate functions. This loadBalance of fairness function is very common for employee rostering, task assignment (incl jbpm), cloud optimization, etc, so we 'll provide it out of the box. Internally, the compiler should do some syntactic sugar for DRL {code} $b : loadBalance($p, $d) => syntactic sugar => $b : loadBalance(new Object[]{$p, $d}) {code} The AccumulateFunction would then get an Object[] instance: {code} public void accumulate(Serializable context, Object o) { Object[] value = (Object[]) o; ... } {code} It's ok that the AccumulateFunction is still complex as that's only coded once, but the use of that function is in a lot of user code and examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1420) (int) ($p * 1_000.0) throws a misleading exception

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-1420: ---------------------------------------- Summary: (int) ($p * 1_000.0) throws a misleading exception Key: DROOLS-1420 URL: https://issues.jboss.org/browse/DROOLS-1420 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.0.0.Beta5 Reporter: Geoffrey De Smet Assignee: Mario Fusco This fails with *$p cannot be resolved to a variable*: {code} rule R when Cheese($p : price) then int b = (int) ($p * 1_000.0); // FAILS, because $p cannot be resolved ?! end {code} That error message is nonsense. It should just work. If it doesn't due to ECJ, it should say something like "cannot be cast". This works in java: {code} int a = 42; int b = ((int) (a * 1_000.0)); {code} Removing the underscore fixes it: {code} rule R when Cheese($p : price) then int b = (int) ($p * 1000.0); // SUCCESS end {code} Regardless of an upstream ECJ problem (which should be reported if that's indeed the problem), the error message is wrong and send me on a wild goose hunt. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 January 2017