[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-4724:
----------------------------------------
Thank you for the analysis [~jomarko].
Hi [~manstis] I believe the proper answer is to follow the expectation of the XSD, to avoid saving something which would fail at being a valid xml.
Meaning for ContextEntry for the XSD we must provide an Expression, hence the NPE in the marshaller implementation:
!screenshot-1.png|thumbnail!
While for Decision node that is optional, hence this work:
!screenshot-2.png|thumbnail!
Being expression optional also applies to functionDefinition's body and businessKnowledgeModel nodes' expression.
That said, I believe we can reasonably act on the ContextEntry behaving different on the basis of the DMN specification itself.
Additionally, I believe is confusing to drop-in just an empty LiteralExpression with no content whatsoever, as that appears to be one of the source of confusion for new-users, as reported for instance by [~mfusco] during the last sanity checks.
Hence I would conclude by proposing the following:
* the current behaviour appears to be working fine AND valid for most of the elements, proving it's okay
* for contextEntry, if missing an expression during the save, we should drop-in a LiteralExpression with {{null}} as its content, so to make it more explicit that was caused by the user saving without having filled that field. We can even have it as:
{code:java}
null // auto-filled on save by the editor to avoid missing empty expression for entry
{code}
this is my perspective, let me know if the second bulletpoint in your view can be implemented WB side or your view is for it to be filled by the -backend marshaller.
/cc [~tirelli]
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, save-context.webm, screenshot-1.png, screenshot-2.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (x) [^error.log] [^save-context.webm]
> - Invocation (/)
> h3. Kogito
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (/)
> - Invocation (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-4724:
-----------------------------------
Attachment: screenshot-2.png
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, save-context.webm, screenshot-1.png, screenshot-2.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (x) [^error.log] [^save-context.webm]
> - Invocation (/)
> h3. Kogito
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (/)
> - Invocation (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-4724:
-----------------------------------
Attachment: screenshot-1.png
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, save-context.webm, screenshot-1.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (x) [^error.log] [^save-context.webm]
> - Invocation (/)
> h3. Kogito
> - Decision node (/)
> - BKM node (/)
> - Cleared Function (/)
> - Context entry (/)
> - Invocation (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Jean Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ]
Jean Francois Denise edited comment on WFWIP-276 at 11/22/19 11:52 AM:
-----------------------------------------------------------------------
[~jbliznak], in order to preserve the possible XML tags that could be present in the config. Could you try by setting --build-env=CONFIG_ADJUSTMENT_MODE=cli and see the impact on your numbers? Even without drivers added, we have CLI operations sent to the server at boot time.
was (Author: jdenise):
[~jbliznak], in order to preserve the possible XML tags that could be present in the config. Could you try by setting CONFIG_ADJUSTMENT_MODE=cli and see the impact on your numbers? Even without drivers added, we have CLI operations sent to the server at boot time.
> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
> Key: WFWIP-276
> URL: https://issues.jboss.org/browse/WFWIP-276
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
> Attachments: test-app.zip
>
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1 | 8283|6128|2155
> |#2 | 9446|7548|1898
> |#3 | 8767|6871| 1896
> |#4 | 8568|6272| 2296
> |#5 | 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1 |13769|5716|8053
> |#2 |13362|5952|7410
> |#3 |14261|6093|8168
> |#4 |14322|6135|8187
> |#5 |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself == {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Jean Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ]
Jean Francois Denise commented on WFWIP-276:
--------------------------------------------
[~jbliznak], in order to preserve the possible XML tags that could be present in the config. Could you try by setting CONFIG_ADJUSTMENT_MODE=cli and see the impact on your numbers? Even without drivers added, we have CLI operations sent to the server at boot time.
> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
> Key: WFWIP-276
> URL: https://issues.jboss.org/browse/WFWIP-276
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
> Attachments: test-app.zip
>
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1 | 8283|6128|2155
> |#2 | 9446|7548|1898
> |#3 | 8767|6871| 1896
> |#4 | 8568|6272| 2296
> |#5 | 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1 |13769|5716|8053
> |#2 |13362|5952|7410
> |#3 |14261|6093|8168
> |#4 |14322|6135|8187
> |#5 |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself == {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Jeff Mesnil edited comment on WFLY-12811 at 11/22/19 11:45 AM:
---------------------------------------------------------------
I built your reproducer and it works as expected:
{code:java}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=true
...
$ curl http://:8080/mp-1.0/dummy
true
$ curl http://:9990/health
{"status":"UP","checks":[{"name":"dummy","status":"UP"}]}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=false
...
$ curl http://:8080/mp-1.0/dummy
false
$ curl http://:9990/health
{"status":"DOWN","checks":[{"name":"dummy","status":"DOWN"}]}
{code}
was (Author: jmesnil):
I built your reproducer and it works as expected:
{{$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=true
...
$ curl http://:8080/mp-1.0/dummy
true
$ curl http://:9990/health
{"status":"UP","checks":[{"name":"dummy","status":"UP"}]}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=false
...
$ curl http://:8080/mp-1.0/dummy
false
$ curl http://:9990/health
{"status":"DOWN","checks":[{"name":"dummy","status":"DOWN"}]}
}}
> Can not inject MP Config property to a HealthCheck bean
> -------------------------------------------------------
>
> Key: WFLY-12811
> URL: https://issues.jboss.org/browse/WFLY-12811
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: mp-1.0.war
>
>
> I am playing a bit with MP specs (getting multiple specs to work together). I have been trying to return Health status based on injected config property (MP Config). However it looks like the property is not properly injected to the bean.
> {code:java}
> @Liveness
> @ApplicationScoped
> public class CDIBasedLivenessHealthCheck implements HealthCheck {
> @Inject
> @ConfigProperty(name = "dummy_live")
> private Provider<Boolean> live;
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("dummy")
> .state(live.get())
> .build();
> }
> }
> {code}
> I am get following error:
> {code:java}
> 15:41:04,616 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-2) Error processing Health Checks: java.lang.NullPointerException
> at health.CDIBasedLivenessHealthCheck.call(CDIBasedLivenessHealthCheck.java:26)
> at health.CDIBasedLivenessHealthCheck$Proxy$_$$_WeldClientProxy.call(Unknown Source)
> at org.wildfly.extension.microprofile.health.HealthReporter.jsonObject(HealthReporter.java:120)
> at org.wildfly.extension.microprofile.health.HealthReporter.fillCheck(HealthReporter.java:107)
> at org.wildfly.extension.microprofile.health.HealthReporter.processChecks(HealthReporter.java:96)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:79)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:60)
> at org.wildfly.extension.microprofile.health.HealthContextService$HealthCheckHandler.handleRequest(HealthContextService.java:100)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:672)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> I believe there is a bug in MP Health integration rather than in weld. After checks are registered here in [CDIExtension|https://github.com/wildfly/wildfly/blob/master/microprofile/...] I am able to call _check.call()_ and I get _UP_ as a result. However during HTTP call here in [HealthReporter|https://github.com/wildfly/wildfly/blob/master/microprofil...] I get NPE.
> I can inject a dummy bean. However if the dummy bean injects a config property, NPE is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Jeff Mesnil edited comment on WFLY-12811 at 11/22/19 11:44 AM:
---------------------------------------------------------------
I built your reproducer and it works as expected:
[code]
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=true
...
$ curl http://:8080/mp-1.0/dummy
true
$ curl http://:9990/health
{"status":"UP","checks":[{"name":"dummy","status":"UP"}]}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=false
...
$ curl http://:8080/mp-1.0/dummy
false
$ curl http://:9990/health
{"status":"DOWN","checks":[{"name":"dummy","status":"DOWN"}]}
[code]
was (Author: jmesnil):
I built your reproducer and it works as expected:
{code}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=true
...
$ curl http://:8080/mp-1.0/dummy
true
$ curl http://:9990/health
{"status":"UP","checks":[{"name":"dummy","status":"UP"}]}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=false
...
$ curl http://:8080/mp-1.0/dummy
false
$ curl http://:9990/health
{"status":"DOWN","checks":[{"name":"dummy","status":"DOWN"}]}
> Can not inject MP Config property to a HealthCheck bean
> -------------------------------------------------------
>
> Key: WFLY-12811
> URL: https://issues.jboss.org/browse/WFLY-12811
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: mp-1.0.war
>
>
> I am playing a bit with MP specs (getting multiple specs to work together). I have been trying to return Health status based on injected config property (MP Config). However it looks like the property is not properly injected to the bean.
> {code:java}
> @Liveness
> @ApplicationScoped
> public class CDIBasedLivenessHealthCheck implements HealthCheck {
> @Inject
> @ConfigProperty(name = "dummy_live")
> private Provider<Boolean> live;
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("dummy")
> .state(live.get())
> .build();
> }
> }
> {code}
> I am get following error:
> {code:java}
> 15:41:04,616 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-2) Error processing Health Checks: java.lang.NullPointerException
> at health.CDIBasedLivenessHealthCheck.call(CDIBasedLivenessHealthCheck.java:26)
> at health.CDIBasedLivenessHealthCheck$Proxy$_$$_WeldClientProxy.call(Unknown Source)
> at org.wildfly.extension.microprofile.health.HealthReporter.jsonObject(HealthReporter.java:120)
> at org.wildfly.extension.microprofile.health.HealthReporter.fillCheck(HealthReporter.java:107)
> at org.wildfly.extension.microprofile.health.HealthReporter.processChecks(HealthReporter.java:96)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:79)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:60)
> at org.wildfly.extension.microprofile.health.HealthContextService$HealthCheckHandler.handleRequest(HealthContextService.java:100)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:672)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> I believe there is a bug in MP Health integration rather than in weld. After checks are registered here in [CDIExtension|https://github.com/wildfly/wildfly/blob/master/microprofile/...] I am able to call _check.call()_ and I get _UP_ as a result. However during HTTP call here in [HealthReporter|https://github.com/wildfly/wildfly/blob/master/microprofil...] I get NPE.
> I can inject a dummy bean. However if the dummy bean injects a config property, NPE is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Jeff Mesnil edited comment on WFLY-12811 at 11/22/19 11:44 AM:
---------------------------------------------------------------
I built your reproducer and it works as expected:
{{$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=true
...
$ curl http://:8080/mp-1.0/dummy
true
$ curl http://:9990/health
{"status":"UP","checks":[{"name":"dummy","status":"UP"}]}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=false
...
$ curl http://:8080/mp-1.0/dummy
false
$ curl http://:9990/health
{"status":"DOWN","checks":[{"name":"dummy","status":"DOWN"}]}
}}
was (Author: jmesnil):
I built your reproducer and it works as expected:
[code]
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=true
...
$ curl http://:8080/mp-1.0/dummy
true
$ curl http://:9990/health
{"status":"UP","checks":[{"name":"dummy","status":"UP"}]}
$ ./bin/standalone.sh -c standalone-full.xml -Ddummy_live=false
...
$ curl http://:8080/mp-1.0/dummy
false
$ curl http://:9990/health
{"status":"DOWN","checks":[{"name":"dummy","status":"DOWN"}]}
[code]
> Can not inject MP Config property to a HealthCheck bean
> -------------------------------------------------------
>
> Key: WFLY-12811
> URL: https://issues.jboss.org/browse/WFLY-12811
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: mp-1.0.war
>
>
> I am playing a bit with MP specs (getting multiple specs to work together). I have been trying to return Health status based on injected config property (MP Config). However it looks like the property is not properly injected to the bean.
> {code:java}
> @Liveness
> @ApplicationScoped
> public class CDIBasedLivenessHealthCheck implements HealthCheck {
> @Inject
> @ConfigProperty(name = "dummy_live")
> private Provider<Boolean> live;
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("dummy")
> .state(live.get())
> .build();
> }
> }
> {code}
> I am get following error:
> {code:java}
> 15:41:04,616 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-2) Error processing Health Checks: java.lang.NullPointerException
> at health.CDIBasedLivenessHealthCheck.call(CDIBasedLivenessHealthCheck.java:26)
> at health.CDIBasedLivenessHealthCheck$Proxy$_$$_WeldClientProxy.call(Unknown Source)
> at org.wildfly.extension.microprofile.health.HealthReporter.jsonObject(HealthReporter.java:120)
> at org.wildfly.extension.microprofile.health.HealthReporter.fillCheck(HealthReporter.java:107)
> at org.wildfly.extension.microprofile.health.HealthReporter.processChecks(HealthReporter.java:96)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:79)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:60)
> at org.wildfly.extension.microprofile.health.HealthContextService$HealthCheckHandler.handleRequest(HealthContextService.java:100)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:672)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> I believe there is a bug in MP Health integration rather than in weld. After checks are registered here in [CDIExtension|https://github.com/wildfly/wildfly/blob/master/microprofile/...] I am able to call _check.call()_ and I get _UP_ as a result. However during HTTP call here in [HealthReporter|https://github.com/wildfly/wildfly/blob/master/microprofil...] I get NPE.
> I can inject a dummy bean. However if the dummy bean injects a config property, NPE is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months