December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-388) On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-388?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-388: --------------------------------- Does it work if you _add_ {{enabled-protocols="TLSv1"}} in addition to {{enabled-cipher-suites="TLSv1"}}? > On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string > ----------------------------------------------------------------------------------------- > > Key: ELY-388 > URL: https://issues.jboss.org/browse/ELY-388 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Environment: IBM java 1.8 SR1 FP10 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > On ibm java 1.8 I can't establish HTTPS connection using TLSv1 cipher string. On EAP 6.4 it is possible. > Handshake ends with message > javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no appropriate cipher suite specified or protocols are deactivated > Note, issue apply to enabled-cipher-suites="TLSv1", not enabled-protocols="TLSv1" - that works OK. > According to OpenSSL documentation [1], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > According to Elytron documentation [2], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS > [2] http://wildfly-security.github.io/wildfly-elytron/org/wildfly/security/ss... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1965) Change default thread pool rejection policy to "abort"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1965?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1965: ----------------------------------------------- Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1275362|https://bugzilla.redhat.com/show_bug.cgi?id=1275362] from POST to CLOSED > Change default thread pool rejection policy to "abort" > ------------------------------------------------------ > > Key: JGRP-1965 > URL: https://issues.jboss.org/browse/JGRP-1965 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.6 > Reporter: Paul Ferraro > Assignee: Bela Ban > Fix For: 3.6.7 > > > Currently, JGroups transport thread pools use discard as a rejection policy. Thus if there are no available threads, and the queue is full, the executor will silently drop the task. > Abort will throw a RejectedExecutionException, in which case, which JGroups catches to populate the num_rejected_msgs statistic. This is a better default, so that users can monitor this value to determine whether or not to modify their thread pool configuration. Otherwise, num_rejected_msgs is 0, which might be a source of confusion. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-388) On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-388?page=com.atlassian.jira.plugin.sy... ] Martin Choma reassigned ELY-388: -------------------------------- Assignee: Darran Lofthouse (was: Stuart Douglas) > On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string > ----------------------------------------------------------------------------------------- > > Key: ELY-388 > URL: https://issues.jboss.org/browse/ELY-388 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Environment: IBM java 1.8 SR1 FP10 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > On ibm java 1.8 I can't establish HTTPS connection using TLSv1 cipher string. On EAP 6.4 it is possible. > Handshake ends with message > javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no appropriate cipher suite specified or protocols are deactivated > Note, issue apply to enabled-cipher-suites="TLSv1", not enabled-protocols="TLSv1" - that works OK. > According to OpenSSL documentation [1], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > According to Elytron documentation [2], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS > [2] http://wildfly-security.github.io/wildfly-elytron/org/wildfly/security/ss... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-388) On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-388?page=com.atlassian.jira.plugin.sy... ] Martin Choma moved JBEAP-2277 to ELY-388: ----------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-388 (was: JBEAP-2277) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: SSL (was: Security) (was: Web (Undertow)) Target Release: (was: 7.0.0.GA) Affects Version/s: 1.0.2.Final (was: 7.0.0.ER2 (Beta)) > On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string > ----------------------------------------------------------------------------------------- > > Key: ELY-388 > URL: https://issues.jboss.org/browse/ELY-388 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Environment: IBM java 1.8 SR1 FP10 > Reporter: Martin Choma > Assignee: Stuart Douglas > > On ibm java 1.8 I can't establish HTTPS connection using TLSv1 cipher string. On EAP 6.4 it is possible. > Handshake ends with message > javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no appropriate cipher suite specified or protocols are deactivated > Note, issue apply to enabled-cipher-suites="TLSv1", not enabled-protocols="TLSv1" - that works OK. > According to OpenSSL documentation [1], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > According to Elytron documentation [2], cipher suites corresponding with TLSv1 cipher string should be available for handshake. > [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS > [2] http://wildfly-security.github.io/wildfly-elytron/org/wildfly/security/ss... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1194) Name for wildcard resources should be configurable in parser

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1194?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1194: ------------------------------------- Labels: affects_elytron (was: ) > Name for wildcard resources should be configurable in parser > ------------------------------------------------------------ > > Key: WFCORE-1194 > URL: https://issues.jboss.org/browse/WFCORE-1194 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.0.4.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Labels: affects_elytron > > Currently attribute do distinguish between resource names is always "name" > this should be configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1194) Name for wildcard resources should be configurable in parser

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-1194: ----------------------------------- Summary: Name for wildcard resources should be configurable in parser Key: WFCORE-1194 URL: https://issues.jboss.org/browse/WFCORE-1194 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Affects Versions: 2.0.4.Final Reporter: Tomaz Cerar Assignee: Tomaz Cerar Currently attribute do distinguish between resource names is always "name" this should be configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5810) JNDIPermission is based in a private module

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-5810?page=com.atlassian.jira.plugin.... ] Ivo Studensky commented on WFLY-5810: ------------------------------------- In a pull request comment [~dmlloyd] said: {quote} If [~n1hility] approves of moving {{JndiPermission}}, I'll get that ball rolling. I'd like to put it in the {{org.wildfly.naming.client}} package where the rest of the new naming client classes will be appearing in EAP 7.1. {quote} > JNDIPermission is based in a private module > ------------------------------------------- > > Key: WFLY-5810 > URL: https://issues.jboss.org/browse/WFLY-5810 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 10.0.0.CR4 > Reporter: Ivo Studensky > > At the moment {{JndiPermission}} is based in {{org.jboss.as.naming}} module which is private. Because of this it effectively cannot be used by deployments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5810) JNDIPermission is based in a private module

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-5810?page=com.atlassian.jira.plugin.... ] Ivo Studensky reassigned WFLY-5810: ----------------------------------- Assignee: Ivo Studensky > JNDIPermission is based in a private module > ------------------------------------------- > > Key: WFLY-5810 > URL: https://issues.jboss.org/browse/WFLY-5810 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 10.0.0.CR4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > At the moment {{JndiPermission}} is based in {{org.jboss.as.naming}} module which is private. Because of this it effectively cannot be used by deployments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5810) JNDIPermission is based in a private module

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-5810?page=com.atlassian.jira.plugin.... ] Ivo Studensky reassigned WFLY-5810: ----------------------------------- Assignee: David Lloyd (was: Ivo Studensky) > JNDIPermission is based in a private module > ------------------------------------------- > > Key: WFLY-5810 > URL: https://issues.jboss.org/browse/WFLY-5810 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 10.0.0.CR4 > Reporter: Ivo Studensky > Assignee: David Lloyd > > At the moment {{JndiPermission}} is based in {{org.jboss.as.naming}} module which is private. Because of this it effectively cannot be used by deployments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5810) JNDIPermission is based in a private module

by Ivo Studensky (JIRA)

Ivo Studensky created WFLY-5810: ----------------------------------- Summary: JNDIPermission is based in a private module Key: WFLY-5810 URL: https://issues.jboss.org/browse/WFLY-5810 Project: WildFly Issue Type: Bug Components: Naming Affects Versions: 10.0.0.CR4 Reporter: Ivo Studensky At the moment {{JndiPermission}} is based in {{org.jboss.as.naming}} module which is private. Because of this it effectively cannot be used by deployments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015