[JBoss JIRA] (WFCORE-526) "patch apply" over a CommandContext bound to existing ModelControllerClient fails
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-526?page=com.atlassian.jira.plugin... ]
Ladislav Thon updated WFCORE-526:
---------------------------------
Description:
I'm trying to apply a patch programmatically, using CLI as the API (which might be a bad idea, but all I'm doing is using public methods and interfaces). I already have a {{ModelControllerClient}}, so I create a {{CommandContext}} and bind it to my client:
{code}
ModelControllerClient client = ...;
CommandContext cliContext = CommandContextFactory.getInstance().newCommandContext();
cliContext.bindClient(client);
{code}
Then, I try to invoke the {{patch apply}} operation like this:
{code}
cliContext.handle("patch apply path/to/patch.zip");
{code}
This results in an exception:
{code}
Exception in thread "main" org.jboss.as.cli.CommandLineException: Failed to handle 'patch apply /home/lthon/Downloads/jboss-eap-6.3.3.CP.CR2-patch.zip'
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:660)
at cz.ladicek.wildfly.PatchingErrorReproducer.main(PatchingErrorReproducer.java:21)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: java.lang.IllegalStateException: failed to resolve a jboss.home.dir use the --distribution attribute to point to a valid installation
at org.jboss.as.patching.cli.PatchHandler.getJBossHome(PatchHandler.java:545)
at org.jboss.as.patching.cli.PatchHandler.createPatchOperationTarget(PatchHandler.java:518)
at org.jboss.as.patching.cli.PatchHandler.doHandle(PatchHandler.java:275)
at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:651)
... 6 more
{code}
The reason is that the patching CLI code, specifically the {{PatchHandler.createPatchOperationTarget}} method, reads {{CommandContext.getControllerHost()}} to find out if it is connected to a running server. In my case, {{getControllerHost()}} returns {{null}} because it was initialized using already-existing {{ModelControllerClient}}.
IMHO, patching code should use a more intelligent method to find out if it is connected to a running server.
Alternatively, this could be formulated as a bug of the core CLI code, because the {{getControllerHost()}} method is documented to _return the host the controller client is connected to or null if the connection hasn't been established yet_, which is arguably a lie when {{CommandContext.bindClient}} is used.
For reproducing, the "client" application depends on {{org.wildfly.core:wildfly-controller-client:1.0.0.Alpha16}} and {{org.wildfly.core:wildfly-patching:1.0.0.Alpha16}}, while the server is a clean build from current WildFly master (commit {{2ea95a18}}).
was:
I'm trying to apply a patch programmatically, using CLI as the API (which might be a bad idea, but all I'm doing is using public methods and interfaces). I already have a {{ModelControllerClient}}, so I create a {{CommandContext}} and bind it to my client:
{code}
ModelControllerClient client = ...;
CommandContext cliContext = CommandContextFactory.getInstance().newCommandContext();
cliContext.bindClient(client);
{code}
Then, I try to invoke the {{patch apply}} operation like this:
{code}
cliContext.handle("patch apply path/to/patch.zip");
{code}
This results in an exception:
{code}
Exception in thread "main" org.jboss.as.cli.CommandLineException: Failed to handle 'patch apply /home/lthon/Downloads/jboss-eap-6.3.3.CP.CR2-patch.zip'
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:660)
at cz.ladicek.wildfly.PatchingErrorReproducer.main(PatchingErrorReproducer.java:21)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: java.lang.IllegalStateException: failed to resolve a jboss.home.dir use the --distribution attribute to point to a valid installation
at org.jboss.as.patching.cli.PatchHandler.getJBossHome(PatchHandler.java:545)
at org.jboss.as.patching.cli.PatchHandler.createPatchOperationTarget(PatchHandler.java:518)
at org.jboss.as.patching.cli.PatchHandler.doHandle(PatchHandler.java:275)
at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:651)
... 6 more
{code}
The reason is that the patching CLI code, specifically the {{PatchHandler.createPatchOperationTarget}} method, reads {{CommandContext.getControllerHost()}} to find out if it is connected to a running server. In my case, {{getControllerHost()}} returns {{null}} because it was initialized using already-existing {{ModelControllerClient}}.
IMHO, patching code should use a more intelligent method to find out if it is connected to a running server.
Alternatively, this could be formulated as a bug of the core CLI code, because the {{getControllerHost()}} method is documented to _return the host the controller client is connected to or null if the connection hasn't been established yet_, which is arguably a lie when {{CommandContext.bindClient}} is used.
> "patch apply" over a CommandContext bound to existing ModelControllerClient fails
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-526
> URL: https://issues.jboss.org/browse/WFCORE-526
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Patching
> Reporter: Ladislav Thon
> Assignee: Alexey Loubyansky
>
> I'm trying to apply a patch programmatically, using CLI as the API (which might be a bad idea, but all I'm doing is using public methods and interfaces). I already have a {{ModelControllerClient}}, so I create a {{CommandContext}} and bind it to my client:
> {code}
> ModelControllerClient client = ...;
> CommandContext cliContext = CommandContextFactory.getInstance().newCommandContext();
> cliContext.bindClient(client);
> {code}
> Then, I try to invoke the {{patch apply}} operation like this:
> {code}
> cliContext.handle("patch apply path/to/patch.zip");
> {code}
> This results in an exception:
> {code}
> Exception in thread "main" org.jboss.as.cli.CommandLineException: Failed to handle 'patch apply /home/lthon/Downloads/jboss-eap-6.3.3.CP.CR2-patch.zip'
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:660)
> at cz.ladicek.wildfly.PatchingErrorReproducer.main(PatchingErrorReproducer.java:21)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Caused by: java.lang.IllegalStateException: failed to resolve a jboss.home.dir use the --distribution attribute to point to a valid installation
> at org.jboss.as.patching.cli.PatchHandler.getJBossHome(PatchHandler.java:545)
> at org.jboss.as.patching.cli.PatchHandler.createPatchOperationTarget(PatchHandler.java:518)
> at org.jboss.as.patching.cli.PatchHandler.doHandle(PatchHandler.java:275)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:651)
> ... 6 more
> {code}
> The reason is that the patching CLI code, specifically the {{PatchHandler.createPatchOperationTarget}} method, reads {{CommandContext.getControllerHost()}} to find out if it is connected to a running server. In my case, {{getControllerHost()}} returns {{null}} because it was initialized using already-existing {{ModelControllerClient}}.
> IMHO, patching code should use a more intelligent method to find out if it is connected to a running server.
> Alternatively, this could be formulated as a bug of the core CLI code, because the {{getControllerHost()}} method is documented to _return the host the controller client is connected to or null if the connection hasn't been established yet_, which is arguably a lie when {{CommandContext.bindClient}} is used.
> For reproducing, the "client" application depends on {{org.wildfly.core:wildfly-controller-client:1.0.0.Alpha16}} and {{org.wildfly.core:wildfly-patching:1.0.0.Alpha16}}, while the server is a clean build from current WildFly master (commit {{2ea95a18}}).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-526) "patch apply" over a CommandContext bound to existing ModelControllerClient fails
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-526:
------------------------------------
Summary: "patch apply" over a CommandContext bound to existing ModelControllerClient fails
Key: WFCORE-526
URL: https://issues.jboss.org/browse/WFCORE-526
Project: WildFly Core
Issue Type: Bug
Components: CLI, Patching
Reporter: Ladislav Thon
Assignee: Alexey Loubyansky
I'm trying to apply a patch programmatically, using CLI as the API (which might be a bad idea, but all I'm doing is using public methods and interfaces). I already have a {{ModelControllerClient}}, so I create a {{CommandContext}} and bind it to my client:
{code}
ModelControllerClient client = ...;
CommandContext cliContext = CommandContextFactory.getInstance().newCommandContext();
cliContext.bindClient(client);
{code}
Then, I try to invoke the {{patch apply}} operation like this:
{code}
cliContext.handle("patch apply path/to/patch.zip");
{code}
This results in an exception:
{code}
Exception in thread "main" org.jboss.as.cli.CommandLineException: Failed to handle 'patch apply /home/lthon/Downloads/jboss-eap-6.3.3.CP.CR2-patch.zip'
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:660)
at cz.ladicek.wildfly.PatchingErrorReproducer.main(PatchingErrorReproducer.java:21)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: java.lang.IllegalStateException: failed to resolve a jboss.home.dir use the --distribution attribute to point to a valid installation
at org.jboss.as.patching.cli.PatchHandler.getJBossHome(PatchHandler.java:545)
at org.jboss.as.patching.cli.PatchHandler.createPatchOperationTarget(PatchHandler.java:518)
at org.jboss.as.patching.cli.PatchHandler.doHandle(PatchHandler.java:275)
at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:651)
... 6 more
{code}
The reason is that the patching CLI code, specifically the {{PatchHandler.createPatchOperationTarget}} method, reads {{CommandContext.getControllerHost()}} to find out if it is connected to a running server. In my case, {{getControllerHost()}} returns {{null}} because it was initialized using already-existing {{ModelControllerClient}}.
IMHO, patching code should use a more intelligent method to find out if it is connected to a running server.
Alternatively, this could be formulated as a bug of the core CLI code, because the {{getControllerHost()}} method is documented to _return the host the controller client is connected to or null if the connection hasn't been established yet_, which is arguably a lie when {{CommandContext.bindClient}} is used.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (DROOLS-629) NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-629?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-629:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1181584|https://bugzilla.redhat.com/show_bug.cgi?id=1181584] from ON_QA to VERIFIED
> NullPointerException thrown on next call to insert and fireAllRules after stream garbage collection runs
> --------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-629
> URL: https://issues.jboss.org/browse/DROOLS-629
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta3
> Reporter: Mike Wilson
> Assignee: Mario Fusco
> Fix For: 6.2.0.CR1
>
> Attachments: drools-gc-causes-npe-example.zip
>
>
> I have observed that the following NullPointerException (NPE) occurs consistently with a very specific set of rules and a very specific set of inputs into a stream session:
> {code}
> java.lang.NullPointerException
> at org.drools.core.util.AbstractHashTable$SingleIndex.equal(AbstractHashTable.java:491)
> at org.drools.core.util.index.LeftTupleList.matches(LeftTupleList.java:266)
> at org.drools.core.util.index.LeftTupleIndexHashTable.get(LeftTupleIndexHashTable.java:434)
> at org.drools.core.util.index.LeftTupleIndexHashTable.getFirst(LeftTupleIndexHashTable.java:217)
> at org.drools.core.reteoo.BetaNode.getFirstLeftTuple(BetaNode.java:443)
> at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:144)
> at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:548)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:534)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:229)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:98)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:988)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1274)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1254)
> ...
> {code}
> The exception always occurs on the next call to "insert" and "fireAllRules" after the following method is invoked within the session: org.drools.core.common.DefaultAgenda$DefaultGarbageCollector.forceGcUnlinkedRules().
> I have attached a maven project that contains a JUnit test, which reproduces this exception using Drools version 6.2.0.Beta3.
> A side effect of this exeption occurring in the middle of fireAllRules is that an extra fact is left over in working memory, which is essentially a memory leak. I assume this is because the evaluation of the LHS of the rules is what causes the NPE to occur, so the fact is not deleted, because the RHS of the rules don't execute.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-499) System properties are broken in domain mode
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-499?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet commented on WFCORE-499:
------------------------------------------
The "boot-time" attribute is not defined for standalone servers, thus also for managed servers.
> System properties are broken in domain mode
> -------------------------------------------
>
> Key: WFCORE-499
> URL: https://issues.jboss.org/browse/WFCORE-499
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: Stuart Douglas
> Assignee: Emmanuel Hugonnet
>
> There seems to be some weirdness in how system properties are being propagated to domain mode servers, and in many cases they are not being applied.
> This appears to be an issue with the boot time handling of system properties.
> The only way I could get the property to be applied was to start the server first, then add the property using boot-time=false, although even in this case the property will disappear if the domain is restarted or the server is reloaded.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-694:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> accumulate with sliding window and other LHS condition
> ------------------------------------------------------
>
> Key: DROOLS-694
> URL: https://issues.jboss.org/browse/DROOLS-694
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR4
> Environment: fail with PHREAK, work correctly as expected with RETEOO
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: 20150121.accumulate-window-counter.zip
>
>
> With reference to attached reproducer.
> Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour.
> {code:java}
> declare Measurement
> @role(event)
> end
> rule "Init Counter last 1h"
> agenda-group "USERSPACE"
> salience 1
> no-loop
> when
> not Counter( name == "Counter last 1h" )
> then
> Counter c = new Counter("Counter last 1h", 0);
> insert(c);
> System.out.println("RHS Init Counter last 1h " + c);
> end
> rule "Update Counter last 1h"
> agenda-group "USERSPACE"
> no-loop
> when
> accumulate( $token : Measurement() over window:time( 1h ) ;
> $val : count($token)
> )
> $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() )
> then
> int count = $val.intValue();
> $cv1.setValue(count);
> update($cv1);
> System.out.println("RHS Update Counter last 1h : "+$cv1);
> end
> {code}
> The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Measurement("voltage", "220"));
> fire(session);
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Measurement("voltage", "221"));
> fire(session);
> LOG.info("Final checks");
> Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM
> assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0);
> {code}
> However this works only with ReteOO and the test FAILS with Phreak.
> Can you kindly advise, please?
> Thank you
> MM
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-694:
------------------------------------
Ciao Matteo, I just started investigating this test case and the problem seems to be caused by the no-loop in the 2nd rule. You really don't need it and removing the no-loop fixes your test cases. Moreover the problem seems not related with the use of a sliding window of with the stream mode at all. I can reproduce the same issue even removing them. I'm now trying to develop a simple reproducer with only the strictly necessary ingredients and figure out what's going wrong. In the meanwhile I hope this hint could be of some help for you.
> accumulate with sliding window and other LHS condition
> ------------------------------------------------------
>
> Key: DROOLS-694
> URL: https://issues.jboss.org/browse/DROOLS-694
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR4
> Environment: fail with PHREAK, work correctly as expected with RETEOO
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20150121.accumulate-window-counter.zip
>
>
> With reference to attached reproducer.
> Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour.
> {code:java}
> declare Measurement
> @role(event)
> end
> rule "Init Counter last 1h"
> agenda-group "USERSPACE"
> salience 1
> no-loop
> when
> not Counter( name == "Counter last 1h" )
> then
> Counter c = new Counter("Counter last 1h", 0);
> insert(c);
> System.out.println("RHS Init Counter last 1h " + c);
> end
> rule "Update Counter last 1h"
> agenda-group "USERSPACE"
> no-loop
> when
> accumulate( $token : Measurement() over window:time( 1h ) ;
> $val : count($token)
> )
> $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() )
> then
> int count = $val.intValue();
> $cv1.setValue(count);
> update($cv1);
> System.out.println("RHS Update Counter last 1h : "+$cv1);
> end
> {code}
> The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Measurement("voltage", "220"));
> fire(session);
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Measurement("voltage", "221"));
> fire(session);
> LOG.info("Final checks");
> Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM
> assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0);
> {code}
> However this works only with ReteOO and the test FAILS with Phreak.
> Can you kindly advise, please?
> Thank you
> MM
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-672?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-672.
--------------------------------
Fix Version/s: 6.2.0.Final
Resolution: Duplicate Issue
This issue has been already reported here https://bugzilla.redhat.com/show_bug.cgi?id=1117954 and fixed with this commit https://github.com/droolsjbpm/drools/commit/5e05721f4a81d9f80285c0dc1216d...
> Drools audit log view cannot be opened
> --------------------------------------
>
> Key: DROOLS-672
> URL: https://issues.jboss.org/browse/DROOLS-672
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Reporter: Jose Luis Melgar
> Assignee: Mario Fusco
> Labels: Drools
> Fix For: 6.2.0.Final
>
>
> On behalf of Gergely Bacso:
> {quote}
> From: Mark Proctor
> Sent: 20/12/2014 21:15
> To: drools-setup(a)googlegroups.com
> Cc: Bob Brodt
> Subject: Re: [drools-setup] Drools audit log view cannot be opened
> please open a JIRA, so we can be sure to fix this.
> Thanks
> Mark
> {quote}
> {quote}
> On 19 Dec 2014, at 18:19, Gergely Bacsó wrote:
> Hi,
> First of all: this problem can be reproduced with only a single audit file.
> I managed to get closer to the solution by spending a few hours reading Drools source code:
> The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up:
> http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop())
> Since my audit logs for some reason contain several of
> AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays.
> Gergely
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-672?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-672:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Drools audit log view cannot be opened
> --------------------------------------
>
> Key: DROOLS-672
> URL: https://issues.jboss.org/browse/DROOLS-672
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Reporter: Jose Luis Melgar
> Assignee: Mario Fusco
> Labels: Drools
>
> On behalf of Gergely Bacso:
> {quote}
> From: Mark Proctor
> Sent: 20/12/2014 21:15
> To: drools-setup(a)googlegroups.com
> Cc: Bob Brodt
> Subject: Re: [drools-setup] Drools audit log view cannot be opened
> please open a JIRA, so we can be sure to fix this.
> Thanks
> Mark
> {quote}
> {quote}
> On 19 Dec 2014, at 18:19, Gergely Bacsó wrote:
> Hi,
> First of all: this problem can be reproduced with only a single audit file.
> I managed to get closer to the solution by spending a few hours reading Drools source code:
> The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up:
> http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop())
> Since my audit logs for some reason contain several of
> AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays.
> Gergely
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months