September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5643) Consider isolating integration tests of DMN->PMML into specific module

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5643: -------------------------------------- Summary: Consider isolating integration tests of DMN->PMML into specific module Key: DROOLS-5643 URL: https://issues.redhat.com/browse/DROOLS-5643 Project: Drools Issue Type: Task Reporter: Matteo Mortari Assignee: Jiri Petrlik Please consider isolating the integration test for DMN->PMML https://github.com/kiegroup/droolsjbpm-integration/tree/master/kie-server... into their own test modules, please. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-355) Bootable JAR - scripts in bin folder of the server installation directory are not executable

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-355?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFWIP-355: ---------------------------------------- [~tommaso-borgato] The PR has been merged, I assume over to you now to verify? FYI a new tag of WildFly Core is due fairly shortly which will contain the fix. > Bootable JAR - scripts in bin folder of the server installation directory are not executable > -------------------------------------------------------------------------------------------- > > Key: WFWIP-355 > URL: https://issues.redhat.com/browse/WFWIP-355 > Project: WildFly WIP > Issue Type: Bug > Reporter: Tommaso Borgato > Assignee: Jean Francois Denise > Priority: Major > > Related RFE: EAP7-1385 > Scripts in the bin folder of the server's installation directory are not executable; > If you start the server like the following: > {noformat} > java -jar target/default-hollow-jar-bootable.jar --install-dir=/tmp/wildfly-bootable-server-hollow-jar > {noformat} > and the look into the bin folder: > {noformat} > $ ls -ltr /tmp/wildfly-bootable-server-hollow-jar/bin > total 1520 > -rw-rw-r--. 1 hudson hudson 2362 Sep 11 10:11 vault.sh > -rw-rw-r--. 1 hudson hudson 709 Sep 11 10:11 vault.ps1 > -rw-rw-r--. 1 hudson hudson 2269 Sep 11 10:11 vault.bat > -rw-rw-r--. 1 hudson hudson 823 Sep 11 10:11 common.bat > -rw-rw-r--. 1 hudson hudson 1933 Sep 11 10:11 jboss-cli-logging.properties > -rw-rw-r--. 1 hudson hudson 3271 Sep 11 10:11 jboss-cli.bat > -rw-rw-r--. 1 hudson hudson 792 Sep 11 10:11 common.sh > -rw-rw-r--. 1 hudson hudson 11549 Sep 11 10:11 common.ps1 > -rw-rw-r--. 1 hudson hudson 893 Sep 11 10:11 jboss-cli.ps1 > -rw-rw-r--. 1 hudson hudson 1793 Sep 11 10:11 elytron-tool.sh > -rw-rw-r--. 1 hudson hudson 1079 Sep 11 10:11 elytron-tool.ps1 > -rw-rw-r--. 1 hudson hudson 1710 Sep 11 10:11 elytron-tool.bat > -rw-rw-r--. 1 hudson hudson 2392 Sep 11 10:11 add-user.sh > -rw-rw-r--. 1 hudson hudson 3035 Sep 11 10:11 jboss-cli.xml > -rw-rw-r--. 1 hudson hudson 2635 Sep 11 10:11 jboss-cli.sh > -rw-rw-r--. 1 hudson hudson 1069 Sep 11 10:11 add-user.ps1 > -rw-rw-r--. 1 hudson hudson 2444 Sep 11 10:11 add-user.properties > -rw-rw-r--. 1 hudson hudson 2417 Sep 11 10:11 add-user.bat > -rw-rw-r--. 1 hudson hudson 12843 Sep 11 10:11 standalone.sh > -rw-rw-r--. 1 hudson hudson 1624 Sep 11 10:11 standalone.ps1 > -rw-rw-r--. 1 hudson hudson 3226 Sep 11 10:11 standalone.conf.ps1 > -rw-rw-r--. 1 hudson hudson 3402 Sep 11 10:11 standalone.conf.bat > -rw-rw-r--. 1 hudson hudson 2965 Sep 11 10:11 standalone.conf > -rw-rw-r--. 1 hudson hudson 9576 Sep 11 10:11 standalone.bat > -rw-rw-r--. 1 hudson hudson 49 Sep 11 10:11 product.conf > -rw-rw-r--. 1 hudson hudson 49721 Sep 11 10:11 launcher.jar > -rw-rw-r--. 1 hudson hudson 1369074 Sep 11 10:11 wildfly-elytron-tool.jar > {noformat} > you can see e.g. jboss-cli.sh is not executable -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5010) Startup error messages caused by expression where expressions are not allowed are confusing

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5010?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-5010: ------------------------------------- Fix Version/s: 13.0.0.Final > Startup error messages caused by expression where expressions are not allowed are confusing > ------------------------------------------------------------------------------------------- > > Key: WFCORE-5010 > URL: https://issues.redhat.com/browse/WFCORE-5010 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Ondrej Chaloupka > Assignee: Lukas Vydra > Priority: Minor > Fix For: 13.0.0.Beta6, 13.0.0.Final > > > When a property expression is used at place where expression usage is not allowed then error message which is shown is quite confusing. From user point of view (especially the newcomer) it would be nice if the error message shows the real reason - usage of expression at place where is not permitted. > Maybe CLI could warn on usage of expression on place where is not allowed too. > Documentation recommends configuration with CLI, editing of XML file is common too. More of it there are some tasks which are harder to be done with CLI and editing XML is faster/easier. > Examples: > Setting > {code} > /subsystem=ee/managed-executor-service=default:write-attribute(name=context-service, value="${my.context.service}") > {code} > ends with this error message during startup > {code} > 14:13:21,076 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "ee"), > ("managed-executor-service" => "default") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.concurrent.ee.context.service.${my.context.service}"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.concurrent.ee.executor.default is missing [jboss.concurrent.ee.context.service.${my.context.service}]"]} > {code} > another confusion is setting name of host in {{host-slave.xml}} file. When set as > {code} > <host xmlns="urn:jboss:domain:4.2" host="${host.name}"> > {code} > then NullPointerException is thrown. > {code} > [Host Controller] 14:18:45,238 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.host.controller.HostControllerConfigurationPersister.load(HostControllerConfigurationPersister.java:188) > at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:594) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) > at java.lang.Thread.run(Thread.java:745)[Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError > at [row,col]:[3,1][Host Controller] Message: WFLYCTL0197: Unexpected attribute 'host' encountered > at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117) > at org.jboss.as.host.controller.parsing.HostXml_4.readHostElement(HostXml_4.java:311) > at org.jboss.as.host.controller.parsing.HostXml_4.readElement(HostXml_4.java:170) > at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:79) > at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:50) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) ... 4 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13855) remote-cache-container protocol-version allowed values contains last protocol version twice

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13855?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13855: ---------------------------------- Affects Version/s: 20.0.1.Final 20.0.0.Final > remote-cache-container protocol-version allowed values contains last protocol version twice > ------------------------------------------------------------------------------------------- > > Key: WFLY-13855 > URL: https://issues.redhat.com/browse/WFLY-13855 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 21.0.0.Beta1 > > > Clearly because of {{org.infinispan.client.hotrod.ProtocolVersion#PROTOCOL_VERSION_AUTO}} plus there is no pruning in place. > Fix is to use {{org.jboss.as.clustering.controller.validation.EnumValidator#EnumValidator(java.lang.Class<E>, java.util.EnumSet<E>)}} instead. > {code:json} > "protocol-version" => { > "type" => STRING, > "description" => "This property defines the protocol version that this client should use.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => "3.0", > "allowed" => [ > "2.0", > "2.1", > "2.2", > "2.3", > "2.4", > "2.5", > "2.6", > "2.7", > "2.8", > "2.9", > "3.0", > "3.0" > ], > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13865) Enable switching Galleon pack Maven coordinates for the Galleon layers used in the clustering tests

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13865?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13865: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13566 > Enable switching Galleon pack Maven coordinates for the Galleon layers used in the clustering tests > --------------------------------------------------------------------------------------------------- > > Key: WFLY-13865 > URL: https://issues.redhat.com/browse/WFLY-13865 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Major > > The Galleon layers tests for clustering are using two galleon packs, the one for testing to bring in web-clustering and the full Galleon pack. > This configuration is not properly testing the switching of the Galleon packs under test by the CI Jobs. > The take here is to provide this capability replacing the full one by using the Maven properties passed by the CI Job, e.g: > {code:java} > <feature-pack> > <groupId>${testsuite.ee.galleon.pack.groupId}</groupId> > <artifactId>${testsuite.ee.galleon.pack.artifactId}</artifactId> > <version>${testsuite.ee.galleon.pack.version}</version> > <inherit-configs>false</inherit-configs> > <inherit-packages>false</inherit-packages> > </feature-pack> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5642) Replace com.sun.jaxb with org.glassfish.jaxb dependencies

