August 2017 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] (DROOLS-1692) Migrate tests in drools-persistence-jpa module from Bitronix to Narayana

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1692?page=com.atlassian.jira.plugi... ] Tibor Zimányi reassigned DROOLS-1692: ------------------------------------- Assignee: Dominik Hanak (was: Tibor Zimányi) > Migrate tests in drools-persistence-jpa module from Bitronix to Narayana > ------------------------------------------------------------------------ > > Key: DROOLS-1692 > URL: https://issues.jboss.org/browse/DROOLS-1692 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Dominik Hanak > Fix For: 7.3.0.Final > > > Tests in module drools-persistence-jpa must be migrated to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1717?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1717: ---------------------------------- Description: Having a test case like this [1], it sometimes fails on java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] [Near : {... enumValue == AnEnum.SECOND ....}] ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e was: Having a test case like this [1], it sometimes fails on java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] [Near : {... enumValue == AnEnum.SECOND ....}] ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e > Concurrency problems with enum constraints in MVEL > -------------------------------------------------- > > Key: DROOLS-1717 > URL: https://issues.jboss.org/browse/DROOLS-1717 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Labels: concurrency > > Having a test case like this [1], it sometimes fails on > java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] > [Near : {... enumValue == AnEnum.SECOND ....}] > ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. > Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. > [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af > [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 > [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1717: ------------------------------------- Summary: Concurrency problems with enum constraints in MVEL Key: DROOLS-1717 URL: https://issues.jboss.org/browse/DROOLS-1717 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.2.0.Final Reporter: Tibor Zimányi Assignee: Mario Fusco Having a test case like this [1], it sometimes fails on java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] [Near : {... enumValue == AnEnum.SECOND ....}] ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-396) Undertow HTTPS listener does not accept EXPORT40 and EXPORT56 cipher strings

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-396?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-396: ------------------------------ Assignee: Jan Kalina > Undertow HTTPS listener does not accept EXPORT40 and EXPORT56 cipher strings > ---------------------------------------------------------------------------- > > Key: ELY-396 > URL: https://issues.jboss.org/browse/ELY-396 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Reporter: Ondrej Kotek > Assignee: Jan Kalina > Priority: Minor > > Undertow HTTPS listener does not accept EXPORT40 and EXPORT56 cipher strings in enabled-cipher-suites attribute. They are accepted in EAP 6.4. > According to OpenSSL documentation [1], and according to Elytron documentation [2], the cipher strings should be accepted. > [1] https://www.openssl.org/docs/man1.0.2/apps/ciphers.html > [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

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 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

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 Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-388?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-388: -------------------------------- 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-6262) Look into adding reload-required to WildScribe

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6262?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-6262. ------------------------------- Fix Version/s: 11.0.0.Final Resolution: Done added > Look into adding reload-required to WildScribe > ---------------------------------------------- > > Key: WFLY-6262 > URL: https://issues.jboss.org/browse/WFLY-6262 > Project: WildFly > Issue Type: Feature Request > Components: Documentation > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Final > > > It would be useful to see what attributes require reload/restart required and which do not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017