September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5013) Remove the wildfly-openssl i386 and Solaris@x86_64 bindings

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFCORE-5013?page=com.atlassian.jira.plug... ] Jan Stourac updated WFCORE-5013: -------------------------------- Summary: Remove the wildfly-openssl i386 and Solaris@x86_64 bindings (was: Remove the wildfly-openssl i386 bindings) > Remove the wildfly-openssl i386 and Solaris@x86_64 bindings > ----------------------------------------------------------- > > Key: WFCORE-5013 > URL: https://issues.redhat.com/browse/WFCORE-5013 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > Fix For: 14.0.0.Beta1 > > > We should remove the following bindings: > * wildfly-openssl-linux-i386 > * wildfly-openssl-windows-i386 > * wildfly-openssl-solaris-x86_64 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5013) Remove the wildfly-openssl i386 bindings

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFCORE-5013?page=com.atlassian.jira.plug... ] Jan Stourac updated WFCORE-5013: -------------------------------- Description: We should remove the following bindings: * wildfly-openssl-linux-i386 * wildfly-openssl-windows-i386 * wildfly-openssl-solaris-x86_64 was:We should remove the wildfly-openssl-linux-i386 and the wildfly-openssl-windows-i386 bindings. > Remove the wildfly-openssl i386 bindings > ---------------------------------------- > > Key: WFCORE-5013 > URL: https://issues.redhat.com/browse/WFCORE-5013 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > Fix For: 14.0.0.Beta1 > > > We should remove the following bindings: > * wildfly-openssl-linux-i386 > * wildfly-openssl-windows-i386 > * wildfly-openssl-solaris-x86_64 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5612) DMN integrate test example from DMN spec not listed in ADOC

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5612: -------------------------------------- Summary: DMN integrate test example from DMN spec not listed in ADOC Key: DROOLS-5612 URL: https://issues.redhat.com/browse/DROOLS-5612 Project: Drools Issue Type: Task Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Follows up [BXMSDOC-6058] and [DROOLS-5440] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5611) Use DMNContextFPAImpl for DMNRuntime evaluation

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5611: ----------------------------------------- Summary: Use DMNContextFPAImpl for DMNRuntime evaluation Key: DROOLS-5611 URL: https://issues.redhat.com/browse/DROOLS-5611 Project: Drools Issue Type: Enhancement Components: dmn engine Affects Versions: 7.42.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi DROOLS-5517 is implemented like: 1) DMNRuntimeImpl creates a DMNContextImpl from DMNContextFPAImpl 2) DMNRuntimeImpl evaluation goes through with DMNContextImpl 3) Before responding to the client, create DMNContextFPAImpl with OutputSet and return This JIRA aims to use DMNContextFPAImpl for DMNRuntimeImpl evaluation instead of converting to DMNContextImpl. A partial implementation: https://github.com/tkobayas/drools/tree/DROOLS-5517-use-FPA-for-evaluation -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2285) ObjectMessage: handle objects with incorrect size

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2285?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2285. ---------------------------- Resolution: Rejected > ObjectMessage: handle objects with incorrect size > ------------------------------------------------- > > Key: JGRP-2285 > URL: https://issues.redhat.com/browse/JGRP-2285 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > An ObjectMessage accepts objects of type SizeStreamable. When such an object has an incorrect serializableSize() method, the following can happen: > * Say the serialized size is 1000, but serializedSize() returns 1200 > * When the ObjectMessage is serialized, a length of 1200 is written, but then only 1000 bytes are serialized onto the output stream > * On the receiving side, length=1200 is read and a byte array of 1200 is created > * DataInput.readFully() reads 1000 bytes, but then reaches the eof of the stream, trying to read an additional 200 bytes > * An exception is thrown and the reading of the message fails > If we caught the exception, things would work, however this would mask other errors in the object serialization/deserialization code. > If the serialization code was able to mark the position of the output stream, then we could write the *actual number of bytes written* (especially if it differs from serializedSize()); however, DataOutput doesn't give us this option! > Investigate whether simply catching (and ignoring) the EOFException would work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5610) Fix model name inside PMML_MODEL

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5610: ---------------------------------------- Summary: Fix model name inside PMML_MODEL Key: DROOLS-5610 URL: https://issues.redhat.com/browse/DROOLS-5610 Project: Drools Issue Type: Task Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Some model names are wrong inside PMML_MODEL (e.g. NeuralNetwork name should be "NeuralNetwork" and not "NeuralNetworkModel") See http://dmg.org/pmml/v4-4-1 for model names -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2285) ObjectMessage: handle objects with incorrect size

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2285?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2285: -------------------------------- Added {{ObjectMessageTest.testIncorrectSize()}}: as suspected above, this issue is moot, as the object is not preceeded with a length field. > ObjectMessage: handle objects with incorrect size > ------------------------------------------------- > > Key: JGRP-2285 > URL: https://issues.redhat.com/browse/JGRP-2285 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > An ObjectMessage accepts objects of type SizeStreamable. When such an object has an incorrect serializableSize() method, the following can happen: > * Say the serialized size is 1000, but serializedSize() returns 1200 > * When the ObjectMessage is serialized, a length of 1200 is written, but then only 1000 bytes are serialized onto the output stream > * On the receiving side, length=1200 is read and a byte array of 1200 is created > * DataInput.readFully() reads 1000 bytes, but then reaches the eof of the stream, trying to read an additional 200 bytes > * An exception is thrown and the reading of the message fails > If we caught the exception, things would work, however this would mask other errors in the object serialization/deserialization code. > If the serialization code was able to mark the position of the output stream, then we could write the *actual number of bytes written* (especially if it differs from serializedSize()); however, DataOutput doesn't give us this option! > Investigate whether simply catching (and ignoring) the EOFException would work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-342) RESTEasy JAXB end-point on bootable jar return unexpected 400 response

