January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1498) Release WildFly Elytron 1.2.0.Beta12

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1498: ------------------------------------- Summary: Release WildFly Elytron 1.2.0.Beta12 Key: ELY-1498 URL: https://issues.jboss.org/browse/ELY-1498 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta12 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1497) Support Modular Crypt Format (MCF) password in Bcrypt mapper

by Tom Stiemerling (JIRA)

[ https://issues.jboss.org/browse/ELY-1497?page=com.atlassian.jira.plugin.s... ] Tom Stiemerling commented on ELY-1497: -------------------------------------- Discussion thread: https://developer.jboss.org/thread/277056 > Support Modular Crypt Format (MCF) password in Bcrypt mapper > ------------------------------------------------------------ > > Key: ELY-1497 > URL: https://issues.jboss.org/browse/ELY-1497 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Passwords > Affects Versions: 1.1.7.Final > Reporter: Tom Stiemerling > > Currently BCrypt mapper for DB realm does not support MCF format passwords (which does not require explicit salt or iterations): > 17:42:28,328 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("jdbc-realm" => "DatabaseRealm") > ]) - failure description: "WFLYCTL0155: 'salt-index' may not be null" > Support should be added to support MCF password so only single column needed in DB. > Logic: > if (password && !salt && !iterations) > assume MCF format password > else if (password && salt && iterations) > assume BCrypt (b64) password, etc > else > error -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1497) Support Modular Crypt Format (MCF) password in Bcrypt mapper

by Tom Stiemerling (JIRA)

Tom Stiemerling created ELY-1497: ------------------------------------ Summary: Support Modular Crypt Format (MCF) password in Bcrypt mapper Key: ELY-1497 URL: https://issues.jboss.org/browse/ELY-1497 Project: WildFly Elytron Issue Type: Enhancement Components: Passwords Affects Versions: 1.1.7.Final Reporter: Tom Stiemerling Currently BCrypt mapper for DB realm does not support MCF format passwords (which does not require explicit salt or iterations): 17:42:28,328 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("jdbc-realm" => "DatabaseRealm") ]) - failure description: "WFLYCTL0155: 'salt-index' may not be null" Support should be added to support MCF password so only single column needed in DB. Logic: if (password && !salt && !iterations) assume MCF format password else if (password && salt && iterations) assume BCrypt (b64) password, etc else error -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1496) Test PKCS12 KeystoreCredentialStore on non-Oracle JDKs

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1496?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1496: ---------------------------- Summary: Test PKCS12 KeystoreCredentialStore on non-Oracle JDKs (was: Test PKCS12 KeystoreCredentialStore) > Test PKCS12 KeystoreCredentialStore on non-Oracle JDKs > ------------------------------------------------------ > > Key: ELY-1496 > URL: https://issues.jboss.org/browse/ELY-1496 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Affects Versions: 1.2.0.Beta11 > Reporter: Jan Kalina > Priority: Minor > > As part of ELY-1494 was disabled testing with PKCS12 KeyStore on non-oracle JDKs, because following problems: > * IBM and HP (and some older Oracle too) requires provider in signed JAR, which fails on directory of classes used by surefire/junit elytron tests (see ELY-1494) > * * IBM does not allow storing custom objects in PKCS12 KeyStore - allows predefined set of specs/algorithms - this cannot be workarounded currently > This testing should be re-enabled if this will be fixed in mentioned JDKs. > The first problem can be solved on our side too: > * rework junit testing to operate on generated (and possibly signed) elytron JAR > * test this from different module, outside of elytron - when elytron is dependency, it is packed in JAR -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1496) Test PKCS12 KeystoreCredentialStore

by Jan Kalina (JIRA)

Jan Kalina created ELY-1496: ------------------------------- Summary: Test PKCS12 KeystoreCredentialStore Key: ELY-1496 URL: https://issues.jboss.org/browse/ELY-1496 Project: WildFly Elytron Issue Type: Task Components: Credential Store Affects Versions: 1.2.0.Beta11 Reporter: Jan Kalina Priority: Minor As part of ELY-1494 was disabled testing with PKCS12 KeyStore on non-oracle JDKs, because following problems: * IBM and HP (and some older Oracle too) requires provider in signed JAR, which fails on directory of classes used by surefire/junit elytron tests (see ELY-1494) * * IBM does not allow storing custom objects in PKCS12 KeyStore - allows predefined set of specs/algorithms - this cannot be workarounded currently This testing should be re-enabled if this will be fixed in mentioned JDKs. The first problem can be solved on our side too: * rework junit testing to operate on generated (and possibly signed) elytron JAR * test this from different module, outside of elytron - when elytron is dependency, it is packed in JAR -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2232. ---------------------------- Resolution: Done I fixed the issue, let me know if this works for you > Using NATIVE_S3_PING old members doesn't seem to get removed > ------------------------------------------------------------ > > Key: JGRP-2232 > URL: https://issues.jboss.org/browse/JGRP-2232 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.7 > Environment: Spring Boot / Boxfuse / AWS > Reporter: Jesper Blomquist > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.10 > > > According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us. > Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!). > Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age): > 967 elements: > {noformat} > i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old) > i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old) > i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old) > i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old) > i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old) > i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old) > i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old) > i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old) > i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old) > i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old) > i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old) > i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old) > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-132: --------------------------------------- What I have now is just a simple holder type of class in jboss-logging using a {{HashMap}}. For WildFly we shouldn't see too much of a performance impact since loggers are static. Non-static loggers might see a performance impact though. A locale prepended key is an interesting idea. That would likely help with fallback messages too. > Support low-metaspace bundles/classes > ------------------------------------- > > Key: LOGTOOL-132 > URL: https://issues.jboss.org/browse/LOGTOOL-132 > Project: Log Tool > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Critical > > Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes. > Introduce a leaner variation on generated classes with the following requirements: > * The generated class must be {{final}} > * The generated class must contain no message strings > * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information > * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this > Here are some implementation ideas: > * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message > ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string > ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated > ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale) > * Option 2: The resource files contain key-value pairs, with the key being equal to the method name > ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales > ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9646) Wsconsume is not able to generate jar file from wsdl

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-9646?page=com.atlassian.jira.plugin.... ] Alessio Soldano reassigned WFLY-9646: ------------------------------------- Assignee: R Searls (was: Alessio Soldano) > Wsconsume is not able to generate jar file from wsdl > ---------------------------------------------------- > > Key: WFLY-9646 > URL: https://issues.jboss.org/browse/WFLY-9646 > Project: WildFly > Issue Type: Bug > Components: Scripts, Web Services > Reporter: Marek Kopecký > Assignee: R Searls > Priority: Blocker > Fix For: 12.0.0.Alpha1 > > > *Description:* > Wsconsume is able to generate jar file from wsdl on WildFly 11. On WildFly master, wsconsume doesn't create any files in "out" folder. It leads to Exception from wsdl2java tool. > *Steps to reproduce:* > # cd $\{JBOSS_HOME\}/bin > # # download Echo1.wsdl, Echo1Service.wsdl and Echo1Service_schema1.xsd files, these files are attached to this jira > # mkdir out > # ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl > *Actual results:* > {noformat} > [mkopecky@dhcp-10-40-4-226 bin]$ ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl > Could not find log4j.properties or log4j.xml configuration, logging to console. > Loading FrontEnd jaxws ... > Loading DataBinding jaxb ... > wsdl2java -clientjar wsClientShort.jar -compile -exsh false -p org.jboss.test.script -d /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583 -verbose -classdir /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out -allowElementReferences file:/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/Echo1Service.wsdl > wsdl2java - Apache CXF 3.1.12 > JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava > org.apache.cxf.tools.common.ToolException: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read") > at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:423) > at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105) > at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113) > at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313) > at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298) > at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108) > at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96) > at org.jboss.modules.Module.run(Module.java:344) > at org.jboss.modules.Main.main(Main.java:525) > Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read") > at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > at java.security.AccessController.checkPermission(AccessController.java:884) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at java.io.File.isDirectory(File.java:844) > at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69) > at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64) > at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785) > at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185) > at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:192) > at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141) > at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:123) > at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:306) > at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164) > at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415) > ... 8 more > [mkopecky@dhcp-10-40-4-226 bin]$ ll out/ > total 0 > [mkopecky@dhcp-10-40-4-226 bin]$ > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7263) Upgrade HttpClient to 4.5.2

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-7263?page=com.atlassian.jira.plugin.... ] Alessio Soldano resolved WFLY-7263. ----------------------------------- Resolution: Out of Date This is now out-of-date (actually, WildFly 11.0.0.Final shipped with HttpClient 4.5.2). > Upgrade HttpClient to 4.5.2 > --------------------------- > > Key: WFLY-7263 > URL: https://issues.jboss.org/browse/WFLY-7263 > Project: WildFly > Issue Type: Component Upgrade > Components: REST, Web Services > Reporter: James Netherton > Assignee: Alessio Soldano > > HttpClient 4.5.2 has been available for a while now. Various projects have started to make use of it. It'd be good if WildFly can upgrade. It'd help with integrating some Camel functionality: > https://github.com/wildfly-extras/wildfly-camel/issues/1357 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2272) [DMN Editor] Move Editor controls inline

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2272?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2272: ----------------------------------- Tester: Jozef Marko > [DMN Editor] Move Editor controls inline > ---------------------------------------- > > Key: DROOLS-2272 > URL: https://issues.jboss.org/browse/DROOLS-2272 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Affects Versions: 7.5.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > > Expression Editors have a row of controls to add row, column, change Hit Policy etc. > These all need moving "inline" into the editor itself. The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018