[JBoss JIRA] (WFCORE-3211) Auto more/less in CLI for multi-page output
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-3211:
----------------------------------
Summary: Auto more/less in CLI for multi-page output
Key: WFCORE-3211
URL: https://issues.jboss.org/browse/WFCORE-3211
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Darran Lofthouse
Assignee: Jean-Francois Denise
Where the result of a management operation in the CLI returns multiple screens of output it would be nice if this could be automatically wrapped in a more/less type behaviour.
Similar to how git handles git log compared to how svn handles svn log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-388) On IBM Java 1.8 I am unable to create HTTPS connection whit "TLSv1" openssl cipher string
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-388?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-388 at 8/30/17 6:17 AM:
---------------------------------------------------------
By Steps to reproduce this is *not Elytron issue* - legacy {{security-realm}} is set and elytron's {{ssl-context}} is not defined. Legacy security is used to obtain SSL context.
was (Author: honza889):
By Steps to reproduce this is *not Elytron issue* - legacy {{security-realm}} is set and elytron's {{ssl-context}} is not defined.
> 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
> Attachments: server_debug.log
>
>
> 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
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2061) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2061?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2061:
--------------------------------
The code below passes:
{code:java}
String input="Bela Ban";
byte[] buf=Util.objectToByteBuffer(input);
String tmp=Util.objectFromByteBuffer(buf);
assert tmp.equals(input);
input="Béla Ban";
buf=Util.objectToByteBuffer(input);
tmp=Util.objectFromByteBuffer(buf);
assert tmp.equals(input);
{code}
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2061
> URL: https://issues.jboss.org/browse/JGRP-2061
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Fix For: 4.0.6
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {code:java}
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> {code}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2061) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2061?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2061:
---------------------------
Description:
In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
For example, see objectToByteBuffer lines 561-567:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
{code:java}
case TYPE_STRING:
String str=(String)obj;
int len=str.length();
ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
for(int i=0; i < len; i++)
retval.put((byte)str.charAt(i));
return retval.array();
{code}
This code will incorrectly encode any String with non ASCII encoding.
There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
was:
In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
For example, see objectToByteBuffer lines 561-567:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
{{
case TYPE_STRING:
String str=(String)obj;
int len=str.length();
ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
for(int i=0; i < len; i++)
retval.put((byte)str.charAt(i));
return retval.array();
}}
This code will incorrectly encode any String with non ASCII encoding.
There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2061
> URL: https://issues.jboss.org/browse/JGRP-2061
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Fix For: 4.0.6
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {code:java}
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> {code}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months