September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-524) Caching support in the LDAP realm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-524: --------------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta9) > Caching support in the LDAP realm > --------------------------------- > > Key: ELY-524 > URL: https://issues.jboss.org/browse/ELY-524 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: David Lloyd > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta10 > > > The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic. > The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention. > For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes. > Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name. > This is a complex design topic so discussion is welcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-617) Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-617?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-617: --------------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta9) > Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration > --------------------------------------------------------------------------------- > > Key: ELY-617 > URL: https://issues.jboss.org/browse/ELY-617 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta10 > > > Javadoc states various NameRewriter instances will not be null, implementation suggests otherwise. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-625) Include the client schema in the jar

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-625?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-625: --------------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta9) > Include the client schema in the jar > ------------------------------------ > > Key: ELY-625 > URL: https://issues.jboss.org/browse/ELY-625 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta10 > > > We need to get the schema into the jar so when assembled in a WildFly feature pack it can be extracted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-628: --------------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta9) > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-624) Add support for SSO and Clustered SSO

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-624?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-624: --------------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta9) > Add support for SSO and Clustered SSO > ------------------------------------- > > Key: ELY-624 > URL: https://issues.jboss.org/browse/ELY-624 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta10 > > > This issue is to cover the APIs / SPIs and some implementation where Elytron is to be used with container managed SSO / Clustered SSO. > By this we mean authentication mechanisms similar to HTTP Form where we want the resulting SecurityIdentity to be re-used across different HTTP context and possibly in the clustered case across different nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-629) Release WildFly Elytron 1.1.0.Beta9

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-629?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-629. ---------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta9 > ----------------------------------- > > Key: ELY-629 > URL: https://issues.jboss.org/browse/ELY-629 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta9 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1800: ---------------------------------------- Assignee: (was: Brian Stansberry) > Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1800 > URL: https://issues.jboss.org/browse/WFCORE-1800 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Attachments: WFCORE-1800.patch > > > If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists. > Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist. > {code} > /path=invalid(name=name) > {code} > For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH. > The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1800: ------------------------------------------ Background comment on this for anyone interested in it that I mentioned to James when we were discussing this: [10:10 AM] Brian Stansberry: a kernel-wide fix just makes me nervous about unintentionally breaking something [10:11 AM] James R Perkins: Okay. It made me a bit nervous too which is why I didn't submit a PR :) [10:12 AM] Brian Stansberry: I think a long time ago we said that runtime-only resources still have to expose a Resource in the tree, but I believe that was still after a lot of subsystems were written Basically a fix for this would likely further enforce the rule that a Resource must be present in the tree, which may break some old stuff. I think it's the right thing to do at some point anyway, but as part of it we need to recognize the potential for breakage and do some analysis of runtime-only resources to ensure they are done correctly. TBH there may have been some other changes (e.g. in read-resource handling) that would have resulted in breakage if this rule wasn't being followed. But we should be cautious. > Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1800 > URL: https://issues.jboss.org/browse/WFCORE-1800 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > Attachments: WFCORE-1800.patch > > > If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists. > Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist. > {code} > /path=invalid(name=name) > {code} > For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH. > The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1291) Rule Compilation errors on mac and windows

by Robert (Bob) Brodt (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1291?page=com.atlassian.jira.plugi... ] Robert (Bob) Brodt closed DROOLS-1291. -------------------------------------- Release Notes Text: A change in the Eclipse Neon JDT surfaced a bug in the Drools Java compiler interface. This was not an issue with the Eclipse Mars JDT. Fix Version/s: 6.5.0.CR2 Resolution: Duplicate Issue This is a duplicate of DROOLS-1250 > Rule Compilation errors on mac and windows > ------------------------------------------ > > Key: DROOLS-1291 > URL: https://issues.jboss.org/browse/DROOLS-1291 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Environment: RHDS 10.0.0.GA + RHDSIS 10.0.0.Alpha1 (JBoss Drools 6.4.1.Final-v20160503-1355-B205) > Reporter: Andrej Podhradsky > Assignee: Robert (Bob) Brodt > Priority: Blocker > Fix For: 6.5.0.CR2 > > Attachments: drools_error.png > > > The following error occurs on mac and windows after creating a drools project in Problems view > {code} > Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > Message.GOODBYE cannot be resolved to a type > org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1800: ---------------------------------- Description: If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists. Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist. {code} /path=invalid(name=name) {code} For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH. The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH. was: If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists. Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist. {code} /path=invalid(name=name) {code} For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH. > Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1800 > URL: https://issues.jboss.org/browse/WFCORE-1800 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > Attachments: WFCORE-1800.patch > > > If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists. > Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist. > {code} > /path=invalid(name=name) > {code} > For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH. > The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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 September 2016