October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5475) Configuration xml files contain notion about jacorb even if it's already removed as supported subsystem

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5475?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka updated WFLY-5475: ----------------------------------- Affects Version/s: 10.0.0.CR2 > Configuration xml files contain notion about jacorb even if it's already removed as supported subsystem > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-5475 > URL: https://issues.jboss.org/browse/WFLY-5475 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.0.0.CR2 > Reporter: Ondřej Chaloupka > Assignee: Tomasz Adamski > > Currently the provided configuration files of application server ({{standalone/configuration/standalone-....xml}} or {{domain/configuration/....xml}}) contain expression {{jacorb}} even it was replaced by Open JDK IIOP. > I think that the configuration files should not contains the notion about the jacorb. > There are those sentences > domain/configuration/host-slave.xml + domain/configuration/host.xml > {code} > To secure JacORB you need to setup SSL > {code} > standalone/configuration/standalone*.xml + docs/examples/configs/standalone*.xml > {code} >  > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5474) exploded jsp is not deployed after server reload

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-5474?page=com.atlassian.jira.plugin.... ] Jan Stourac moved JBEAP-1230 to WFLY-5474: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5474 (was: JBEAP-1230) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Domain Management (was: Domain Management) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.CR2 (was: 7.0.0.DR11 (Alpha)) > exploded jsp is not deployed after server reload > ------------------------------------------------ > > Key: WFLY-5474 > URL: https://issues.jboss.org/browse/WFLY-5474 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 10.0.0.CR2 > Reporter: Jan Stourac > Assignee: Brian Stansberry > Priority: Critical > Attachments: simple-jsp.war > > > When I deploy exploded jsp on EAP server via marker file, undeploy it and again redeploy it via cli, then perform server reload, after those steps particular jsp is not available anymore. > For more info see "Steps to Reproduce" section. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-118) Subclass of java.util.logging.Level creates PermGen memory leak

by Murmur Murmur (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-118?page=com.atlassian.jira.plu... ] Murmur Murmur edited comment on JBLOGGING-118 at 10/5/15 7:29 AM: ------------------------------------------------------------------ I don't have a luxury of installing new jars server-side. All war files should be self contained applications. Some apps use a standard JDK provided logging capability, want to minimize all extra libraries or both valid reasons. This is currently a no-go if app is using say OpenJPA+JerseyRest+validator@annotations, jboss-logging is not behaving nice with any of that combination. Is there an internal valid reasons to have a subclass of Level even if it's known to create memory problems? If yes I understand this and won't push this change anymore. I use my own version of library and state in Stackoverflow and rest forums it is just an unofficial fix, don't expect it to pull regular upstream changes. Another globally side-effect safe working solution, very easy to implement would be to have JDKLoggerProvider2.java+JDKLogger2.java implementation. It did not use JDKLevel.java class at all. No fragmented jboss-logging libraries in wild. was (Author: murmur001): I don't have a luxury of installing new jars server-side. All war files should be self contained applications. Some apps use a standard JDK provided logging capability, want to minimize all extra libraries or both valid reasons. This is currently a no-go if app is using say OpenJPA+JerseyRest+validator@annotations, jboss-logging is not behaving nice with any of that combination. Is there an internal valid reasons to have a subclass of Level even if it's known to create memory problems? If yes I understand this and and won't push this change anymore. I use my own version of library and state in Stackoverflow and rest forums it is just an unofficial fix, don't expect it to pull regular upstream changes. Another globally side-effect safe working solution, very easy to implement would be to have JDKLoggerProvider2.java+JDKLogger2.java implementation. It did not use JDKLevel.java class at all. No fragmented jboss-logging libraries in wild. > Subclass of java.util.logging.Level creates PermGen memory leak > --------------------------------------------------------------- > > Key: JBLOGGING-118 > URL: https://issues.jboss.org/browse/JBLOGGING-118 > Project: JBoss Logging > Issue Type: Bug > Components: jboss-logging-jdk > Affects Versions: 3.3.0.Beta1 > Environment: JDK7, Tomcat 7, OpenJPA-2.4.1, ValidationAPI-1.x, hibernate-validator-5.2.1, jboss-logging (fresh from github). > Reporter: Murmur Murmur > Assignee: James Perkins > > Subclass of java.util.logging.Level creates PermGen memory leak if webapp provides jboss-logging.jar inside a webapp. This happen most likely in Tomcat and hot-redeployment stops working after few times out of PermGen memory. > It's a commonly known side effect of JDK logging library, projects should not inherit Level class. > See this discussion and github pull request where I have fixed this problem. > http://stackoverflow.com/a/32412984/185565 > https://github.com/jboss-logging/jboss-logging/pull/21 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-118) Subclass of java.util.logging.Level creates PermGen memory leak

