[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Ivan Straka commented on WFLY-12811:
------------------------------------
Hi [~jmesnil],
yes, i have an issue if boolean is used. It does not produce NPE, nor any other error. However it is always set to false (even if the value in the config source is true).
I have attached a reproducer.
> 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
>
> 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] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-4724:
----------------------------------------
Hi [~tari_manga] I've submitted a change for the workbench (removing setting the default {{LiteralExpression}}.
However [~jomarko] discovered that when saving a {{Context}} when the {{ContextEntry}} has no expression set a NPE is thrown by {{org.kie.dmn.backend.marshalling.v1_2.xstream.ContextEntryConverter}} trying to write a {{null}} child.
My question is should the User also be able to save {{ContextEntry}} w/o an expression being explicitly set or should we default to a {{LiteralExpression}} in this scenario? If so, it would be inconsistent with both {{Decision}} nodes and {{FunctionDefinition}}s w/o an expression being explicitly set (both these scenarios pass).
I believe all three scenarios should work the same.
> [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
>
>
> 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] (WFLY-12798) HealthCheck HTTP endpoint does not support CDI @RequestScoped scope
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12798?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-12798:
------------------------------------
[~flow80] WildFly 17 behaviour was not correct, it was using *unmanaged* CDI beans for the health checks.
In WildFly 17, the @RequestScope was not working either but it was taken into account at all (leading to subtle bugs).
In WildFly 18, we fixed the integration code to use *managed* CDI beans. So now @RequestScope is taken into account. However the scope itself is not activated on the health check probes. We need to determine if that would be possible or if only @ApplicationScope beans can be used by WildFly.
> HealthCheck HTTP endpoint does not support CDI @RequestScoped scope
> -------------------------------------------------------------------
>
> Key: WFLY-12798
> URL: https://issues.jboss.org/browse/WFLY-12798
> Project: WildFly
> Issue Type: Bug
> Components: MP Health
> Affects Versions: 18.0.0.Final
> Reporter: Florian Sailer
> Assignee: Jeff Mesnil
> Priority: Major
>
> 2019-11-15 15:26:11,717 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-1) Error processing Health Checks: org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164)
> at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
> at at.arz.bpe.boundary.PingCheck$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:666)
> 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.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:132)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> MP-Health Spec doesnt enforce a scope and it worked with wildfly 17.0.0.1-Final.
> https://github.com/eclipse/microprofile-health/issues/109
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFCORE-4626) Expose ExternalModuleService as WildFly capability
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4626?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4626:
--------------------------------
Component/s: Management
> Expose ExternalModuleService as WildFly capability
> --------------------------------------------------
>
> Key: WFCORE-4626
> URL: https://issues.jboss.org/browse/WFCORE-4626
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 11.0.0.Beta3
>
>
> ExternalModuleService is used to create the ExternalModuleSpecService which exposes the ModuleDefinition for any external module dependency.
> Currently, ExternalModuleService is used via DUPs to scan the deployment and add external modules. We should expose this service via a Capability so it can be easily accessed via not only by the DUPs, but also other services that could require configure external modules.
> This capability should be registered in ServerService, see for example PathManager. It should be something that ExternalModuleService implements, the goal is not to expose the start/stop/getValue methods via the capability.
> See [this|https://github.com/wildfly/wildfly-core/pull/3890#issuecomment-52180...] as reference comment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4795) [DMN Designer] User is unable to save model when structure is removed
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4795?page=com.atlassian.jira.plugi... ]
Michael Anstis reassigned DROOLS-4795:
--------------------------------------
Assignee: karreiro (was: Michael Anstis)
> [DMN Designer] User is unable to save model when structure is removed
> ---------------------------------------------------------------------
>
> Key: DROOLS-4795
> URL: https://issues.jboss.org/browse/DROOLS-4795
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: karreiro
> Priority: Major
> Labels: drools-tools
> Attachments: edit-and-remove.webm
>
>
> There is scenario causing user is not able to save the DMN file anymore. If is editing some structure field, but he decides in the middle of editing to rmeove whole structure, the save button of the designer remains disabled.
> We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months