June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1531) Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1531?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1531: --------------------------------- ok, in which meaning should they provide same set of run methods in such case? > Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext > ------------------------------------------------------------------------------------------ > > Key: ELY-1531 > URL: https://issues.jboss.org/browse/ELY-1531 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Authentication Server > Reporter: David Lloyd > > Both AuthenticationContext and SecurityIdentity can be captured and restored in a similar manner; they should use the same gamut of {{run*()}} methods. > The methods from {{org.wildfly.common.function.Functions}} can help with this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3639) Elytron error message less comprehensive in jdk9 compared to jdk8

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3639?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-3639: -------------------------------------------- Assignee: Jean-Francois Denise > Elytron error message less comprehensive in jdk9 compared to jdk8 > ----------------------------------------------------------------- > > Key: WFCORE-3639 > URL: https://issues.jboss.org/browse/WFCORE-3639 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Beta1 > Reporter: Martin Choma > Assignee: Jean-Francois Denise > > I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason. > {code:title=jdk8} > Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed: > GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication > PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.] > {code} > Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism > {code:title=jdk9} > Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode. > {code} > This is general question, but I have hit this with this specific use case: > 1. server is configured to use GS2-KRB5 and PLAIN > 2. server is configured with TLS > 3. client is configured to use GS2-KRB5 > 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-279) Pipeline to Istio 0.8.0

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-279: ------------------------------------ Summary: Pipeline to Istio 0.8.0 Key: SWSQE-279 URL: https://issues.jboss.org/browse/SWSQE-279 Project: Kiali QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-9849. ------------------------------ Resolution: Rejected There is no memory leak, just a weak reference that stays around after undeployment. The weak references should be cleaned up by the Java garbage collector. > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9849: ------------------------------------ I opened wildfly-leak-2.hprof and verified that there is no leak, I just had forgotten to verify that the suspected leaks had strong references to them. In summary, having four org.hibernate.internal.SessionFactoryImpl instances in memory is correct, as three of them are only have *weak* references to them (will be garbage collected eventually). One difference between Hibernate 5.3.1.Final and earlier Hibernate versions, is that 5.3.1.Final defaults to using ByteBuddy for enhancing entity classes, instead of Javassist. Which probably has something to do with why with 5.3.1, I don't see any weak references to the undeployed (org.hibernate.internalSessionFactoryImpl) test app. Hope this helps you, I'm closing this issue as not a bug. Thank you for reporting it and providing the needed information to verify, that there is no leak. :) Scott > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9849: ------------------------------------ For example, one of the weak references to the org.hibernate.internalSessionFactoryImpl is: {code} Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ class java.lang.reflect.Proxy @ 0xe01da968 System Class | 1 | 24 | 144 | 7,152 '- proxyClassCache java.lang.reflect.WeakCache @ 0xe00ea488 | 1 | 32 | 144 | 7,088 '- map java.util.concurrent.ConcurrentHashMap @ 0xe00ea4d8 | 1 | 64 | 144 | 4,208 '- table java.util.concurrent.ConcurrentHashMap$Node[16] @ 0xe00ea518 | 1 | 80 | 144 | 4,144 '- [2] java.util.concurrent.ConcurrentHashMap$Node @ 0xff265af0 | 1 | 32 | 144 | 1,376 '- next java.util.concurrent.ConcurrentHashMap$Node @ 0xff265f60 | 1 | 32 | 144 | 464 '- key java.lang.reflect.WeakCache$CacheKey @ 0xff265f80 | 1 | 32 | 144 | 32 '- referent org.jboss.modules.ModuleClassLoader @ 0xe077cde8 | 1 | 88 | 144 | 161,776 '- classes java.util.Vector @ 0xe077cf48 | 1 | 32 | 144 | 65,312 '- elementData java.lang.Object[2560] @ 0xff1d0588 | 1 | 10,256 | 144 | 65,280 '- [1448] class org.hibernate.proxy.pojo.javassist.JavassistProxyFactory$2 @ 0xff2049c0| 1 | 0 | 144 | 0 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ {code} I'll look again at the heap dump that you posted and verify if the leaked session factories have strong references. > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1596) Verify all permission checks on public API are documented in the Javadoc

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1596?page=com.atlassian.jira.plugin.s... ] Jan Kalina reassigned ELY-1596: ------------------------------- Assignee: Jan Kalina > Verify all permission checks on public API are documented in the Javadoc > ------------------------------------------------------------------------ > > Key: ELY-1596 > URL: https://issues.jboss.org/browse/ELY-1596 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Jan Kalina > > We have methods such as the following where a permission check occurs but the Javadoc does not describe the required permission so an end user would only discover this by trial and error. > http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/index... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1531) Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1531?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1531: ---------------------------------- It would be very difficult to do so in a clean manner I think. > Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext > ------------------------------------------------------------------------------------------ > > Key: ELY-1531 > URL: https://issues.jboss.org/browse/ELY-1531 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Authentication Server > Reporter: David Lloyd > > Both AuthenticationContext and SecurityIdentity can be captured and restored in a similar manner; they should use the same gamut of {{run*()}} methods. > The methods from {{org.wildfly.common.function.Functions}} can help with this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1531) Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1531?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1531: --------------------------------- [~dmlloyd], run*() methods are added into AuthenticationContext from Contextual interface. Does this issue mean SecurityIdentity should use Contextual interface too? (and deprecate currently used runAs*() methods?) > Use the same gamut of runAs*() methods for both SecurityIdentity and AuthenticationContext > ------------------------------------------------------------------------------------------ > > Key: ELY-1531 > URL: https://issues.jboss.org/browse/ELY-1531 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client, Authentication Server > Reporter: David Lloyd > > Both AuthenticationContext and SecurityIdentity can be captured and restored in a similar manner; they should use the same gamut of {{run*()}} methods. > The methods from {{org.wildfly.common.function.Functions}} can help with this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow edited comment on WFLY-9849 at 6/1/18 10:45 AM: ------------------------------------------------------------- Updated: I don't seem to actually see a leak with Hibernate ORM 5.1.14.Final, as there weren't any strong references to the (undeployed) org.hibernate.internal.SessionFactoryImpl objects was (Author: smarlow): I do seem to see a leak also with Hibernate ORM 5.1.14.Final but not 5.3.1.Final. Could you verify that you don't see a leak with WildFly 13 started up via "standalone.sh -Dee8.preview.mode=true". > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2018