[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Akhtar Momin (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Akhtar Momin commented on JGRP-1618:
------------------------------------
We are using 2.6.15 JGroups jar for our application and we are facing memory leak issue and heap dump revealed that the problem was in the xmit_table ConcurrentHashMap of Org.jgroups.protocols.pbcast.NAKACK.
Heap dump generation in production is quiet frequent i.e. something around every 14-15 days .We have to always restart the application in production in order to make it work which is not good.
1. Could you please help us to understand the issue and why it is retaining so much of heap?
2. Which version of jgroup jar would be best in order to avoid this issue?
3. Is there any fix in particular java file of jgroup collection which will help in reducing the retained heap memory?
Please let us know if you need any information in order to understand the problem.
Thanks in advance
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Akhtar Momin (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Akhtar Momin updated JGRP-1618:
-------------------------------
Attachment: screenshot-1.png
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Guillaume Smet (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Guillaume Smet commented on WFLY-11566:
---------------------------------------
{quote}
Configure the Factory once WFLY gets it
{quote}
This is not an option. The {{ValidatorFactory}} is fully immutable (and it was designed this way for a long time so we don't want it to change).
{quote}
Provide a custom new bean that will replace this Factory (e.g. an enabled CDI alternative that will "override" the original bean), this new bean will be configured by WFLY
{quote}
Can't say I'm a big fan of that one because the VF initialization process is a bit complicated.
{quote}
NOTE - you cannot do that via another CDI bean. Assuming HV is providing bean via extension, they won't be able to use other beans at that point, it is too early in the process.
{quote}
The real VF used by WildFly is initialized here: https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main... . We can't get a bean from the {{BeanManager}} at that point?
Another option I was considering would be to use the ServiceLoader but I wonder how it would work on the class loader level (I know things can quickly get complicated in WF).
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4888) spring boot and drools integration occur path error and cannot load rule
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4888?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-4888.
---------------------------------
Resolution: Cannot Reproduce
I cannot reproduce this problem. The project that you sent works perfectly for me and when I try to launch the spring-boot app it generates the output that I'm pasting below. Do you have a different output? if so can you please paste it?
{code}
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.2.2.RELEASE)
2019-12-20 17:30:46.167 INFO 7204 --- [ main] c.b.test.spring.drools.SpringDroolsApp : Starting SpringDroolsApp on new-host with PID 7204 (/home/mfusco/Downloads/springdrools/target/classes started by mfusco in /home/mfusco/Downloads/springdrools)
2019-12-20 17:30:46.169 INFO 7204 --- [ main] c.b.test.spring.drools.SpringDroolsApp : No active profile set, falling back to default profiles: default
2019-12-20 17:30:46.820 INFO 7204 --- [ main] o.k.s.KModuleBeanFactoryPostProcessor : :: BeanFactoryPostProcessor::postProcessBeanFactory called ::
2019-12-20 17:30:46.823 WARN 7204 --- [ main] o.d.c.k.b.impl.ClasspathKieProject : Unable to find pom.properties in /home/mfusco/Downloads/springdrools/target/classes
2019-12-20 17:30:46.828 INFO 7204 --- [ main] o.d.c.k.b.impl.ClasspathKieProject : Recursed up folders, found and used pom.xml /home/mfusco/Downloads/springdrools/pom.xml
2019-12-20 17:30:46.828 INFO 7204 --- [ main] o.k.s.KModuleBeanFactoryPostProcessor : Found project with releaseId: cn.beausoft.test:spring-drools:1.0
2019-12-20 17:30:46.908 INFO 7204 --- [ main] o.k.s.KModuleBeanFactoryPostProcessor : Adding KieModule from /home/mfusco/Downloads/springdrools/target/classes to repository.
2019-12-20 17:30:47.152 INFO 7204 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 1235 (http)
2019-12-20 17:30:47.157 INFO 7204 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2019-12-20 17:30:47.158 INFO 7204 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.29]
2019-12-20 17:30:47.215 INFO 7204 --- [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
2019-12-20 17:30:47.215 INFO 7204 --- [ main] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 999 ms
2019-12-20 17:30:47.929 INFO 7204 --- [ main] o.s.s.concurrent.ThreadPoolTaskExecutor : Initializing ExecutorService 'applicationTaskExecutor'
2019-12-20 17:30:48.087 INFO 7204 --- [ main] o.s.s.c.ThreadPoolTaskScheduler : Initializing ExecutorService 'taskScheduler'
2019-12-20 17:30:48.130 INFO 7204 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 1235 (http) with context path ''
2019-12-20 17:30:48.134 INFO 7204 --- [ main] c.b.test.spring.drools.SpringDroolsApp : Started SpringDroolsApp in 2.297 seconds (JVM running for 2.764)
{code}
> spring boot and drools integration occur path error and cannot load rule
> ------------------------------------------------------------------------
>
> Key: DROOLS-4888
> URL: https://issues.redhat.com/browse/DROOLS-4888
> Project: Drools
> Issue Type: Bug
> Components: docs, integration
> Affects Versions: 7.30.0.Final
> Reporter: 韩 济蓬
> Assignee: Mario Fusco
> Priority: Major
> Attachments: springdrools.zip
>
>
> I'm trying to run drools 7.30.0.Final with Spring Boot 2.2.2.RELEASE.I configured drools as the documentation says. My drools-config.xml configuration file is where I keep the drools beans and looks like this:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:kie="http://drools.org/schema/kie-spring"
> xsi:schemaLocation="http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd http://drools.org/schema/kie-spring http://drools.org/schema/kie-spring.xsd">
> <kie:kmodule id="sample_module">
> <kie:kbase name="testRules" packages="rules" declarativeAgenda="true">
> <kie:ksession name="ksession1" type="stateless"/>
> <kie:ksession name="ksession2" scope="prototype">
> <kie:ruleRuntimeEventListener ref="mockRuleRuntimeEventListener" />
> <kie:consoleLogger />
> </kie:ksession>
> </kie:kbase>
> </kie:kmodule>
> <!-- https://docs.jboss.org/drools/release/7.30.0.Final/drools-docs/html_singl... -->
> <!-- <bean id="kiePostProcessor" class="org.kie.spring.KModuleBeanFactoryPostProcessor"/> -->
> <bean class="org.kie.spring.annotations.KModuleAnnotationPostProcessor"/>
> </beans>
> {code}
> occur a warn looks:
> 2019-12-19 14:44:25.231 WARN 9916 --- [ main] o.d.c.kie.builder.impl.KieProject : No files found for KieBase testRules
> when i try debug org.kie.spring.KModuleBeanFactoryPostProcessor. Trace to ZipKieModule at line 133. cannot uncompress,get variable urlPath value is "/BOOT-INF/classes" jarFile values is "\Users\user\Desktop\springdrools\target\spring-drools-1.0.jar!\BOOT-INF\classes". lead to cannot load resource.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12908) MicroProfile ConfigProviderResolver should be set eagerly
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-12908?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-12908:
--------------------------------
Description: Consumers of MicroProfile Config should not have to depend on a service to ensure that the static value returned by ConfigProviderResolver.instance() is defined. A simple model requirement on the mp-config capability should be sufficient. (was: Consumers of MicroProfile Config should not have to depend on a service to ensure that the static value returned by ConfigProviderResolver.instance() is defined.)
> MicroProfile ConfigProviderResolver should be set eagerly
> ---------------------------------------------------------
>
> Key: WFLY-12908
> URL: https://issues.redhat.com/browse/WFLY-12908
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 18.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Consumers of MicroProfile Config should not have to depend on a service to ensure that the static value returned by ConfigProviderResolver.instance() is defined. A simple model requirement on the mp-config capability should be sufficient.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4884) When a variable is reassigned in a consequence the property reactivity for the correspondent fact should be ignored
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4884?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4884:
--------------------------------
Sprint: 2020 Week 01-03 (from Dec 30) (was: 2019 Week 50-52 (from Dec 9))
> When a variable is reassigned in a consequence the property reactivity for the correspondent fact should be ignored
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4884
> URL: https://issues.redhat.com/browse/DROOLS-4884
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Major
>
> When a variable is reassigned in a consequence (not a good practice in general) the property reactivity for the correspondent fact should be ignored. In other word the following test should succeed.
> {code}
> @Test
> public void testReassignment() {
> final String str1 =
> "package com.example\n" +
> "\n" +
> "declare Counter\n" +
> " value1: int\n" +
> " value2: int\n" +
> "end\n" +
> "\n" +
> "rule \"Init\" when\n" +
> " not Counter()\n" +
> "then\n" +
> " drools.insert(new Counter(0, 0));\n" +
> "end\n" +
> "\n" +
> "rule \"Loop\"\n" +
> "when\n" +
> " $c: Counter( value1 == 0 )\n" +
> "then\n" +
> " $c = new Counter(0, 0);\n" +
> " $c.setValue2(1);\n" +
> " update($c);\n" +
> "end\n\n";
> final KieSession ksession = new KieHelper().addContent( str1, ResourceType.DRL )
> .build()
> .newKieSession();
> assertEquals( 5, ksession.fireAllRules(5) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12908) MicroProfile ConfigProviderResolver should be set eagerly
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12908:
-----------------------------------
Summary: MicroProfile ConfigProviderResolver should be set eagerly
Key: WFLY-12908
URL: https://issues.redhat.com/browse/WFLY-12908
Project: WildFly
Issue Type: Bug
Components: MP Config
Affects Versions: 18.0.1.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Consumers of MicroProfile Config should not have to depend on a service to ensure that the static value returned by ConfigProviderResolver.instance() is defined.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months