by Murmur Murmur (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-118?page=com.atlassian.jira.plu... ] Murmur Murmur commented on JBLOGGING-118: ----------------------------------------- I don't have a luxury of installing new jars server-side. All war files should be self contained applications. Some apps use a standard JDK provided logging capability, want to minimize all extra libraries or both valid reasons. This is currently a no-go if app is using say OpenJPA+JerseyRest+validator@annotations, jboss-logging is not behaving nice with any of that combination. Is there an internal valid reasons to have a subclass of Level even if it's known to create memory problems? If yes I understand this and and won't push this change anymore. I use my own version of library and state in Stackoverflow and rest forums it is just an unofficial fix, don't expect it to pull regular upstream changes. Another globally side-effect safe working solution, very easy to implement would be to have JDKLoggerProvider2.java+JDKLogger2.java implementation. It did not use JDKLevel.java class at all. No fragmented jboss-logging libraries in wild. > Subclass of java.util.logging.Level creates PermGen memory leak > --------------------------------------------------------------- > > Key: JBLOGGING-118 > URL: https://issues.jboss.org/browse/JBLOGGING-118 > Project: JBoss Logging > Issue Type: Bug > Components: jboss-logging-jdk > Affects Versions: 3.3.0.Beta1 > Environment: JDK7, Tomcat 7, OpenJPA-2.4.1, ValidationAPI-1.x, hibernate-validator-5.2.1, jboss-logging (fresh from github). > Reporter: Murmur Murmur > Assignee: James Perkins > > Subclass of java.util.logging.Level creates PermGen memory leak if webapp provides jboss-logging.jar inside a webapp. This happen most likely in Tomcat and hot-redeployment stops working after few times out of PermGen memory. > It's a commonly known side effect of JDK logging library, projects should not inherit Level class. > See this discussion and github pull request where I have fixed this problem. > http://stackoverflow.com/a/32412984/185565 > https://github.com/jboss-logging/jboss-logging/pull/21 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-118) Subclass of java.util.logging.Level creates PermGen memory leak

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-118?page=com.atlassian.jira.plu... ] David Lloyd commented on JBLOGGING-118: --------------------------------------- If you don't want this effect to happen, then you should either (a) install jboss-logging server-wide, or (b) don't use the JUL backend; instead use log4j or logback or something. > Subclass of java.util.logging.Level creates PermGen memory leak > --------------------------------------------------------------- > > Key: JBLOGGING-118 > URL: https://issues.jboss.org/browse/JBLOGGING-118 > Project: JBoss Logging > Issue Type: Bug > Components: jboss-logging-jdk > Affects Versions: 3.3.0.Beta1 > Environment: JDK7, Tomcat 7, OpenJPA-2.4.1, ValidationAPI-1.x, hibernate-validator-5.2.1, jboss-logging (fresh from github). > Reporter: Murmur Murmur > Assignee: James Perkins > > Subclass of java.util.logging.Level creates PermGen memory leak if webapp provides jboss-logging.jar inside a webapp. This happen most likely in Tomcat and hot-redeployment stops working after few times out of PermGen memory. > It's a commonly known side effect of JDK logging library, projects should not inherit Level class. > See this discussion and github pull request where I have fixed this problem. > http://stackoverflow.com/a/32412984/185565 > https://github.com/jboss-logging/jboss-logging/pull/21 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-916) Kerberos authentication into Management Console does not fallback correctly

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-916?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-916: ------------------------------------ Fix Version/s: 2.0.0.CR7 > Kerberos authentication into Management Console does not fallback correctly > ---------------------------------------------------------------------------- > > Key: WFCORE-916 > URL: https://issues.jboss.org/browse/WFCORE-916 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.0.Beta1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 2.0.0.CR7 > > > Fallback management realm is not taken into account for Kerberos authentication into Management Console. In cases when Kerberos authentication to Management Console is configured also with fallback mechanism (properties, security-domain...) and one of: > - realm in principal is not set correctly > - path to keytab is not set correctly > is set in EAP configuration and when user with valid kerberos ticket tries to access Management Console then fallback is not taken into account and user cant access management console. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-118) Subclass of java.util.logging.Level creates PermGen memory leak

