[JBoss JIRA] (WFCORE-201) UnboundedQueueThreadPool's keep-alive param is currently useless
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-201?page=com.atlassian.jira.plugin... ]
Panagiotis Sotiropoulos reassigned WFCORE-201:
----------------------------------------------
Assignee: Panagiotis Sotiropoulos
> UnboundedQueueThreadPool's keep-alive param is currently useless
> ----------------------------------------------------------------
>
> Key: WFCORE-201
> URL: https://issues.jboss.org/browse/WFCORE-201
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 1.0.0.Alpha10
> Reporter: James Livingston
> Assignee: Panagiotis Sotiropoulos
>
> UnboundedQueueThreadPoolService currently sets the number of core thread and the maximum threads to the same value. As core threads are never removed, the keep-alive time parameter is useless.
> Either the core threads should be lowered (to 0?) to allow timeouts, or the keep-alive parameter removed/deprecated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5121) IBM JDK: Wrong IPv6 address type used in TGS-REQ during kerberos authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5121?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-5121.
------------------------------------
Fix Version/s: 10.0.0.Final
Resolution: Rejected
I am marking this bug as rejected as this is not a bug within our code.
> IBM JDK: Wrong IPv6 address type used in TGS-REQ during kerberos authentication
> --------------------------------------------------------------------------------
>
> Key: WFLY-5121
> URL: https://issues.jboss.org/browse/WFLY-5121
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Final
>
> Attachments: capture-ibm7-ipv6-AP_ERR_MODIFIED.pcapng
>
>
> IBM JDK has a bug in its KRB5 implementation. It uses Address type 23 for IPv6 addresses. The RFC-4120 specifies in section 7.5.3 that IPv6 address type has value 24.
> https://tools.ietf.org/html/rfc4120#section-7.5.3
> ApacheDS Kerberos server after receiving TGS-REQ message with this wrong address type returns KRB-ERROR message with error code 41 (KRB5KRB_AP_ERR_MODIFIED).
> The problem occurs during client's call GSSContext.initSecContext() method.
> Additional info:
> If I change the address type value in debugger to 24 it starts to work as expected.
> The problem seems to be in com.ibm.security.krb5.internal.HostAddress.getAddrType(InetAddress) method:
> {noformat}
> /* */ private int getAddrType(InetAddress inetAddress)
> /* */ {
> /* 118 */ int addressType = 0;
> /* 119 */ if ((inetAddress instanceof Inet4Address))
> /* 120 */ addressType = 2;
> /* 121 */ else if ((inetAddress instanceof Inet6Address))
> /* 122 */ addressType = 23;
> /* 123 */ return addressType;
> /* */ }
> {noformat}
> Important part of the call stack:
> {noformat}
> [1] com.ibm.security.krb5.internal.HostAddress.<init> (HostAddress.java:212)
> [2] com.ibm.security.krb5.HostAddresses.<init> (HostAddresses.java:85)
> [3] com.ibm.security.jgss.mech.krb5.Krb5Context.getDelgCreds (Krb5Context.java:2,472)
> [4] com.ibm.security.jgss.mech.krb5.Krb5Context.initSecContext (Krb5Context.java:616)
> [5] com.ibm.security.jgss.mech.krb5.Krb5Context.initSecContext (Krb5Context.java:805)
> [6] com.ibm.security.jgss.mech.spnego.SPNEGOContext.createInitToken (SPNEGOContext.java:1,146)
> [7] com.ibm.security.jgss.mech.spnego.SPNEGOContext.initSecContext (SPNEGOContext.java:529)
> [8] com.ibm.security.jgss.GSSContextImpl.initSecContext (GSSContextImpl.java:382)
> [9] com.ibm.security.jgss.GSSContextImpl.initSecContext (GSSContextImpl.java:331)
> [10] org.jboss.as.test.integration.security.common.negotiation.JBossNegotiateScheme.authenticate (JBossNegotiateScheme.java:171)
> [11] org.apache.http.client.protocol.RequestAuthenticationBase.authenticate (RequestAuthenticationBase.java:120)
> [12] org.apache.http.client.protocol.RequestAuthenticationBase.process (RequestAuthenticationBase.java:83)
> [13] org.apache.http.client.protocol.RequestTargetAuthentication.process (RequestTargetAuthentication.java:80)
> [14] org.apache.http.protocol.ImmutableHttpProcessor.process (ImmutableHttpProcessor.java:131)
> [15] org.apache.http.protocol.HttpRequestExecutor.preProcess (HttpRequestExecutor.java:165)
> [16] org.apache.http.impl.client.DefaultRequestDirector.execute (DefaultRequestDirector.java:485)
> [17] org.apache.http.impl.client.AbstractHttpClient.doExecute (AbstractHttpClient.java:863)
> [18] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:82)
> [19] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:106)
> [20] org.jboss.as.test.integration.security.common.Utils$2.run (Utils.java:525)
> [21] org.jboss.as.test.integration.security.common.Utils$2.run (Utils.java:523)
> [22] java.security.AccessController.doPrivileged (AccessController.java:366)
> [23] javax.security.auth.Subject.doAs (Subject.java:572)
> [24] org.jboss.as.test.integration.security.common.Utils.makeCallWithKerberosAuthn (Utils.java:523)
> [25] org.jboss.as.test.integration.security.loginmodules.negotiation.SPNEGOLoginModuleTestCase.testAuthn (SPNEGOLoginModuleTestCase.java:157)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5121) IBM JDK: Wrong IPv6 address type used in TGS-REQ during kerberos authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5121?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-5121:
--------------------------------------
Assignee: Darran Lofthouse
> IBM JDK: Wrong IPv6 address type used in TGS-REQ during kerberos authentication
> --------------------------------------------------------------------------------
>
> Key: WFLY-5121
> URL: https://issues.jboss.org/browse/WFLY-5121
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Attachments: capture-ibm7-ipv6-AP_ERR_MODIFIED.pcapng
>
>
> IBM JDK has a bug in its KRB5 implementation. It uses Address type 23 for IPv6 addresses. The RFC-4120 specifies in section 7.5.3 that IPv6 address type has value 24.
> https://tools.ietf.org/html/rfc4120#section-7.5.3
> ApacheDS Kerberos server after receiving TGS-REQ message with this wrong address type returns KRB-ERROR message with error code 41 (KRB5KRB_AP_ERR_MODIFIED).
> The problem occurs during client's call GSSContext.initSecContext() method.
> Additional info:
> If I change the address type value in debugger to 24 it starts to work as expected.
> The problem seems to be in com.ibm.security.krb5.internal.HostAddress.getAddrType(InetAddress) method:
> {noformat}
> /* */ private int getAddrType(InetAddress inetAddress)
> /* */ {
> /* 118 */ int addressType = 0;
> /* 119 */ if ((inetAddress instanceof Inet4Address))
> /* 120 */ addressType = 2;
> /* 121 */ else if ((inetAddress instanceof Inet6Address))
> /* 122 */ addressType = 23;
> /* 123 */ return addressType;
> /* */ }
> {noformat}
> Important part of the call stack:
> {noformat}
> [1] com.ibm.security.krb5.internal.HostAddress.<init> (HostAddress.java:212)
> [2] com.ibm.security.krb5.HostAddresses.<init> (HostAddresses.java:85)
> [3] com.ibm.security.jgss.mech.krb5.Krb5Context.getDelgCreds (Krb5Context.java:2,472)
> [4] com.ibm.security.jgss.mech.krb5.Krb5Context.initSecContext (Krb5Context.java:616)
> [5] com.ibm.security.jgss.mech.krb5.Krb5Context.initSecContext (Krb5Context.java:805)
> [6] com.ibm.security.jgss.mech.spnego.SPNEGOContext.createInitToken (SPNEGOContext.java:1,146)
> [7] com.ibm.security.jgss.mech.spnego.SPNEGOContext.initSecContext (SPNEGOContext.java:529)
> [8] com.ibm.security.jgss.GSSContextImpl.initSecContext (GSSContextImpl.java:382)
> [9] com.ibm.security.jgss.GSSContextImpl.initSecContext (GSSContextImpl.java:331)
> [10] org.jboss.as.test.integration.security.common.negotiation.JBossNegotiateScheme.authenticate (JBossNegotiateScheme.java:171)
> [11] org.apache.http.client.protocol.RequestAuthenticationBase.authenticate (RequestAuthenticationBase.java:120)
> [12] org.apache.http.client.protocol.RequestAuthenticationBase.process (RequestAuthenticationBase.java:83)
> [13] org.apache.http.client.protocol.RequestTargetAuthentication.process (RequestTargetAuthentication.java:80)
> [14] org.apache.http.protocol.ImmutableHttpProcessor.process (ImmutableHttpProcessor.java:131)
> [15] org.apache.http.protocol.HttpRequestExecutor.preProcess (HttpRequestExecutor.java:165)
> [16] org.apache.http.impl.client.DefaultRequestDirector.execute (DefaultRequestDirector.java:485)
> [17] org.apache.http.impl.client.AbstractHttpClient.doExecute (AbstractHttpClient.java:863)
> [18] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:82)
> [19] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:106)
> [20] org.jboss.as.test.integration.security.common.Utils$2.run (Utils.java:525)
> [21] org.jboss.as.test.integration.security.common.Utils$2.run (Utils.java:523)
> [22] java.security.AccessController.doPrivileged (AccessController.java:366)
> [23] javax.security.auth.Subject.doAs (Subject.java:572)
> [24] org.jboss.as.test.integration.security.common.Utils.makeCallWithKerberosAuthn (Utils.java:523)
> [25] org.jboss.as.test.integration.security.loginmodules.negotiation.SPNEGOLoginModuleTestCase.testAuthn (SPNEGOLoginModuleTestCase.java:157)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "qui" on HPUX
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFCORE-929:
------------------------------------------
[~stalep] could you please give it a look? Any thoughts? Thanks.
> CLI is terminated unexpectedly after type "qui" on HPUX
> -------------------------------------------------------
>
> Key: WFCORE-929
> URL: https://issues.jboss.org/browse/WFCORE-929
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> *Description of problem:*
> CLI is terminated unexpectedly after type "qui" on HPUX
> *How reproducible:*
> Always on HPUX
> *Steps to Reproduce:*
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # qui
> #* type "qui" in console to CLI, do not press "enter"
> *Actual results:*
> CLI is terminated
> *Expected results:*
> CLI is not terminated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[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)
Ondřej Chaloupka created WFLY-5475:
--------------------------------------
Summary: 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
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}
<!-- TODO - only show this if the jacorb subsystem is added -->
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[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}
> <!-- TODO - only show this if the jacorb subsystem is added -->
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[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)
10 years, 10 months
[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)
10 years, 10 months
[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)
10 years, 10 months