October 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11093) WildFly can't be build on Java 11, xts module failure

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-11093?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-11093: ----------------------------------------- Does simply correcting the import ordering in XtsAsLogger fix this? That's the only thing about that commit that looks at all 'wrong' or different from the thousands of other logger methods we've got. > WildFly can't be build on Java 11, xts module failure > ----------------------------------------------------- > > Key: WFLY-11093 > URL: https://issues.jboss.org/browse/WFLY-11093 > Project: WildFly > Issue Type: Bug > Components: Server, XTS > Reporter: Rostislav Svoboda > Assignee: Ondra Chaloupka > Priority: Blocker > Labels: Java11 > > WildFly can't be build on Java 11. > {code} > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project wildfly-xts: Compilation failure > [ERROR] /Users/rsvoboda/git/wildfly/xts/target/generated-sources/annotations/org/jboss/as/xts/logging/XtsAsLogger_$logger.java:[11,22] '.' expected > [ERROR] > {code} > After reverting fix for https://issues.jboss.org/browse/WFLY-9455 I can build the server using Java 11. > https://github.com/wildfly/wildfly/commit/b2674da738af714a05f30464e849544... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2805) Use Xalan from JRE rather than our own fork

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugi... ] Kabir Khan closed WFCORE-2805. ------------------------------ Resolution: Rejected > Use Xalan from JRE rather than our own fork > ------------------------------------------- > > Key: WFCORE-2805 > URL: https://issues.jboss.org/browse/WFCORE-2805 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > > As proposed by [~wolfc] we want to check if we can get rid of maintaining our own fork of Xalan. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2805) Use Xalan from JRE rather than our own fork

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugi... ] Kabir Khan commented on WFCORE-2805: ------------------------------------ WFCORE-4023 replaces WFCORE-2805 and includes all the 2.12.0 fixes which were the motivation for opening WFCORE-2085. However, we still needed to apply changes to make it work in a modular environment (https://github.com/jboss/xerces/tree/jboss-2.12.0.SP02) > Use Xalan from JRE rather than our own fork > ------------------------------------------- > > Key: WFCORE-2805 > URL: https://issues.jboss.org/browse/WFCORE-2805 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > > As proposed by [~wolfc] we want to check if we can get rid of maintaining our own fork of Xalan. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2952) Hierarhical DataSource

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2952?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2952: ---------------------------------- Sprint: (was: 2018 Week 39-41) > Hierarhical DataSource > ---------------------- > > Key: DROOLS-2952 > URL: https://issues.jboss.org/browse/DROOLS-2952 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > > A really useful addition to DataSources would be scoped hierarchy. > Lets say I make DataSource d1, and unit u1 is instantiated with it. > I then want to instantiate d2, where d1 is the parent. I then instantiate u2 with d2. > That means u2 can seemlessly see and react to all the data in d2 and d1. u1 can only see and react to u1. > If u2 does inserts, those go into d2. > If u2 is garbage collected and no references remain on d2, it is also GC'd. This allows a for temporary and local DataSources, scoped to a given unit. > We can then add control structure methods such as: > moveAllToParent() > This would move all the FHs in d2 into d1. We might do this if u2 successfully finishes and d2 is about to be discarded, but we want to keep the results. > For a given DataSuorce we should be able to determine if it's root, or get it's level. We should always be able to get and insert into root, parent, or any numerically specific level. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10188) Setting Undertow default server needs validation of provided server to avoid broken Wildfly configuration

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-10188?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFLY-10188: ------------------------------------ This is still issue for WildFly 14. > Setting Undertow default server needs validation of provided server to avoid broken Wildfly configuration > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-10188 > URL: https://issues.jboss.org/browse/WFLY-10188 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.1.Final, 12.0.0.Final, 13.0.0.Final > Reporter: Pavel Jelinek > Assignee: Stuart Douglas > Priority: Critical > > Undertow server needs default-host to be set to be able to be used as Undertow subsystem default-server otherwise Wildfly would not start due to: > {code} > ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow' are not available: > org.wildfly.undertow.host.test-server.default-host; Possible registration points for this capability: > /subsystem=undertow/server=*/host=* > {code} > This is dangerous as after calling a {{reload}} operation, the server simply fails and crashes. One can accidentaly kill the server with this and \!manual\! fix is necessary to the configuration to be able to start server again. > I think that there should be some check that configuration of the newly created server is complete and valid before it is set as a default server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10188) Setting Undertow default server needs validation of provided server to avoid broken Wildfly configuration

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-10188?page=com.atlassian.jira.plugin... ] Jan Stourac updated WFLY-10188: ------------------------------- Affects Version/s: 13.0.0.Final 14.0.1.Final > Setting Undertow default server needs validation of provided server to avoid broken Wildfly configuration > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-10188 > URL: https://issues.jboss.org/browse/WFLY-10188 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.1.Final, 12.0.0.Final, 13.0.0.Final > Reporter: Pavel Jelinek > Assignee: Stuart Douglas > Priority: Critical > > Undertow server needs default-host to be set to be able to be used as Undertow subsystem default-server otherwise Wildfly would not start due to: > {code} > ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow' are not available: > org.wildfly.undertow.host.test-server.default-host; Possible registration points for this capability: > /subsystem=undertow/server=*/host=* > {code} > This is dangerous as after calling a {{reload}} operation, the server simply fails and crashes. One can accidentaly kill the server with this and \!manual\! fix is necessary to the configuration to be able to start server again. > I think that there should be some check that configuration of the newly created server is complete and valid before it is set as a default server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11096) Stale session data on failover

