[JBoss JIRA] (WFLY-13815) Make core-tools optional in datasources-web-server layer
by Jean Francois Denise (Jira)
Jean Francois Denise created WFLY-13815:
-------------------------------------------
Summary: Make core-tools optional in datasources-web-server layer
Key: WFLY-13815
URL: https://issues.redhat.com/browse/WFLY-13815
Project: WildFly
Issue Type: Enhancement
Components: Build System
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
This would allow for exclusion of core-tools that is not required in all execution contexts (eg: bootable JAR).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5609) Cannot use as parameter of a function the result of another function receiving a parameter of its own
by Ciprian Chiru (Jira)
Ciprian Chiru created DROOLS-5609:
-------------------------------------
Summary: Cannot use as parameter of a function the result of another function receiving a parameter of its own
Key: DROOLS-5609
URL: https://issues.redhat.com/browse/DROOLS-5609
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.42.0.Final
Reporter: Ciprian Chiru
Assignee: Luca Molteni
Given the following rule:
{code:java}
import java.util.*;
global java.util.Set controlSet;
global org.example.drools.service.DummyService dummyService;
rule "will execute per each Measurement having ID color"
no-loop
when
Measurement( id == "color", $colorVal : val )
String() from dummyService.dummy(dummyService.dummy($colorVal))
then
controlSet.add($colorVal);
end{code}
The compilation fails with:
{code:java}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile-1) on project rules: Compilation failure
[ERROR] .../target/generated-sources/drools-model-compiler/main/java/rules/Rules38bbab4141b64289855d5e28d5f95ca6RuleMethods0.java:[24,111] no suitable method found for from(org.drools.model.Global<org.example.drools.service.DummyService>,org.drools.model.Global<org.example.drools.service.DummyService>,org.drools.model.Variable<java.lang.String>,rules.P4C.LambdaExtractor4CA52645EC5319D0363A23796D4739AE)
[ERROR] method org.drools.model.DSL.<T>from(T) is not applicable
[ERROR] (cannot infer type-variable(s) T
[ERROR] (actual and formal argument lists differ in length))
[ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>) is not applicable
[ERROR] (cannot infer type-variable(s) T
[ERROR] (actual and formal argument lists differ in length))
[ERROR] method org.drools.model.DSL.<T>from(org.drools.model.functions.Function0<T>) is not applicable
[ERROR] (cannot infer type-variable(s) T
[ERROR] (actual and formal argument lists differ in length))
[ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>,org.drools.model.functions.Function1<T,?>) is not applicable
[ERROR] (cannot infer type-variable(s) T
[ERROR] (actual and formal argument lists differ in length))
[ERROR] method org.drools.model.DSL.<A,B>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.functions.Function2<A,B,?>) is not applicable
[ERROR] (cannot infer type-variable(s) A,B
[ERROR] (actual and formal argument lists differ in length))
[ERROR] method org.drools.model.DSL.<A,B,C>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.functions.Function3<A,B,C,?>) is not applicable
[ERROR] (cannot infer type-variable(s) A,B,C
[ERROR] (argument mismatch; rules.P4C.LambdaExtractor4CA52645EC5319D0363A23796D4739AE cannot be converted to org.drools.model.functions.Function3<A,B,C,?>))
[ERROR] method org.drools.model.DSL.<A,B,C,D>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.Variable<D>,org.drools.model.functions.Function4<A,B,C,D,?>) is not applicable
[ERROR] (cannot infer type-variable(s) A,B,C,D
[ERROR] (actual and formal argument lists differ in length)){code}
This error can be reproduced with version _7.43.0-SNAPSHOT_
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5608) Cannot use method chaining as source for facts
by Ciprian Chiru (Jira)
Ciprian Chiru created DROOLS-5608:
-------------------------------------
Summary: Cannot use method chaining as source for facts
Key: DROOLS-5608
URL: https://issues.redhat.com/browse/DROOLS-5608
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.42.0.Final
Reporter: Ciprian Chiru
Assignee: Luca Molteni
Given the sample rule below:
{code:java}
import java.util.*;
global java.util.Set controlSet;
rule "will execute per each Measurement having ID color"
no-loop
when
Measurement( id == "color", $colorVal : val )
String() from Optional.of($colorVal).orElse("blah")
then
controlSet.add($colorVal);
end{code}
Compiling the resulting model fails with:
{code:java}
.../target/generated-sources/drools-model-compiler/main/java/rules/Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0.java:[24,129] cannot find symbol
[ERROR] symbol: variable $colorVal
[ERROR] location: class rules.Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0{code}
Can be reproduced with _7.43.0-SNAPSHOT_
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[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, 3 months
[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, 3 months
[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, 3 months
[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, 3 months