[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Yacine Jaber (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Yacine Jaber updated DROOLS-702:
--------------------------------
Attachment: wod-drools-test.7z
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Mark Proctor
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Yacine Jaber (JIRA)
Yacine Jaber created DROOLS-702:
-----------------------------------
Summary: Rule Inheritance fired the sub rule even the condition doen't match
Key: DROOLS-702
URL: https://issues.jboss.org/browse/DROOLS-702
Project: Drools
Issue Type: Bug
Affects Versions: 6.1.0.Final
Environment: Windows, Java6.0.29
Reporter: Yacine Jaber
Assignee: Mark Proctor
Priority: Critical
You can find the attached a simple maven project that shows this error.
You can run ExampleDrools class as main java application.
The sub rules are fired even if the condition is not matched.
There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 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 resolved DROOLS-694.
--------------------------------
Fix Version/s: 6.2.0.Final
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/fa05dcc5d
> 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
> Fix For: 6.2.0.Final
>
> 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)
11 years, 2 months
[JBoss JIRA] (WFLY-4299) transaction subsystem node-identifier can not resolve expression
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-4299?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-4299:
-----------------------------------
Priority: Critical (was: Major)
> transaction subsystem node-identifier can not resolve expression
> ----------------------------------------------------------------
>
> Key: WFLY-4299
> URL: https://issues.jboss.org/browse/WFLY-4299
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: configuration, configuration_management, domain
>
> If the transaction subsystem should use an expression as node-identifier this will not work in domain mode:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 36) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "WFLYCTL0211: Cannot resolve expression '${txNodeIdentifier}'"
> This was possible in former builds with the same configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4299) transaction subsystem node-identifier can not resolve expression
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-4299:
--------------------------------------
Summary: transaction subsystem node-identifier can not resolve expression
Key: WFLY-4299
URL: https://issues.jboss.org/browse/WFLY-4299
Project: WildFly
Issue Type: Bug
Components: Domain Management
Affects Versions: 9.0.0.Alpha1
Reporter: Wolf-Dieter Fink
Assignee: Brian Stansberry
If the transaction subsystem should use an expression as node-identifier this will not work in domain mode:
ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 36) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "WFLYCTL0211: Cannot resolve expression '${txNodeIdentifier}'"
This was possible in former builds with the same configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[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)
11 years, 2 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)
11 years, 2 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)
11 years, 2 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)
11 years, 2 months