[JBoss JIRA] (WFLY-12835) HealthChecks in subdeployments are not registered
by charles ghislain (Jira)
[ https://issues.redhat.com/browse/WFLY-12835?page=com.atlassian.jira.plugi... ]
charles ghislain edited comment on WFLY-12835 at 5/6/20 11:24 AM:
------------------------------------------------------------------
It affects 19.0.0.Final as well.
The org.wildfly.extension.microprofile.health.deployment.CDIExtension resolves HealthChecks using 'Weld BeanManager for org.wildfly.extension.microprofile.health-smallrye.additionalClasses [bean count=32]' wich does not find Healtcheck present in ejbs or wars modules of an ear.
Using CDI.current() there works, but is not reliable for ear if im not mistaken.
On Wildfly 16 application checks are discovered with the same setup
was (Author: cghislai):
It affects 19.0.0.Final as well.
The org.wildfly.extension.microprofile.health.deployment.CDIExtension resolves HealthChecks using 'Weld BeanManager for org.wildfly.extension.microprofile.health-smallrye.additionalClasses [bean count=32]' wich does not find Healtcheck present in ejbs or wars modules of an ear.
Using CDI.current() there works, but is not reliable for ear if im not mistaken.
Im sure it worked with earlier versions, before the change in the output json schema.
> HealthChecks in subdeployments are not registered
> -------------------------------------------------
>
> Key: WFLY-12835
> URL: https://issues.redhat.com/browse/WFLY-12835
> Project: WildFly
> Issue Type: Feature Request
> Components: MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
>
> After EAR is deployed HealthChecks are not registered and not exposed under _/health_ endpoint.
> EAR contains one WAR and one JAR. Both of them contains HealthChecks.
> Test source: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-health/mic...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFLY-13433:
------------------------------------------
Summary: Improve capability support in EJB3 subsystem
Key: WFLY-13433
URL: https://issues.redhat.com/browse/WFLY-13433
Project: WildFly
Issue Type: Enhancement
Components: EJB
Affects Versions: 20.0.0.Beta1
Reporter: Richard Achmatowicz
Assignee: Cheng Fang
Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4962?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-4962:
-------------------------------------
Description:
For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used.
At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources.
was:
For all deployments we should associate a new class SecurityMetaData with all parent deployments, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used.
At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources.
> Add a SecurityMetaData for all deployments
> ------------------------------------------
>
> Key: WFCORE-4962
> URL: https://issues.redhat.com/browse/WFCORE-4962
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 12.0.0.Beta3
>
>
> For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used.
> At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-4962:
----------------------------------------
Summary: Add a SecurityMetaData for all deployments
Key: WFCORE-4962
URL: https://issues.redhat.com/browse/WFCORE-4962
Project: WildFly Core
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 12.0.0.Beta3
For all deployments we should associate a new class SecurityMetaData with all parent deployments, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used.
At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13432) Provide capability for Undertow HTTP Upgrade registry
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13432?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz updated WFLY-13432:
---------------------------------------
Description: The HTTP Upgrade feature of Undertow depends on subsystems such as Messaging and EJB having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities. (was: The HTTP Upgrade feature of Undertow depends on subsystems such as Remoting, Messaging and EJB having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities.)
> Provide capability for Undertow HTTP Upgrade registry
> -----------------------------------------------------
>
> Key: WFLY-13432
> URL: https://issues.redhat.com/browse/WFLY-13432
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> The HTTP Upgrade feature of Undertow depends on subsystems such as Messaging and EJB having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5254) [DMN Designer] Generate SVG for use in Swagger documentation
by Tiago Dolphine (Jira)
[ https://issues.redhat.com/browse/DROOLS-5254?page=com.atlassian.jira.plug... ]
Tiago Dolphine commented on DROOLS-5254:
----------------------------------------
Hi [~roger600] [~karreiro] the SVG generation basically is a wrapper on the Canvas Context2D, so it generates the SVG based on the current drawn Canvas, all elements that are on the canvas should be on the SVG as well.
> [DMN Designer] Generate SVG for use in Swagger documentation
> ------------------------------------------------------------
>
> Key: DROOLS-5254
> URL: https://issues.redhat.com/browse/DROOLS-5254
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.36.0.Final
> Reporter: Matteo Mortari
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: drools-tools
>
> {quote}
> It'd be nice to have the ability to generate SVGs for a DMN XML model (including graph and boxed expressions) using a utility class/function that does not require the editor to be deployed or running. The resulting SVG would be used in the Swagger documentation.
> {quote}
> Apparently the _process_ people have been looking into something similar for processes; so it might be worth checking with [~roger600] first as whatever DMN does may simply follow on from BPMN2/CM.
> There is possibly an existing DMN JIRA for a similar requirement (as, IIRC, "Export as SVG" only generates SVG for the graph at present and not the boxed expressions).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years