November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGTOOL-119) GeneratedSourceAnalysisTest needs to be redone

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-119?page=com.atlassian.jira.plugi... ] James Perkins reassigned LOGTOOL-119: ------------------------------------- Fix Version/s: 2.1.0.Alpha1 Assignee: James Perkins Resolution: Done > GeneratedSourceAnalysisTest needs to be redone > ---------------------------------------------- > > Key: LOGTOOL-119 > URL: https://issues.jboss.org/browse/LOGTOOL-119 > Project: Log Tool > Issue Type: Task > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha1 > > > The {{GeneratedSourceAnalysisTest}} test needs to be redone to better parse source files. Adding new methods or various enhancements to the generated source files usually causes problems with the test. The parsing is also very crude and should be improved. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-119) GeneratedSourceAnalysisTest needs to be redone

by James Perkins (JIRA)

James Perkins created LOGTOOL-119: ------------------------------------- Summary: GeneratedSourceAnalysisTest needs to be redone Key: LOGTOOL-119 URL: https://issues.jboss.org/browse/LOGTOOL-119 Project: Log Tool Issue Type: Task Reporter: James Perkins The {{GeneratedSourceAnalysisTest}} test needs to be redone to better parse source files. Adding new methods or various enhancements to the generated source files usually causes problems with the test. The parsing is also very crude and should be improved. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1364) InMemorySessionFactory has apparent memory leak

by Eli Israel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1364?page=com.atlassian.jira.plugi... ] Eli Israel commented on DROOLS-1364: ------------------------------------ I notice that the comment in the InMemorySessionFactory class reads: // TODO all sessions stored here should be proxied so it can be removed on dispose/destroy Which would certainly cover the issue I noticed. > InMemorySessionFactory has apparent memory leak > ----------------------------------------------- > > Key: DROOLS-1364 > URL: https://issues.jboss.org/browse/DROOLS-1364 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Eli Israel > Assignee: Mario Fusco > > I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated) > The SessionCache properly gets rid of sessions that have hung around too long, which is great. > But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions. > It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-756: ------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Elytron ldap-realm does not support recursive role search > --------------------------------------------------------- > > Key: ELY-756 > URL: https://issues.jboss.org/browse/ELY-756 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > Scenario: > LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process. > In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm. > Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron. > See example of LDIF for LDAP server: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=jduke,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: jduke > cn: Java Duke > sn: Duke > userPassword: Password1 > dn: ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Roles > dn: cn=R1,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R1 > member: uid=jduke,ou=People,dc=jboss,dc=org > description: the R1 group > dn: cn=R2,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R2 > member: cn=R1,ou=Roles,dc=jboss,dc=org > description: the R2 group > dn: cn=R3,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R3 > member: cn=R2,ou=Roles,dc=jboss,dc=org > description: the R3 group > {code} > In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-695) Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-695?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-695: ------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource. > ------------------------------------------------------------------------------------------------------- > > Key: ELY-695 > URL: https://issues.jboss.org/browse/ELY-695 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store, KeyStores > Reporter: Hynek Švábek > Assignee: Jan Kalina > > Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource. > *Scenario:* > * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore > * I want to delete whole Elytron subsystem > * I execute this CLI command */subsystem=elytron:remove()* and get error > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly", > "rolled-back" => true > } > {code} > *NOTES:* > * When I perform CLI command */subsystem=elytron:remove()* again as it passes. > * When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7619) Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7619?page=com.atlassian.jira.plugin.... ] Jan Kalina moved ELY-695 to WFLY-7619: -------------------------------------- Project: WildFly (was: WildFly Elytron) Key: WFLY-7619 (was: ELY-695) Component/s: Security (was: Credential Store) (was: KeyStores) > Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource. > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-7619 > URL: https://issues.jboss.org/browse/WFLY-7619 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Jan Kalina > > Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource. > *Scenario:* > * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore > * I want to delete whole Elytron subsystem > * I execute this CLI command */subsystem=elytron:remove()* and get error > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly", > "rolled-back" => true > } > {code} > *NOTES:* > * When I perform CLI command */subsystem=elytron:remove()* again as it passes. > * When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1364) InMemorySessionFactory has apparent memory leak

by Eli Israel (JIRA)

Eli Israel created DROOLS-1364: ---------------------------------- Summary: InMemorySessionFactory has apparent memory leak Key: DROOLS-1364 URL: https://issues.jboss.org/browse/DROOLS-1364 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.Final Reporter: Eli Israel Assignee: Mario Fusco I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated) The SessionCache properly gets rid of sessions that have hung around too long, which is great. But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions. It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7618) Fix code to not use default platform dependant encoding

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-7618?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda commented on WFLY-7618: ----------------------------------------- Tomaz's analysis identified 107 problems with encoding and only 24 of those in non test code > Fix code to not use default platform dependant encoding > ------------------------------------------------------- > > Key: WFLY-7618 > URL: https://issues.jboss.org/browse/WFLY-7618 > Project: WildFly > Issue Type: Task > Reporter: Rostislav Svoboda > Assignee: Tomaz Cerar > > WFLY codebase depends in some cases on system default encoding. This should be fixed to use de facto standard UTF8. > This JIRA is followup of WFCORE-1510 in the main codebase. Main concern (proven by history too) is Windows. > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7618) Fix code to not use default platform dependant encoding

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-7618?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda updated WFLY-7618: ------------------------------------ Description: WFLY codebase depends in some cases on system default encoding. This should be fixed to use de facto standard UTF8. This JIRA is followup of WFCORE-1510 in the main codebase. Main concern (proven by history too) is Windows. was: WFLY codebase depends in some cases on system default encoding. This should be fixed to use de facto standard UTF8. This is basically followup of WFCORE-1510 in the main codebase. > Fix code to not use default platform dependant encoding > ------------------------------------------------------- > > Key: WFLY-7618 > URL: https://issues.jboss.org/browse/WFLY-7618 > Project: WildFly > Issue Type: Task > Reporter: Rostislav Svoboda > Assignee: Tomaz Cerar > > WFLY codebase depends in some cases on system default encoding. This should be fixed to use de facto standard UTF8. > This JIRA is followup of WFCORE-1510 in the main codebase. Main concern (proven by history too) is Windows. > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7618) Fix code to not use default platform dependant encoding

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFLY-7618: --------------------------------------- Summary: Fix code to not use default platform dependant encoding Key: WFLY-7618 URL: https://issues.jboss.org/browse/WFLY-7618 Project: WildFly Issue Type: Task Reporter: Rostislav Svoboda Assignee: Tomaz Cerar WFLY codebase depends in some cases on system default encoding. This should be fixed to use de facto standard UTF8. This is basically followup of WFCORE-1510 in the main codebase. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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