February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1408) Basic Authentication does not mention SSL

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1408?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-1408: ---------------------------------------- The community documentation is editable by members of the community so feel free to update, although as we are not up to WildFly 10 edits may be most effective against the most recent major version in the docs. > Basic Authentication does not mention SSL > ----------------------------------------- > > Key: WFLY-1408 > URL: https://issues.jboss.org/browse/WFLY-1408 > Project: WildFly > Issue Type: Bug > Components: Documentation > Reporter: floyd floyd > Assignee: Zach Rhoads > > In the following documentation Basic Authentication is suggested. I have two comments: > - The documentation should clearly state that SSL (so HTTPS) should be used when using Basic authentication or Digest authentication. Usernames and Passwords will be sent in Cleartext in every single HTTP request to the server if SSL is not used when using Basic authentication. Which is clearly a security issue. > - The documentation should suggest Digest authentication rather than Basic authentication. > https://docs.jboss.org/author/display/WFLY8/WS-Security#WS-Security-Authe... > The same problem exists for the AS7 documentation: > https://docs.jboss.org/author/display/AS7/Developer+Guide#DeveloperGuide-... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2009) TCP/TCP_NIO: make SO_REUSEADDR configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2009?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2009: -------------------------------- Copied code for solution from ISPN-6099: {noformat} while(port in range) channel=ServerSocketChanel.open(); channel.bind(addr,port); if(exception) -> port++ and continue {noformat} > TCP/TCP_NIO: make SO_REUSEADDR configurable > ------------------------------------------- > > Key: JGRP-2009 > URL: https://issues.jboss.org/browse/JGRP-2009 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8, 4.0 > > > Before binding a {{ServerSocket}} or {{ServerSocketChannel}}, let the user configure whether of not to reuse addresses by setting option {{SO_REUSEADDR}} (and possibly {{SO_REUSEPORT}}?). > See https://issues.jboss.org/browse/ISPN-6099 for details -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1914: --------------------------- Fix Version/s: 4.1 (was: 4.0) Pushed to 4.1. > S3_PING doesn't work with S3 buckets created in Frankfurt region > ----------------------------------------------------------------- > > Key: JGRP-1914 > URL: https://issues.jboss.org/browse/JGRP-1914 > Project: JGroups > Issue Type: Bug > Reporter: Gleb Leonov > Assignee: Bela Ban > Fix For: 4.1 > > Attachments: AWS4.png > > > I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2017. ---------------------------- Resolution: Done I removed 1 copy of a byte[] buffer ({{new_payload}}) which was not needed. If this is not what you had in mind, please reopen (in 4.1). > Optimize COMPRESS protocol by pooling / re-using byte array/buffer > ------------------------------------------------------------------ > > Key: JGRP-2017 > URL: https://issues.jboss.org/browse/JGRP-2017 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.4.5, 3.6.7 > Environment: Wildfly 8.2.1.Final (JGroups 3.4.5) > Reporter: Mathieu Lachance > Assignee: Bela Ban > Fix For: 3.6.8, 4.0 > > > I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final. > Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat. > The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector. > When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great). > This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum. > Here is some notable classes of the Netty implementation: > https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects? > Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them? > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2017: -------------------------------- I'm only going to remove the {{new_payload}} copy, but we cannot replace the payload of messages due to JGRP-867. > Optimize COMPRESS protocol by pooling / re-using byte array/buffer > ------------------------------------------------------------------ > > Key: JGRP-2017 > URL: https://issues.jboss.org/browse/JGRP-2017 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.4.5, 3.6.7 > Environment: Wildfly 8.2.1.Final (JGroups 3.4.5) > Reporter: Mathieu Lachance > Assignee: Bela Ban > Fix For: 3.6.8, 4.0 > > > I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final. > Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat. > The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector. > When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great). > This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum. > Here is some notable classes of the Netty implementation: > https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects? > Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them? > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1399) Failure when resolving an expression with the default value containing a '$' at the end

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1399?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-1399: ------------------------------------------- Currently doubling $ only works for escaping ${ if we look into tests and the expression parser. > Failure when resolving an expression with the default value containing a '$' at the end > --------------------------------------------------------------------------------------- > > Key: WFCORE-1399 > URL: https://issues.jboss.org/browse/WFCORE-1399 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Valentin Maechler > Assignee: ehsavoie Hugonnet > Attachments: ExpressionResolver.java, ExpressionResolverUnitTestCase.java > > > Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value. > e.g. {code} > value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1399) Failure when resolving an expression with the default value containing a '$' at the end

by Valentin Maechler (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1399?page=com.atlassian.jira.plugi... ] Valentin Maechler commented on WFCORE-1399: ------------------------------------------- Please check the last entry of WFCORE-1399 and runt te described test on your side. This is currently a major issue on our side. > Failure when resolving an expression with the default value containing a '$' at the end > --------------------------------------------------------------------------------------- > > Key: WFCORE-1399 > URL: https://issues.jboss.org/browse/WFCORE-1399 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Valentin Maechler > Assignee: ehsavoie Hugonnet > Attachments: ExpressionResolver.java, ExpressionResolverUnitTestCase.java > > > Can not add a JNDI / naming entry which contains a "$" sign at the end of its default value. > e.g. {code} > value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}" > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1066) Remove not needed "wrap"s in drools-karaf-features

by Petr Široký (JIRA)

Petr Široký created DROOLS-1066: ----------------------------------- Summary: Remove not needed "wrap"s in drools-karaf-features Key: DROOLS-1066 URL: https://issues.jboss.org/browse/DROOLS-1066 Project: Drools Issue Type: Enhancement Components: integration Affects Versions: 6.4.0.Beta1 Reporter: Petr Široký Assignee: Petr Široký drools-karaf-features (https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-o...) use wrap protocol for bundles where it should not be needed (e.g. for other KIE artifacts which should already contain OSGi metadata). The file needs to be reviewed and all useless wraps have to be removed (they only make things more confusing). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-252) Javaassist problem with Test class having inheritance when used with PoweMock

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-252?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-252: --------------------------------------- {{Caused by: java.lang.RuntimeException: java.io.IOException: invalid constant type: 18}} This looks strange. Javassist 3.19 should produce something like {{invalid constant type: 18 at ??}}. Are you really using 3.19? > Javaassist problem with Test class having inheritance when used with PoweMock > ----------------------------------------------------------------------------- > > Key: JASSIST-252 > URL: https://issues.jboss.org/browse/JASSIST-252 > Project: Javassist > Issue Type: Bug > Environment: Java Version 7 with below JARs > cglib-nodep-2.2.2.jar > javassist-3.20.0-GA.jar > junit-4.12.jar > mockito-all-1.10.19.jar > objenesis-2.1.jar > powermock-mockito-1.6.3-full.jar > Reporter: Shailendra Yadav > Assignee: Shigeru Chiba > > https://github.com/jayway/powermock/issues/583 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-426) Release WildFly Elytron 1.1.0.Beta4

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-426: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta4 Key: ELY-426 URL: https://issues.jboss.org/browse/ELY-426 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta4 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 February 2016