by Marek Kopecky (Jira)

Marek Kopecky created WFWIP-342: ----------------------------------- Summary: RESTEasy JAXB end-point on bootable jar return unexpected 400 response Key: WFWIP-342 URL: https://issues.redhat.com/browse/WFWIP-342 Project: WildFly WIP Issue Type: Bug Reporter: Marek Kopecky Assignee: Jean Francois Denise RFE link: EAP7-1385 RESTEasy JAXB end-point on bootable jar return unexpected 400 response with these security params: {code:xml} <context-param> <param-name>resteasy.document.secure.processing.feature</param-name> <param-value>true</param-value> </context-param> <context-param> <param-name>resteasy.document.secure.disableDTDs</param-name> <param-value>false</param-value> </context-param> <context-param> <param-name>resteasy.document.expand.entity.references</param-name> <param-value>false</param-value> </context-param> {code} Used layers: * jaxrs-server * microprofile-config Although this test is security related, AFAIK this is not related with legacy-security/elytron configuration, because related params are used in javax.xml.parsers.DocumentBuilderFactory directly from RESTEasy. Anyway let me know if I'm wrong. Steps to reproduce: # use installed WF version with reasonable layers, eg: WF_VERSION=21.0.0.Beta1-SNAPSHOT # # git clone git@github.com:marekkopecky/Resteasy.git -b bootable-jar-3-12-secure-processing # cd Resteasy # mvn install -DskipTests -Dcheckstyle.skip=true # cd testsuite # mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml # cd integration-tests # mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=${WF_VERSION} -Dserver.home=placeholder -Dcheckstyle.skip=true -Denforcer.skip -Dcheckstyle.skip=true -Dmaven.test.redirectTestOutputToFile=false I can move these steps outside of TS, but I believe that TS doesn't affects this bootable jar behaviour, so it doesn't seem to be necessary. I see just this unexpected&suspicious console output although I'm not sure whether it's related or not: {noformat} [org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 189; External DTD: Failed to read external DTD 'SecureProcessing_external.dtd', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.] {noformat} cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13490) Galleon layer for web console

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13490?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13490: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/13343, https://github.com/wildfly/wildfly/pull/13520 (was: https://github.com/wildfly/wildfly/pull/13343) > Galleon layer for web console > ----------------------------- > > Key: WFLY-13490 > URL: https://issues.redhat.com/browse/WFLY-13490 > Project: WildFly > Issue Type: Feature Request > Components: Build System, Web Console > Reporter: Jean Francois Denise > Assignee: Yeray Borges Santana > Priority: Major > Fix For: 21.0.0.Beta1 > > > Web console could be exposed as a "web-console" decorator galleon layer. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13818) Increase the test coverage of LayersTestCase for the all layers case

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13818: --------------------------------------- Summary: Increase the test coverage of LayersTestCase for the all layers case Key: WFLY-13818 URL: https://issues.redhat.com/browse/WFLY-13818 Project: WildFly Issue Type: Task Components: Build System, Test Suite Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana Fix For: 21.0.0.Beta1 The LayersTestCase verifies the following: * Verifies the provisioned modules are the expected ones. * Verifies the provisioned server starts successfully. Currently, we have a server provision under test that doesn't add all the layers, the idea of this task is to supply one server provisioning including all the available layers. The WildFly Galleon Layers have an inheritance structure where some layers already include others, instead of check what is already included, the idea on this task is to include all, even if they are already included by another one, Galleon will take care of merging them. In the future, when a new layer is added, we have to add to this all-in-one provision. The idea is to have one all-in-one provision for jpa and all-in-one provision for jpa-distribute. The similar task could be done if we detect additional mutually excludable layers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020