September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2289) FRAG4: handle ObjectMessage whose size() method is incorrect

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2289?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2289: -------------------------------- Test is {{ObjectMessageTest.testIncorrectSizeWithFRAG4()}} > FRAG4: handle ObjectMessage whose size() method is incorrect > ------------------------------------------------------------ > > Key: JGRP-2289 > URL: https://issues.redhat.com/browse/JGRP-2289 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > When an ObjectMessage has a {{SizeStreamable}} object whose size() returns more bytes than are actually written, {{FRAG4}} will block on reading of the last fragment. Example: size() returns 27 bytes (LENGTH), but we only write 20 bytes, then {{readFully()}} (used to read the fragments) will throw an exception (EOF, IIRC). > To fix this, {{FragmentedMessage.writeTo()}} could do the following: > * Check if DataOutput is of type ByteArrayDataOutputStream. This is almost always the case as this is used on the bundler base class. If not -> use the current code path > * Remember the current position > * Write LENGTH bytes (27 in the example above) > * Call obj.writeTo(out) > * If the current position is *not* equal to the remembered position + LENGTH: > ** Position the output stream back to the remembered position and write the correct length ACTUAL bytes (20) as an int > Obviously, this only works for DataOutput implementations that support position(), but with most bundlers using ByteArrayDataOutputStream, this should be the case most of the time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[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)

4 years, 3 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)

4 years, 3 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)

4 years, 3 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)

4 years, 3 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)

4 years, 3 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)

4 years, 3 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)

4 years, 3 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)

4 years, 3 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)

4 years, 3 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