August 2020 - jboss-jira - Jboss List Archives

[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 edited comment on WFCORE-5013 at 8/31/20 11:40 AM: --------------------------------------------------------------- [~fjuma], I've put a comment also [in issue there already|https://issues.redhat.com/browse/JBEAP-19607?focusedCommentId=144...], but commenting here too to be sure message is propagated: Based on the info in https://access.redhat.com/articles/2026253 - I believe that we shall also remove natives for Solaris x86_64 as this is not supported since EAP7.3.0.GA anymore. We support only Solaris SPARC64 since EAP7.3.0.GA. TL;DR; Remove native builds for *Solaris x86_64* from the release too. was (Author: jstourac): [~fjuma], I've put a comment also [in issue there already|https://issues.redhat.com/browse/JBEAP-19607?focusedCommentId=144...], but commenting here too to be sure message is propagated: Based on the info in https://access.redhat.com/articles/2026253 - I believe that we shall also remove natives for Solaris x86_64 as this is not supported since EAP7.3.0.GA anymore. We support only Solaris SPARC64 since EAP7.3.0.GA. TL;DR; Remove native builds for Solaris x86_64 from the release too. > 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: 13.0.0.Final > > > We should remove the wildfly-openssl-linux-i386 and the wildfly-openssl-windows-i386 bindings for WildFly Core 13.0.0.Final (i.e., WildFly 21 Final). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

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 commented on WFCORE-5013: ------------------------------------- [~fjuma], I've put a comment also [in issue there already|https://issues.redhat.com/browse/JBEAP-19607?focusedCommentId=144...], but commenting here too to be sure message is propagated: Based on the info in https://access.redhat.com/articles/2026253 - I believe that we shall also remove natives for Solaris x86_64 as this is not supported since EAP7.3.0.GA anymore. We support only Solaris SPARC64 since EAP7.3.0.GA. TL;DR; Remove native builds for Solaris x86_64 from the release too. > 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: 13.0.0.Final > > > We should remove the wildfly-openssl-linux-i386 and the wildfly-openssl-windows-i386 bindings for WildFly Core 13.0.0.Final (i.e., WildFly 21 Final). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode

by Vladimir Grabarchuk (Jira)

[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ] Vladimir Grabarchuk commented on WFCORE-4291: --------------------------------------------- Thanks for the update. Does that mean it will be available *in* *WildFly 22*? > Restore legacy (not "graceful") startup mode > -------------------------------------------- > > Key: WFCORE-4291 > URL: https://issues.redhat.com/browse/WFCORE-4291 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Reporter: Vladimir Grabarchuk > Assignee: Brian Stansberry > Priority: Major > > Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components. > The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether. > If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

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: -------------------------------- This issue is probably moot, as the above assumption is incorrect: an ObjectMessage marshals its object payload directly to an output stream, and does *not* preceed it with a length. Verifying... > 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)

5 years, 1 month

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 updated JGRP-2285: --------------------------- Description: 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. was: 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 serilization 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. > 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)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFWIP-341) Bootable JAR - Legacy patching

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFWIP-341?page=com.atlassian.jira.plugin... ] Jean Francois Denise updated WFWIP-341: --------------------------------------- Description: A user should be able to apply legacy patches when building a bootable JAR. The maven plugin offers a "legacy-patch-cli-script" configuration item to reference a CLI script that contains patch command(s). For example: "patch apply patch-oneoff1.zip --override-all patch apply patch-oneoff2.zip --override-all patch info --json-output" Documentation of the legacy-patch-cli-script makes it clear that the option "--override-all" can be required when trimming the server with Galleon. In order to optimize the server content, the configuration item "legacy-patch-clean-up" (false by default), can be set to remove unused patch related content (should be tech-preview feature for XP 2.0): * <JBOSS_HOME>/.installation/patches directory is removed * Patched modules original locations in base layer are removed. They are not needed, .overlays content override them. * New modules added by the patch that are not referenced by the existing or patched modules graph are deleted. * overlays directories that are not present in the .overlays file are removed (can occur when multiple patches are applied). Advantages of optimization: * Smaller JAR * Fix unwanted optional module dependencies that would happen with patch. was: A user should be able to apply legacy patches when building a bootable JAR. The maven plugin offers a "legacy-patch-cli-script" configuration item to reference a CLI script that contains patch command(s). For example: "patch apply patch-oneoff1.zip --override-all patch apply patch-oneoff2.zip --override-all patch info --json-output" Documentation of the legacy-patch-cli-script makes it clear that the option "--override-all" can be required when trimming the server with Galleon. In order to optimize the server content, the configuration item "legacy-patch-clean-up" (false by default), can be set to remove unused patch related content: * <JBOSS_HOME>/.installation/patches directory is removed * Patched modules original locations in base layer are removed. They are not needed, .overlays content override them. * New modules added by the patch that are not referenced by the existing or patched modules graph are deleted. * overlays directories that are not present in the .overlays file are removed (can occur when multiple patches are applied). > Bootable JAR - Legacy patching > ------------------------------ > > Key: WFWIP-341 > URL: https://issues.redhat.com/browse/WFWIP-341 > Project: WildFly WIP > Issue Type: Enhancement > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > A user should be able to apply legacy patches when building a bootable JAR. > The maven plugin offers a "legacy-patch-cli-script" configuration item to reference a CLI script that contains patch command(s). For example: > "patch apply patch-oneoff1.zip --override-all > patch apply patch-oneoff2.zip --override-all > patch info --json-output" > Documentation of the legacy-patch-cli-script makes it clear that the option "--override-all" can be required when trimming the server with Galleon. > In order to optimize the server content, the configuration item "legacy-patch-clean-up" (false by default), can be set to remove unused patch related content (should be tech-preview feature for XP 2.0): > * <JBOSS_HOME>/.installation/patches directory is removed > * Patched modules original locations in base layer are removed. They are not needed, .overlays content override them. > * New modules added by the patch that are not referenced by the existing or patched modules graph are deleted. > * overlays directories that are not present in the .overlays file are removed (can occur when multiple patches are applied). > Advantages of optimization: > * Smaller JAR > * Fix unwanted optional module dependencies that would happen with patch. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5240) Remove MVEL from Drools

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5240?page=com.atlassian.jira.plug... ] Luca Molteni resolved DROOLS-5240. ---------------------------------- Resolution: Duplicate Issue > Remove MVEL from Drools > ----------------------- > > Key: DROOLS-5240 > URL: https://issues.redhat.com/browse/DROOLS-5240 > Project: Drools > Issue Type: Epic > Components: core engine > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: MDP_BRAINFARTS > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFWIP-341) Bootable JAR - Legacy patching

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-341: ------------------------------------------ Summary: Bootable JAR - Legacy patching Key: WFWIP-341 URL: https://issues.redhat.com/browse/WFWIP-341 Project: WildFly WIP Issue Type: Enhancement Reporter: Jean Francois Denise Assignee: Jean Francois Denise A user should be able to apply legacy patches when building a bootable JAR. The maven plugin offers a "legacy-patch-cli-script" configuration item to reference a CLI script that contains patch command(s). For example: "patch apply patch-oneoff1.zip --override-all patch apply patch-oneoff2.zip --override-all patch info --json-output" Documentation of the legacy-patch-cli-script makes it clear that the option "--override-all" can be required when trimming the server with Galleon. In order to optimize the server content, the configuration item "legacy-patch-clean-up" (false by default), can be set to remove unused patch related content: * <JBOSS_HOME>/.installation/patches directory is removed * Patched modules original locations in base layer are removed. They are not needed, .overlays content override them. * New modules added by the patch that are not referenced by the existing or patched modules graph are deleted. * overlays directories that are not present in the .overlays file are removed (can occur when multiple patches are applied). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5587) SceSim requires an F5 and full Build when testing and importing DMN model

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5587?page=com.atlassian.jira.plug... ] Toni Rikkola reassigned DROOLS-5587: ------------------------------------ Assignee: Yeser Amer (was: Toni Rikkola) > SceSim requires an F5 and full Build when testing and importing DMN model > ------------------------------------------------------------------------- > > Key: DROOLS-5587 > URL: https://issues.redhat.com/browse/DROOLS-5587 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Reporter: Matteo Mortari > Assignee: Yeser Amer > Priority: Major > Attachments: Screenshot 2020-08-20 at 09.39.37.png > > > Create in BC 2 DMN files, when creating the importing model Save but don't build. > Create SceSim for the importing model. > Execution works but pop-up if failed values won't show actual values. > !Screenshot 2020-08-20 at 09.39.37.png|thumbnail! > (on mouseover no pop, clicking view alerts nothing happens) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13810?page=com.atlassian.jira.plugi... ] Paul Ferraro reassigned WFLY-13810: ----------------------------------- Assignee: Paul Ferraro (was: Brian Stansberry) > Intermittent failure in ExternalizerTestCase > -------------------------------------------- > > Key: WFLY-13810 > URL: https://issues.redhat.com/browse/WFLY-13810 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

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 August 2020