by tommaso borgato (JIRA)

tommaso borgato created WFLY-11096: -------------------------------------- Summary: Stale session data on failover Key: WFLY-11096 URL: https://issues.jboss.org/browse/WFLY-11096 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 14.0.1.Final, 15.0.0.Alpha1 Reporter: tommaso borgato Assignee: Paul Ferraro Priority: Minor Occured on client. Affected scenarios: eap-7x-failover-ejb-ejbservlet-shutdown-dist-async eap-7x-failover-http-granular-shutdown-repl-sync eap-7x-failover-http-session-jvmkill-dist-sync eap-7x-failover-http-session-jvmkill-repl-sync eap-7x-failover-http-session-shutdown-repl-sync-haproxy eap-7x-failover-http-session-undeploy-dist-sync Client log stacktrace: {code} 2016/09/21 17:28:51:294 EDT [WARN ][Runner - 134] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 42, received 41, Runner: 134> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 42, received 41, Runner: 134 at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133) at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52) at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103) at java.lang.Thread.run(Thread.java:745) {code} Link to client log: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-816: ------------------------------------ Assignee: (was: Jan Kalina) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Priority: Critical > Fix For: 1.7.0.CR3 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-867) Masked password support cryptography usage

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-867?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-867: ------------------------------------ Assignee: (was: Jan Kalina) > Masked password support cryptography usage > ------------------------------------------ > > Key: ELY-867 > URL: https://issues.jboss.org/browse/ELY-867 > Project: WildFly Elytron > Issue Type: Bug > Components: Passwords > Reporter: Zoran Regvart > > I encountered couple of issues with cryptography used for password masking: > * implementation of masked passwords drops initialization vector (IV) randomly generated by the {{javax.crypto.Cipher}} which makes unmasking (decryption) impossible. > * the implementation is using the same algorithm for key derivation and encryption, which is not possible as there is no encryption support in {{javax.crypto.Cipher}} for PKDBF2 family of algorithms, they are supported only in {{javax.crypto.SecretKeyFactory}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1291) Coverity static analysis: Non-Serializable SecurityIdentity is contained in Serializable ElytronAccount

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1291?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1291: ------------------------------------- Assignee: (was: Jan Kalina) > Coverity static analysis: Non-Serializable SecurityIdentity is contained in Serializable ElytronAccount > ------------------------------------------------------------------------------------------------------- > > Key: ELY-1291 > URL: https://issues.jboss.org/browse/ELY-1291 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > > Coverity static analysis found Serializable ElytronAccount contains non-Serializable SecurityIdentity. > https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=86223... > Please resolve this inconsistent situation. > By dev feedback SecurityIdentity can't be made Serializable. Rework to remove SecurityIdentity from ElytronAccount was suggested. > {code:title=hipchat.log} > [3:23 PM] Martin Choma: Shouldn't be SecurityIdentity Serializable? - because of HttpSession replication? > [3:23 PM] Darran Lofthouse: No it can't be > [3:24 PM] Darran Lofthouse: it is backed by implementation as well as state > [3:25 PM] David M. Lloyd: right it would essentially be a security hole to be able to deserialize an identity > [3:26 PM] David M. Lloyd: among other problems > [3:26 PM] Darran Lofthouse: on the far side we restore the identity instead of deserializing it > [3:31 PM] Martin Choma: I got it. Thing is static analyzer is complaining elytron-web ElytronAccount (Serializable class) is referencing SecurityIdentity, but probably problem is ElytronAccount does not have to be mark as Serializable, right? > [3:34 PM] Darran Lofthouse: @MartinChoma we may be able to re-work that and remove the reference to SI > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2018