[Red Hat JIRA] (DROOLS-5870) DrlDumper does not generate the accumulate import
by Hiroko Miura (Jira)
[ https://issues.redhat.com/browse/DROOLS-5870?page=com.atlassian.jira.plug... ]
Hiroko Miura commented on DROOLS-5870:
--------------------------------------
Customer would like to know if there is any workaround on this issue. Please let me know if any.
> DrlDumper does not generate the accumulate import
> --------------------------------------------------
>
> Key: DROOLS-5870
> URL: https://issues.redhat.com/browse/DROOLS-5870
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.44.0.Final, 7.46.0.Final
> Reporter: Hiroko Miura
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Attachments: import-accumulate-test.zip
>
>
> DrlDumper is not printing out the accumulate import.
> Here is an example code of PackageDescrBuilder.
> {noformat}
> PackageDescr packageDescr = DescrFactory.newPackage().name("examples.drools")
> .newImport().target("java.math.BigDecimal").end()
> .newAccumulateImport().target("examples.drools.accumulate.OriginalFunction").functionName("originalFunction").end()
> .newRule().name("Test Rule")
> .lhs()
> .accumulate()
> .source().pattern().type("TargetFact").id("$target", false)
> .end()
> .end()
> .function("originalFunction", "$accumulateResult", false, "$target.hoge")
> .constraint("true")
> .end()
> .end()
> .rhs("System.out.println($accumulateResult);")
> .end()
> .end().getDescr();
> String drl = new DrlDumper().dump(packageDescr);
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 4 months
[Red Hat JIRA] (WFLY-14151) Introduce a base "health" subsystem and move microprofile-health to the microprofile feature-pack
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-14151?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFLY-14151:
-------------------------------
Description:
The microprofile-health-smallrye subsystem is provided by the wilfdfly galleon-pack.
However its logical inclusion is in the microprofile feature pack (org.wildfly:wildfly-mp-feature-pack-galleon-common) which provides features for MicroProfile.
We should move the subsystem (and extension) to this feature pack.
However, the base WildFly server is still expected to provide "base" healthiness information (to determine when the application server is ready to serve requests) that can be consumed out of the box by a container platform such as Kubernetes.
I propose to introduce a simple "health" subsystem (without any external dependencies) that provides a HTTP endpoints to probe the server healthiness.
The microprofile-health-smallrye subsystem will be refactored to "plug" in the same HTTP endpoint and overrides the base health endpoint and provide the full features of MicroProfile health
was:
The microprofile-metrics-smallrye subsystem is provided by the wilfdfly galleon-pack.
However its logical inclusion is in the microprofile feature pack (org.wildfly:wildfly-mp-feature-pack-galleon-common) which provides features for MicroProfile.
We should move the subsystem (and extension) to this feature pack.
However, the base WildFly server is still expected to provide "base" metrics (for the WildFly management model and the JVM) that can be consumed out of the box.
I propose to introduce a simple "metrics" subsystem (without any external dependencies) that exposes the WildFly management model and the JVM (using JMX) to the /metrics endpoint (on the management port) with the Prometheus format.
The microprofile-metrics-smallrye subsystem will be refactored to "plug" in the same HTTP endpoint and overrides the base metrics endpoint and provide the full features of MicroProfile metrics (application metrics, JSON output, etc.)
> Introduce a base "health" subsystem and move microprofile-health to the microprofile feature-pack
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-14151
> URL: https://issues.redhat.com/browse/WFLY-14151
> Project: WildFly
> Issue Type: Feature Request
> Components: MP Metrics
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 22.0.0.Beta1
>
>
> The microprofile-health-smallrye subsystem is provided by the wilfdfly galleon-pack.
> However its logical inclusion is in the microprofile feature pack (org.wildfly:wildfly-mp-feature-pack-galleon-common) which provides features for MicroProfile.
> We should move the subsystem (and extension) to this feature pack.
> However, the base WildFly server is still expected to provide "base" healthiness information (to determine when the application server is ready to serve requests) that can be consumed out of the box by a container platform such as Kubernetes.
> I propose to introduce a simple "health" subsystem (without any external dependencies) that provides a HTTP endpoints to probe the server healthiness.
> The microprofile-health-smallrye subsystem will be refactored to "plug" in the same HTTP endpoint and overrides the base health endpoint and provide the full features of MicroProfile health
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 4 months
[Red Hat JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Jason Lee (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Jason Lee reassigned WFCORE-4291:
---------------------------------
Assignee: Jason Lee (was: Brian Stansberry)
> 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: Jason Lee
> 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)
3 years, 4 months
[Red Hat JIRA] (ELY-2049) Add trace capability to o.w.s.m.WildFlySecurityManager findAccessDenial
by Boris Unckel (Jira)
Boris Unckel created ELY-2049:
---------------------------------
Summary: Add trace capability to o.w.s.m.WildFlySecurityManager findAccessDenial
Key: ELY-2049
URL: https://issues.redhat.com/browse/ELY-2049
Project: WildFly Elytron
Issue Type: Enhancement
Components: Security Manager
Affects Versions: 1.13.0.CR1
Reporter: Boris Unckel
The current implementation is very strong for regular cases. It works fine to display missing permissions when CodeSource and/or ClassLoader are correctly set to the checked protection domain. If one of those is missing and there is no good exception handling, it is impossible to track down missing permissions.
Example:
[java.io.File|https://github.com/openjdk/jdk/blob/jdk-11%2B28/src/java.bas...]
line 2048
The idea is to provide a yielded trace log and provide the missing permission, the full protection domain and a dummy exception to have stack trace where this occurs.
Current code:
{code:java}
public static ProtectionDomain findAccessDenial(final Permission permission, final ProtectionDomain... domains) {
ProtectionDomain deniedDomain = null;
if (domains != null) for (ProtectionDomain domain : domains) {
if (! domain.implies(permission)) {
final CodeSource codeSource = domain.getCodeSource();
final ClassLoader classLoader = domain.getClassLoader();
final Principal[] principals = domain.getPrincipals();
if (principals == null || principals.length == 0) {
access.accessCheckFailed(permission, codeSource, classLoader);
} else {
access.accessCheckFailed(permission, codeSource, classLoader, Arrays.toString(principals));
}
if (deniedDomain == null && ! LOG_ONLY) {
deniedDomain = domain;
}
}
}
return deniedDomain;
}
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 4 months
[Red Hat JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Jeff Mesnil reassigned WFCORE-4291:
-----------------------------------
Assignee: Jeff Mesnil (was: Jason Lee)
> 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: Jeff Mesnil
> 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)
3 years, 4 months