by Marek Novotny (Jira)

[ https://issues.redhat.com/browse/DROOLS-5642?page=com.atlassian.jira.plug... ] Marek Novotny reassigned DROOLS-5642: ------------------------------------- Assignee: (was: Ant Stephenson) > Replace com.sun.jaxb with org.glassfish.jaxb dependencies > --------------------------------------------------------- > > Key: DROOLS-5642 > URL: https://issues.redhat.com/browse/DROOLS-5642 > Project: Drools > Issue Type: Task > Components: build > Reporter: Marek Novotny > Priority: Major > > There is a mix of com.sun.jaxb dependencies and new RI packaged org.glassfish.jaxb dependencies see documentation for RI https://javaee.github.io/jaxb-v2/doc/user-guide/ch03.html#deployment-mave... > We should unify on one set of JAXB API/runtime to not mix more dependencies with the same classes. Now it requires to dance in between duplicatedClasses with exclusions. > New versions of hibernate, cxf references jakarta jaxb or org.glassfish.jaxb -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5642) Replace com.sun.jaxb with org.glassfish.jaxb dependencies

by Marek Novotny (Jira)

Marek Novotny created DROOLS-5642: ------------------------------------- Summary: Replace com.sun.jaxb with org.glassfish.jaxb dependencies Key: DROOLS-5642 URL: https://issues.redhat.com/browse/DROOLS-5642 Project: Drools Issue Type: Task Components: build Reporter: Marek Novotny Assignee: Ant Stephenson There is a mix of com.sun.jaxb dependencies and new RI packaged org.glassfish.jaxb dependencies see documentation for RI https://javaee.github.io/jaxb-v2/doc/user-guide/ch03.html#deployment-mave... We should unify on one set of JAXB API/runtime to not mix more dependencies with the same classes. Now it requires to dance in between duplicatedClasses with exclusions. New versions of hibernate, cxf references jakarta jaxb or org.glassfish.jaxb -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ] Sonia Zaldana edited comment on WFCORE-5133 at 9/14/20 4:58 PM: ---------------------------------------------------------------- The issue has to do with the [JDK8HackALPNProvider|[https://github.com/undertow-io/undertow/blob/master.... Specifically, with its use of the [ALPNHackSSLEngine|[https://github.com/undertow-io/undertow/blob/master/co...]. The hack tries to find the field "handshaker" in SSLEngineImpl. This class has been refactored in JDK 8 version 261, and it no longer contains that field leading to a failure. Attempting to use the JDK 9 provider instead by setting the system property "io.undertow.protocols.alpn.jdk8" to true, as suggested [here|[https://github.com/undertow-io/undertow/blob/master/core/src/main/j... still does not fix the issue. Although, the JDK 9 provider is correctly loaded in the ALPNClientSelector, the issue then seems to be in [AlpnOpenListener|[https://github.com/undertow-io/undertow/blob/master/cor...] where it fails again to get the JDK 9 provider, as the class is being loaded multiple times and the system property is not always true. [~flavia.rainone], I was wondering whether you had any thoughts on what approach to take to fix this? Thanks for your help. was (Author: szaldana): The issue has to do with the [JDK8HackALPNProvider|[https://github.com/undertow-io/undertow/blob/master.... Specifically, with its use of the [ALPNHackSSLEngine|[https://github.com/undertow-io/undertow/blob/master/co...]. The hack tries to find the field "handshaker" in SSLEngineImpl. This class has been refactored in JDK 8 version 261, and it no longer contains that field leading to a failure. Attempting to use the JDK 9 provider instead by setting the system property "io.undertow.protocols.alpn.jdk8" to true, as suggested [here|[https://github.com/undertow-io/undertow/blob/master/core/src/main/j... still does not fix the issue. Although, the JDK 9 provider is correctly loaded in the ALPNClientSelector, the issue then seems to be in [AlpnOpenListener|[https://github.com/undertow-io/undertow/blob/master/cor...] where it fails again to get the JDK 9 provider, as the class is being loaded multiple times and the system property is not always true. [~flavia.rainone], I was wondering whether you had any thoughts on what approach to take to fix this? Thanks for your help. > SNICombinedWithALPNTestCase fails with oracle JDK 8 261 > ------------------------------------------------------- > > Key: WFCORE-5133 > URL: https://issues.redhat.com/browse/WFCORE-5133 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Sonia Zaldana > Priority: Major > > Exception while using oracle JDK 261: > > {{at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444) > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439) > at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430) > at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5133) SNICombinedWithALPNTestCase fails with oracle JDK 8 261

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5133?page=com.atlassian.jira.plug... ] Sonia Zaldana commented on WFCORE-5133: --------------------------------------- The issue has to do with the [JDK8HackALPNProvider|[https://github.com/undertow-io/undertow/blob/master.... Specifically, with its use of the [ALPNHackSSLEngine|[https://github.com/undertow-io/undertow/blob/master/co...]. The hack tries to find the field "handshaker" in SSLEngineImpl. This class has been refactored in JDK 8 version 261, and it no longer contains that field leading to a failure. Attempting to use the JDK 9 provider instead by setting the system property "io.undertow.protocols.alpn.jdk8" to true, as suggested [here|[https://github.com/undertow-io/undertow/blob/master/core/src/main/j... still does not fix the issue. Although, the JDK 9 provider is correctly loaded in the ALPNClientSelector, the issue then seems to be in [AlpnOpenListener|[https://github.com/undertow-io/undertow/blob/master/cor...] where it fails again to get the JDK 9 provider, as the class is being loaded multiple times and the system property is not always true. [~flavia.rainone], I was wondering whether you had any thoughts on what approach to take to fix this? Thanks for your help. > SNICombinedWithALPNTestCase fails with oracle JDK 8 261 > ------------------------------------------------------- > > Key: WFCORE-5133 > URL: https://issues.redhat.com/browse/WFCORE-5133 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Sonia Zaldana > Priority: Major > > Exception while using oracle JDK 261: > > {{at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:444) > at io.undertow.client.http.HttpClientConnection.handleError(HttpClientConnection.java:439) > at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:430) > at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:347) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.performSimpleTest(SNICombinedWithALPNTestCase.java:242) > at org.jboss.as.test.integration.security.ssl.sni.SNICombinedWithALPNTestCase.testSimpleViaHostname(SNICombinedWithALPNTestCase.java:220)}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13854) WildFly cannot connect to an infinispan-server cluster requiring authentication using properties

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13854?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13854: ---------------------------------- Priority: Blocker (was: Major) > WildFly cannot connect to an infinispan-server cluster requiring authentication using properties > ------------------------------------------------------------------------------------------------ > > Key: WFLY-13854 > URL: https://issues.redhat.com/browse/WFLY-13854 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Blocker > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 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 September 2020