by Murmur Murmur (JIRA)

Murmur Murmur created JBLOGGING-118: --------------------------------------- Summary: Subclass of java.util.logging.Level creates PermGen memory leak Key: JBLOGGING-118 URL: https://issues.jboss.org/browse/JBLOGGING-118 Project: JBoss Logging Issue Type: Bug Components: jboss-logging-jdk Affects Versions: 3.3.0.Beta1 Environment: JDK7, Tomcat 7, OpenJPA-2.4.1, ValidationAPI-1.x, hibernate-validator-5.2.1, jboss-logging (fresh from github). Reporter: Murmur Murmur Assignee: James Perkins Subclass of java.util.logging.Level creates PermGen memory leak if webapp provides jboss-logging.jar inside a webapp. This happen most likely in Tomcat and hot-redeployment stops working after few times out of PermGen memory. It's a commonly known side effect of JDK logging library, projects should not inherit Level class. See this discussion and github pull request where I have fixed this problem. http://stackoverflow.com/a/32412984/185565 https://github.com/jboss-logging/jboss-logging/pull/21 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5473?page=com.atlassian.jira.plugin.... ] Richard Janík updated WFLY-5473: -------------------------------- Steps to Reproduce: - two servers with non-distributable application (requires FORM authentication, user added) and <single-sign-on/> set up - create a few requests to both servers, you'll be required to authenticate for the first request - you should now have at least two sessions with the same SSO context - invalidate one of those sessions by calling session.invalidate() - what happens: another request to either of the servers won't require you to authenticate - what's expected: you should be required to authenticate again (SSO context should be destroyed) - this happens when the application is <distributable/> > Session.invalidate() does not invalidate SSO context for non-distributable applications > --------------------------------------------------------------------------------------- > > Key: WFLY-5473 > URL: https://issues.jboss.org/browse/WFLY-5473 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > > See "Steps to Reproduce" for detailed description. > According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however. > Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications

by Richard Janík (JIRA)

Richard Janík created WFLY-5473: ----------------------------------- Summary: Session.invalidate() does not invalidate SSO context for non-distributable applications Key: WFLY-5473 URL: https://issues.jboss.org/browse/WFLY-5473 Project: WildFly Issue Type: Bug Components: Web (Undertow), Clustering Reporter: Richard Janík Assignee: Stuart Douglas Priority: Blocker See "Steps to Reproduce" for detailed description. According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however. Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-916) Kerberos authentication into Management Console does not fallback correctly

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-916?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFCORE-916: ----------------------------------------- I will have a look and see if we can add some additional validation for the bad configuration, however in general these are not scenarios that fallback is supposed to be used for. Fallback works by sending two simultaneous challenges to the client, one is SPNEGO and the other is either a HTTP Digest or HTTP Basic challenge - if the web browser is configured to support Kerberos it will use it, if not the browser decides to fallback to Digest / Basic. Fallback is not a server side capability if the server subsequently discovers it is incorrectly configured. > Kerberos authentication into Management Console does not fallback correctly > ---------------------------------------------------------------------------- > > Key: WFCORE-916 > URL: https://issues.jboss.org/browse/WFCORE-916 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.0.Beta1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > Fallback management realm is not taken into account for Kerberos authentication into Management Console. In cases when Kerberos authentication to Management Console is configured also with fallback mechanism (properties, security-domain...) and one of: > - realm in principal is not set correctly > - path to keytab is not set correctly > is set in EAP configuration and when user with valid kerberos ticket tries to access Management Console then fallback is not taken into account and user cant access management console. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 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 October 2015