March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-47) Perform and document a small load test run

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-47?page=com.atlassian.jira.plu... ] viet nguyen reassigned HAWKULARQE-47: ------------------------------------- Assignee: viet nguyen (was: mfoley user) > Perform and document a small load test run > ------------------------------------------ > > Key: HAWKULARQE-47 > URL: https://issues.jboss.org/browse/HAWKULARQE-47 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > > - Create a large number of pods (how many?) > - Write scripts to capture hawkular-metrics stats -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2356) Failure in a step ResultHandler should not always be reported as occurring during rollback

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2356: ---------------------------------------- Summary: Failure in a step ResultHandler should not always be reported as occurring during rollback Key: WFCORE-2356 URL: https://issues.jboss.org/browse/WFCORE-2356 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Priority: Minor When AbstractOperationContext.Step invokes a ResultHandler it catches and logs any exception. But the logged message states that the catch was during rollback handling. When the code was first written, perhaps the catch block was only for rollback handling, but now it handles both rollback and completion of successful ops. So the log message needs to be accurate. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8284) Wildfly HTTP Client 1.0.0.Alpha3

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8284?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-9269 to WFLY-8284: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8284 (was: JBEAP-9269) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Wildfly HTTP Client 1.0.0.Alpha3 > -------------------------------- > > Key: WFLY-8284 > URL: https://issues.jboss.org/browse/WFLY-8284 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8284) Wildfly HTTP Client 1.0.0.Alpha3

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8284?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8284: ------------------------------------ Assignee: Stuart Douglas > Wildfly HTTP Client 1.0.0.Alpha3 > -------------------------------- > > Key: WFLY-8284 > URL: https://issues.jboss.org/browse/WFLY-8284 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-3858: ---------------------------------- Assignee: Paul Ferraro (was: Bartosz Spyrko-Śmietanko) > Infinispan cache configuration is not always applied to security-domain > ----------------------------------------------------------------------- > > Key: WFLY-3858 > URL: https://issues.jboss.org/browse/WFLY-3858 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Robert Tuck > Assignee: Paul Ferraro > Attachments: debugger output.txt > > > On Wildfly 8.1.0.Final, I have the following standalone-ha.xml: > <subsystem xmlns="urn:jboss:domain:infinispan:2.0"> > ... > <cache-container name="security" default-cache="auth-cache" start="EAGER"> > <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/> > <replicated-cache name="auth-cache" batching="true" mode="ASYNC"> > <eviction strategy="LRU" max-entries="10000"/> > <expiration lifespan="60000"/> > </replicated-cache> > </cache-container> > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:security:1.2"> > <security-domains> > ... > <security-domain name="OAuth-Consumer" cache-type="infinispan"> > <authentication> > <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient" > module="deployment.ewb-server-ear.ear"> > <module-option name="allowedConsumerAuthFailures" value="-1"/> > <module-option name="consumerLoginFailureTimeoutMs" value="3000"/> > </login-module> > </authentication> > </security-domain> > </security-domains> > </subsystem> > After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries. > After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement: > public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception { > log.debugf("Creating SDC for domain=" + securityDomain); > AuthenticationManager am = createAuthenticationManager(securityDomain); > // create authentication cache > if (cacheFactory instanceof EmbeddedCacheManager) { > EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory); > @SuppressWarnings("rawtypes") > Cache cache = null; > if (cacheManager != null) { > // TODO override global settings with security domain specific > ConfigurationBuilder builder = new ConfigurationBuilder(); > Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache"); > ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null. > if (baseCfg != null) { > builder.read(baseCfg); > } > cacheManager.defineConfiguration(securityDomain, builder.build()); > cache = cacheManager.getCache(securityDomain); > } > if (cache != null && am instanceof CacheableManager) { > @SuppressWarnings({ "unchecked", "rawtypes" }) > CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am; > cm.setCache(cache); > } > } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) { > <…> > } > getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager: > @Override > public Configuration getCacheConfiguration(String name) { > Configuration configuration = configurationOverrides.get(name); > if (configuration == null && cacheExists(name)) { > return defaultConfiguration; > } > return configuration; > } > Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String). > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-838) Ability to obtain SecurityIdentity without requiring LoginPermission

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-838?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-838. ---------------------------------- Fix Version/s: 1.1.0.Beta4 Assignee: Farah Juma (was: David Lloyd) Resolution: Done > Ability to obtain SecurityIdentity without requiring LoginPermission > -------------------------------------------------------------------- > > Key: ELY-838 > URL: https://issues.jboss.org/browse/ELY-838 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Farah Juma > Priority: Critical > Fix For: 1.1.0.Beta29, 1.1.0.Beta4 > > > Integrations such as the batch subsystem within WildFly have the requirement to re-create a previous SecurityIdentity by name using their referenced SecurityDomain, however as this identity may have been inflowed the LoginPermission can not be assumed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-838) Ability to obtain SecurityIdentity without requiring LoginPermission

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-838?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-838: --------------------------------- Fix Version/s: (was: 1.1.0.Beta29) > Ability to obtain SecurityIdentity without requiring LoginPermission > -------------------------------------------------------------------- > > Key: ELY-838 > URL: https://issues.jboss.org/browse/ELY-838 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Farah Juma > Priority: Critical > Fix For: 1.1.0.Beta4 > > > Integrations such as the batch subsystem within WildFly have the requirement to re-create a previous SecurityIdentity by name using their referenced SecurityDomain, however as this identity may have been inflowed the LoginPermission can not be assumed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-838) Ability to obtain SecurityIdentity without requiring LoginPermission

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-838?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-838: ------------------------------------ Assignee: David Lloyd > Ability to obtain SecurityIdentity without requiring LoginPermission > -------------------------------------------------------------------- > > Key: ELY-838 > URL: https://issues.jboss.org/browse/ELY-838 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta29 > > > Integrations such as the batch subsystem within WildFly have the requirement to re-create a previous SecurityIdentity by name using their referenced SecurityDomain, however as this identity may have been inflowed the LoginPermission can not be assumed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-662) Eliminate CredentialStore interaction from within SASL mechanisms.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-662?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-662. ---------------------------------- Resolution: Out of Date Mechanism and credential store interaction has been cleaned up. > Eliminate CredentialStore interaction from within SASL mechanisms. > ------------------------------------------------------------------ > > Key: ELY-662 > URL: https://issues.jboss.org/browse/ELY-662 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credential Store, SASL > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Priority: Critical > Fix For: 1.1.0.Beta29 > > > The conversion between callbacks and credential store should be handled centrally within the callback handler and not within the mechanism. > This way all mechanisms can use the core integration including mechanisms that may not be Elytron aware just using standard Java callbacks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-449) Add CredentialStore support to Elytron client configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-449?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-449: ------------------------------------ Fix Version/s: 1.1.0.Beta17 (was: 1.1.0.Beta29) Assignee: Peter Skopek Resolution: Done > Add CredentialStore support to Elytron client configuration > ----------------------------------------------------------- > > Key: ELY-449 > URL: https://issues.jboss.org/browse/ELY-449 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client, Credential Store > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: 1.1.0.Beta17 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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