[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFLY-12952:
------------------------------------
[~istraka] The culprit of this issue is the notion of "expected" health check procedures.
WildFly allows deployment of Jakarta EE application without any a priori knowledge. The application server does not when when an application will be deployed or if that application contains health check procedures.
That's why the default for the readiness endpoint is to return UP. It means that the app server does not expect any health check procedures from the deployments.
We also want to handle the case where the user knows that that there will be health check procedures in the deployment.
In that case, WildFly needs a hint about that and the user must specify the env var MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS=DOWN, so that WildFly knows that it must return DOWN until there are application readiness probes to take into account to determine the overall readiness of the app server + application.
My understanding is that we respect the spec. We need a hint (or configuration) from the user but this is not against the spec.
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4923) dded handling an end key for selecting bottom right cell in scenario
by Anna Dupliak (Jira)
Anna Dupliak created DROOLS-4923:
------------------------------------
Summary: dded handling an end key for selecting bottom right cell in scenario
Key: DROOLS-4923
URL: https://issues.redhat.com/browse/DROOLS-4923
Project: Drools
Issue Type: Enhancement
Components: Test Scenarios Editor
Affects Versions: 7.31.0.Final
Reporter: Anna Dupliak
Assignee: Anna Dupliak
This is small improvement basically for testing.
This enchantments adds ability to user to navigate to the right bottom cell of the grid by using END key.
It described in ScenarioGridPanelProducer.class.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12952) MP Health returns UP when checks are expected but not installed yet.
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-12952?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-12952:
-------------------------------
Description:
MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
was:
MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/master/spec/src/...] says:
* A producer MUST support custom, application level health check procedures
* A producer SHOULD support reasonable out-of-the-box procedures
* A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
* A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
_Let me note that on OpenShift starting the served should mean starting the service._
Hence I expect negative overall status till the probe is ready and is able to provide response.
However WildFly with default setting responses with status UP:
{code:bash}
while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
17:17:56.466 {"status":"UP","checks":[]}
...
17:18:01.121 {"status":"UP","checks":[]}
17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
{code}
This violates (4) bullet in the specification.
WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
Which would mean the scenario would behave according to the specification. Yet the default state violates it.
If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
{noformat}
17:22:41.719
{"status":"DOWN","checks":[]}
{noformat}
And that would violate (3) in the specification.
TCK tests do not cover the scenario well.
Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
If there is no deployment, the _UP_ it is.
Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
* OpenShift starts the service wait some time and start asking for health status
* WildFly responses _UP_ yet application helathcheck is not installed yet
* With health status _UP_ OpenShift consider a pod ready
* In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
> MP Health returns UP when checks are expected but not installed yet.
> --------------------------------------------------------------------
>
> Key: WFLY-12952
> URL: https://issues.redhat.com/browse/WFLY-12952
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> MicroProfile Health 2.0 specification [link|https://github.com/eclipse/microprofile-health/blob/2.0/spec/src/mai...] says:
> * A producer MUST support custom, application level health check procedures
> * A producer SHOULD support reasonable out-of-the-box procedures
> * A producer with no health check procedures expected or installed MUST return positive overall status (i.e. HTTP 200)
> * A producer with health check procedures expected but not yet installed MUST return negative overall status (i.e. HTTP 503)
> When I deploy and application with a readiness probe before WildFly is started, from my and namely OpenShift POV the health check procedure is expected from the very beginning.
> _Let me note that on OpenShift starting the served should mean starting the service._
> Hence I expect negative overall status till the probe is ready and is able to provide response.
> However WildFly with default setting responses with status UP:
> {code:bash}
> while true; do echo $(date +"%T.%3N") ; curl localhost:9990/health/ready; echo ""; done
> 17:17:56.438 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.452 curl: (7) Failed to connect to localhost port 9990: Connection refused
> 17:17:56.466 {"status":"UP","checks":[]}
> ...
> 17:18:01.121 {"status":"UP","checks":[]}
> 17:18:01.133 {"status":"DOWN","checks":[{"name":"delayed-readiness","status":"DOWN"}]}
> {code}
> This violates (4) bullet in the specification.
> WildFly provides option to set global Status when probes are not defined ([documentation|https://doc-stage.usersys.redhat.com/documentation/en-us/re...])
> Which would mean the scenario would behave according to the specification. Yet the default state violates it.
> If the default value were _DOWN_ we would run into an issue if WildFly without deployment were used (for example as backup for AMQ). The status would be just DOWN:
> {noformat}
> 17:22:41.719
> {"status":"DOWN","checks":[]}
> {noformat}
> And that would violate (3) in the specification.
> TCK tests do not cover the scenario well.
> Is there a way to return _DOWN_ until WildFly scan a deployment and if no health check is found (thus not expected) then start to return _UP_ ? The scan should happen during MP Health initialization.
> If there is no deployment, the _UP_ it is.
> Setting the priority to blocker since WildFly 19 shall be EAP 7.3.0.CD19 which is supposed to run on OpenShift. With this behavior health check is not very useful because:
> * OpenShift starts the service wait some time and start asking for health status
> * WildFly responses _UP_ yet application helathcheck is not installed yet
> * With health status _UP_ OpenShift consider a pod ready
> * In this point application is installed, health status is _DOWN_ (a DB is down) however OpenShift flow is somewhere else
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Jan Kasik commented on WFWIP-294:
---------------------------------
I will sum up our discussion here: After fiddling with [~dlofthouse]'s quickstart project we found out that the issue is reproducible for {{mp.jwt.verify.publickey}}. With {{mp.jwt.verify.publickey.location}} it is not.
> JWT is rejected if signature matching public key is not first in JWK set
> ------------------------------------------------------------------------
>
> Key: WFWIP-294
> URL: https://issues.redhat.com/browse/WFWIP-294
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP JWT
> Reporter: Jan Kasik
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: jwks.json, jwt.base64
>
>
> When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array.
> This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property.
> Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4922) LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4922?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi reassigned DROOLS-4922:
-----------------------------------------
Assignee: Toshiya Kobayashi (was: Luca Molteni)
> LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4922
> URL: https://issues.redhat.com/browse/DROOLS-4922
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> In case of incremental compilation, say, a rule is changed:
> - A lambda consequence (or a lambda predicate) has the same expression
> - But an "import" statement is added to the rule
> It will results in
> {noformat}
> [ERROR] testIdenticalConsequenceButImportChange[PATTERN_DSL](org.drools.modelcompiler.IncrementalCompilationTest) Time elapsed: 3.135 s <<< ERROR!
> java.lang.LinkageError: loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @2b0dc227 (instance of org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for org.drools.test.LambdaConsequence6F5B5EC739B778AE0EE14FA22BAFE144.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader.defineClass(DynamicProjectClassLoader.java:97)
> at org.drools.reflective.classloader.ProjectClassLoader.defineType(ProjectClassLoader.java:183)
> at org.drools.reflective.classloader.ProjectClassLoader.defineClass(ProjectClassLoader.java:195)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.reinitModifiedClasses(KieContainerImpl.java:323)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:243)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:236)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:194)
> at org.drools.modelcompiler.IncrementalCompilationTest.testIdenticalConsequenceButImportChange(IncrementalCompilationTest.java:257)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4922) LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4922?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-4922:
--------------------------------------
Sprint: 2020 Week 01-03 (from Dec 30)
> LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4922
> URL: https://issues.redhat.com/browse/DROOLS-4922
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> In case of incremental compilation, say, a rule is changed:
> - A lambda consequence (or a lambda predicate) has the same expression
> - But an "import" statement is added to the rule
> It will results in
> {noformat}
> [ERROR] testIdenticalConsequenceButImportChange[PATTERN_DSL](org.drools.modelcompiler.IncrementalCompilationTest) Time elapsed: 3.135 s <<< ERROR!
> java.lang.LinkageError: loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @2b0dc227 (instance of org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for org.drools.test.LambdaConsequence6F5B5EC739B778AE0EE14FA22BAFE144.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader.defineClass(DynamicProjectClassLoader.java:97)
> at org.drools.reflective.classloader.ProjectClassLoader.defineType(ProjectClassLoader.java:183)
> at org.drools.reflective.classloader.ProjectClassLoader.defineClass(ProjectClassLoader.java:195)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.reinitModifiedClasses(KieContainerImpl.java:323)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:243)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:236)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:194)
> at org.drools.modelcompiler.IncrementalCompilationTest.testIdenticalConsequenceButImportChange(IncrementalCompilationTest.java:257)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4922) LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-4922:
-----------------------------------------
Summary: LinkageError: attempted duplicate class definition for materialized Lambda during incremental compilation
Key: DROOLS-4922
URL: https://issues.redhat.com/browse/DROOLS-4922
Project: Drools
Issue Type: Bug
Components: executable model
Reporter: Toshiya Kobayashi
Assignee: Luca Molteni
In case of incremental compilation, say, a rule is changed:
- A lambda consequence (or a lambda predicate) has the same expression
- But an "import" statement is added to the rule
It will results in
{noformat}
[ERROR] testIdenticalConsequenceButImportChange[PATTERN_DSL](org.drools.modelcompiler.IncrementalCompilationTest) Time elapsed: 3.135 s <<< ERROR!
java.lang.LinkageError: loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @2b0dc227 (instance of org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for org.drools.test.LambdaConsequence6F5B5EC739B778AE0EE14FA22BAFE144.
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
at org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader.defineClass(DynamicProjectClassLoader.java:97)
at org.drools.reflective.classloader.ProjectClassLoader.defineType(ProjectClassLoader.java:183)
at org.drools.reflective.classloader.ProjectClassLoader.defineClass(ProjectClassLoader.java:195)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.reinitModifiedClasses(KieContainerImpl.java:323)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:243)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:236)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:194)
at org.drools.modelcompiler.IncrementalCompilationTest.testIdenticalConsequenceButImportChange(IncrementalCompilationTest.java:257)
...
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months