[JBoss JIRA] (WFLY-3630) NonPersistentIntervalTimerManagementTestCase fails sometimes
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-3630?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3630:
-----------------------------------
Component/s: Test Suite
> NonPersistentIntervalTimerManagementTestCase fails sometimes
> ------------------------------------------------------------
>
> Key: WFLY-3630
> URL: https://issues.jboss.org/browse/WFLY-3630
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Affects Versions: 9.0.0.Alpha1
> Environment: Windows 7 SP1, Oracle JDK 1.7.0_60
> Reporter: Frank Langelage
> Priority: Major
>
> Testcase org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase fails sometimes for me when running build with all tests on Windows machine. I never saw this failure on my Solaris box using the same JDK version. And somehow the appearance of the failure seem to be related to the execution time.
> Executing the testsuite during the day does not show me this error. Only in the very late evening / early morning hours the error appeared. (All related to Central European Summer time in my case.)
> I added some debug output an saw, that, in case of failure, after "activateTimer" the timer fires immediately so that there is one timeout too much then. The initial timeout time of the timer is passed, when it's suspended. When activated it seems to make good for the missed timeout sometimes.
> The persistent version of this testcase located in the same package with exactly same logic never fails for me.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-1026) Require method to determine best-guess classpath for projects targeted to non-running server
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-1026?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-1026.
------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
Resolution: Won't Do
I don't see us going beyond providing the https://github.com/wildfly/boms boms for each release.
> Require method to determine best-guess classpath for projects targeted to non-running server
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-1026
> URL: https://issues.jboss.org/browse/WFLY-1026
> Project: WildFly
> Issue Type: Enhancement
> Components: Server
> Reporter: Rob Stryker
> Assignee: Brian Stansberry
> Priority: Critical
>
> JBossTools requires some method to discover from a non-running server which jars should be added to a project as exposed for clients (the project) to use. This should be a best-guess and does not need to be complete, but it's better if there is a way to determine which jars are public or private.
> I'm not sure if this would be best addressed by jboss-modules, or some type of marker files (which it could be argued is a bad solution and we have too many such workarounds), or what.
> Previous possible solutions introspected the xml files for each module to determine what jars / packages were public / private, but this was deemed unacceptable for reaching into a modules folder by ourselves.
> Before that, we simply hard-coded which jars or folders to add for each app server version.
> Requiring a running server violates our use case. Speed is of a high importance, and so therefore launching a new VM against a main class in jboss-modules is also not a great solution.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-1187) Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
by Vratislav Marek (Jira)
[ https://issues.jboss.org/browse/WFCORE-1187?page=com.atlassian.jira.plugi... ]
Vratislav Marek commented on WFCORE-1187:
-----------------------------------------
I try to reproduce this issue by steps in the description but commands it's out of date.
Command "_start-embedded-server_" is replaced by "_embed-server_".
In run from a current build from master branch, command "_embed-server_" unrecognize argument "_--jboss-home_".
{code:java}
[disconnected /] embed-server --jboss-home="/tmp/2019-01-25/WFCORE-1187/firstLog"
Unrecognized arguments: [--jboss-home]
{code}
But in command help is written like a valid argument.
{code:java}
[disconnected /] help embed-server
SYNOPSIS
embed-server [--admin-only=true|false]
[-c=config_file || --server-config=config_file]
[--empty-config --remove-existing-config]
[--jboss-home=rootdir]
[--stdout=discard|echo]
DESCRIPTION
Launches a standalone server embedded in the CLI process.
ARGUMENTS
...
--jboss-home - Filesystem path pointing to the root directory
of the installation from which the embedded server
should run. Only available if the CLI itself
is not running in a modular classloading environment.
In a non-modular classloading environment, if this
option is not specified, the value of the
environment variable JBOSS_HOME will be used.
Must be specified if the environment variable
JBOSS_HOME is not set.In a modular classloading
environment it is assumed the CLI is running from
the server installation itself and the JBOSS_HOME
environment variable must be set.
...
{code}
> Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1187
> URL: https://issues.jboss.org/browse/WFCORE-1187
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Ken Wills
> Assignee: ehsavoie Hugonnet
> Priority: Major
>
> - start-embedded-server --jboss-home=/foo/bar1
> - stop-embedded-server
> - start-embedded-server --jboss-home=/foo/bar2
> -- server.log in /foo/bar1/standalone/logs/server.log is still written to.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-1016) Improvement of Message "...PARSE: JBAS018733: Failed to process phase PARSE of subdeployment..."
by Carsten Maneg (Jira)
[ https://issues.jboss.org/browse/WFLY-1016?page=com.atlassian.jira.plugin.... ]
Carsten Maneg closed WFLY-1016.
-------------------------------
Fix Version/s: No Release
Resolution: Done
Too old ....
> Improvement of Message "...PARSE: JBAS018733: Failed to process phase PARSE of subdeployment..."
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-1016
> URL: https://issues.jboss.org/browse/WFLY-1016
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Environment: Windows
> Reporter: Carsten Maneg
> Priority: Minor
> Fix For: No Release
>
>
> The error message could be improved to tell the file name which was parsed (web.xml in this case).
> I check the similar issues but don't find this one.
> Stacktrace:
> 10:24:31,343 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."MyAppCMP-intern.ear"."myApp-ptweb-4.3.0-SNAPSHOT.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."MyAppCMP-intern.ear"."myApp-ptweb-4.3.0-SNAPSHOT.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "myApp-ptweb-4.3.0-SNAPSHOT.war" of deployment "MyAppCMP-intern.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalArgumentException: No enum const class org.jboss.metadata.javaee.spec.EJBReferenceType.Stateless
> at java.lang.Enum.valueOf(Enum.java:196) [rt.jar:1.6.0_31]
> at org.jboss.metadata.javaee.spec.EJBReferenceType.valueOf(EJBReferenceType.java:30)
> at org.jboss.metadata.parser.ee.EJBReferenceMetaDataParser.parse(EJBReferenceMetaDataParser.java:77)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parseRemote(EnvironmentRefsGroupMetaDataParser.java:102)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parse(EnvironmentRefsGroupMetaDataParser.java:75)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parse(EnvironmentRefsGroupMetaDataParser.java:51)
> at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:178)
> at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:55)
> at org.jboss.as.web.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-1016) Improvement of Message "...PARSE: JBAS018733: Failed to process phase PARSE of subdeployment..."
by Carsten Maneg (Jira)
[ https://issues.jboss.org/browse/WFLY-1016?page=com.atlassian.jira.plugin.... ]
Carsten Maneg commented on WFLY-1016:
-------------------------------------
Was related to AS 7.1 (stacktrace) and is nearly 7 years old.
Of course not relevant for WildFly.
> Improvement of Message "...PARSE: JBAS018733: Failed to process phase PARSE of subdeployment..."
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-1016
> URL: https://issues.jboss.org/browse/WFLY-1016
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Environment: Windows
> Reporter: Carsten Maneg
> Priority: Minor
>
> The error message could be improved to tell the file name which was parsed (web.xml in this case).
> I check the similar issues but don't find this one.
> Stacktrace:
> 10:24:31,343 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."MyAppCMP-intern.ear"."myApp-ptweb-4.3.0-SNAPSHOT.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."MyAppCMP-intern.ear"."myApp-ptweb-4.3.0-SNAPSHOT.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "myApp-ptweb-4.3.0-SNAPSHOT.war" of deployment "MyAppCMP-intern.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalArgumentException: No enum const class org.jboss.metadata.javaee.spec.EJBReferenceType.Stateless
> at java.lang.Enum.valueOf(Enum.java:196) [rt.jar:1.6.0_31]
> at org.jboss.metadata.javaee.spec.EJBReferenceType.valueOf(EJBReferenceType.java:30)
> at org.jboss.metadata.parser.ee.EJBReferenceMetaDataParser.parse(EJBReferenceMetaDataParser.java:77)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parseRemote(EnvironmentRefsGroupMetaDataParser.java:102)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parse(EnvironmentRefsGroupMetaDataParser.java:75)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parse(EnvironmentRefsGroupMetaDataParser.java:51)
> at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:178)
> at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:55)
> at org.jboss.as.web.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-1016) Improvement of Message "...PARSE: JBAS018733: Failed to process phase PARSE of subdeployment..."
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-1016?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFLY-1016:
-----------------------------------
Not sure which version has this been reported against (based on the stacktrace, there is JDK-1.6 used, 'jboss-as-server' mentions; was it even WildFly? maybe this referred to JBoss AS?).
Anyway, I think this is not relevant for WildFly anymore (or it never was) - I tried following with {{WildFly 15.0.1.Final}} using [wicket-ear app|https://github.com/wildfly/quickstart/tree/15.0.1.Final/wicket-ear]:
# get the app
# modify web.xml by adding some nonsense element in it ('<pokus/>' in my case)
# compile app and deploy it to server
# see following error messages in server.log:
{code}
12:32:36,611 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-wicket-ear-ear.ear"."wildfly-wicket-ear-war.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-wicket-ear-ear.ear"."wildfly-wicket-ear-war.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "wildfly-wicket-ear-war.war" of deployment "wildfly-wicket-ear-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
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)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYUT0027: Failed to parse XML descriptor "/content/wildfly-wicket-ear-ear.ear/wildfly-wicket-ear-war.war/WEB-INF/web.xml" at [49,5]
at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:134)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
... 8 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[49,5]
Message: Unexpected element '{http://java.sun.com/xml/ns/javaee}pokus' encountered
at org.jboss.metadata.parser.util.MetaDataElementParser.unexpectedElement(MetaDataElementParser.java:115)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:196)
at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:51)
at org.wildfly.extension.undertow.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:96)
... 9 more
12:32:36,622 INFO [org.jboss.as.jpa] (MSC service thread 1-5) WFLYJPA0002: Read persistence.xml for primary
12:32:36,624 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "wildfly-wicket-ear-ear.ear"}) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"wildfly-wicket-ear-ear.ear\".\"wildfly-wicket-ear-war.war\".PARSE" => "WFLYSRV0153: Failed to process phase PARSE of subdeployment \"wildfly-wicket-ear-war.war\" of deployment \"wildfly-wicket-ear-ear.ear\"
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYUT0027: Failed to parse XML descriptor \"/content/wildfly-wicket-ear-ear.ear/wildfly-wicket-ear-war.war/WEB-INF/web.xml\" at [49,5]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[49,5]
Message: Unexpected element '{http://java.sun.com/xml/ns/javaee}pokus' encountered"}}
12:32:36,625 ERROR [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0021: Deploy of deployment "wildfly-wicket-ear-ear.ear" was rolled back with the following failure message:
{"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"wildfly-wicket-ear-ear.ear\".\"wildfly-wicket-ear-war.war\".PARSE" => "WFLYSRV0153: Failed to process phase PARSE of subdeployment \"wildfly-wicket-ear-war.war\" of deployment \"wildfly-wicket-ear-ear.ear\"
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYUT0027: Failed to parse XML descriptor \"/content/wildfly-wicket-ear-ear.ear/wildfly-wicket-ear-war.war/WEB-INF/web.xml\" at [49,5]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[49,5]
Message: Unexpected element '{http://java.sun.com/xml/ns/javaee}pokus' encountered"}}
12:32:36,632 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0208: Stopped subdeployment (runtime-name: wildfly-wicket-ear-ejb.jar) in 7ms
12:32:36,652 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: wildfly-wicket-ear-war.war) in 27ms
12:32:36,657 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment wildfly-wicket-ear-ear.ear (runtime-name: wildfly-wicket-ear-ear.ear) in 32ms
{code}
See that there is clearly stated filename which caused the deployment problem, pointing to particular place in the file.
> Improvement of Message "...PARSE: JBAS018733: Failed to process phase PARSE of subdeployment..."
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-1016
> URL: https://issues.jboss.org/browse/WFLY-1016
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Environment: Windows
> Reporter: Carsten Maneg
> Priority: Minor
>
> The error message could be improved to tell the file name which was parsed (web.xml in this case).
> I check the similar issues but don't find this one.
> Stacktrace:
> 10:24:31,343 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."MyAppCMP-intern.ear"."myApp-ptweb-4.3.0-SNAPSHOT.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."MyAppCMP-intern.ear"."myApp-ptweb-4.3.0-SNAPSHOT.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "myApp-ptweb-4.3.0-SNAPSHOT.war" of deployment "MyAppCMP-intern.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.IllegalArgumentException: No enum const class org.jboss.metadata.javaee.spec.EJBReferenceType.Stateless
> at java.lang.Enum.valueOf(Enum.java:196) [rt.jar:1.6.0_31]
> at org.jboss.metadata.javaee.spec.EJBReferenceType.valueOf(EJBReferenceType.java:30)
> at org.jboss.metadata.parser.ee.EJBReferenceMetaDataParser.parse(EJBReferenceMetaDataParser.java:77)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parseRemote(EnvironmentRefsGroupMetaDataParser.java:102)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parse(EnvironmentRefsGroupMetaDataParser.java:75)
> at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parse(EnvironmentRefsGroupMetaDataParser.java:51)
> at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:178)
> at org.jboss.metadata.parser.servlet.WebMetaDataParser.parse(WebMetaDataParser.java:55)
> at org.jboss.as.web.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-2646) KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
by Olga Rodionova (Jira)
[ https://issues.jboss.org/browse/DROOLS-2646?page=com.atlassian.jira.plugi... ]
Olga Rodionova commented on DROOLS-2646:
----------------------------------------
Found out another issue which may be related to this one: https://issues.jboss.org/browse/DROOLS-3554
> KieContainer#updateToVersion removing rules: logically inserted objects not removed correctly
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2646
> URL: https://issues.jboss.org/browse/DROOLS-2646
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Olga Rodionova
> Assignee: Mario Fusco
> Priority: Major
> Attachments: RuleRemovalABTest.java, SimpleRuleAB.drl
>
>
> Consider two rules which have one of the patterns in common, each of which logically inserts an object in the RHS. Build the KieModule from the KieFileSystem including these rules, create the KieContainer and the KieSession. Insert the facts. Everything works fine.
> Create a new KieModule excluding these rules from the KieFileSystem, update the KieContainer. Expect the logically inserted facts to be retracted, as the rules which trigged their creation is no longer present. Turns out that is true for the facts inserted by the first rule, but not for the second one: the facts remain in the working memory.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3554) KieContainer#updateToVersion removing rules with accumulate
by Olga Rodionova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3554?page=com.atlassian.jira.plugi... ]
Olga Rodionova commented on DROOLS-3554:
----------------------------------------
Probably related with issue https://issues.jboss.org/browse/DROOLS-2646 which has already been resolved
> KieContainer#updateToVersion removing rules with accumulate
> -----------------------------------------------------------
>
> Key: DROOLS-3554
> URL: https://issues.jboss.org/browse/DROOLS-3554
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.16.0.Final
> Reporter: Olga Rodionova
> Assignee: Mario Fusco
> Priority: Major
> Attachments: RuleRemovalTest.java, SimpleRuleWithAccumulate.drl
>
>
> Consider a rule with accumulate pattern in the LHS which logically inserts an object in the RHS. Build the KieModule from the KieFileSystem including this rule, create the KieContainer and the KieSession. Insert the facts. Everything works fine.
> Create a new KieModule excluding this rule from the KieFileSystem, update the KieContainer. Expect the logically inserted fact to be retracted, as the rule which trigged its creation is no longer present. Turns out that the fact is still present in the working memory
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months