[JBoss JIRA] (DROOLS-1737) Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1737?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1737.
---------------------------------
Resolution: Rejected
This is not a bug but the consequence of having enabled by default property reactivity in drools 7.x. See http://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single/...
In your case you probably may want to disable it. In fact if you (for instance) add the following to your main class also drools 7.2.0 will work as you expect.
{code}
System.setProperty( "drools.propertySpecific", "ALLOWED" );
{code}
> Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
> ---------------------------------------------------------------
>
> Key: DROOLS-1737
> URL: https://issues.jboss.org/browse/DROOLS-1737
> Project: Drools
> Issue Type: Bug
> Reporter: Nikolay Plekhanov
> Assignee: Mario Fusco
> Attachments: drools720issue.zip
>
>
> We are trying to migrate project on newest version of drools, but had regression testing failure. We have extracted simplest scenario to reproduce it.
> {code}
> package demo
> import demo.DataRow;
> import demo.ExpectedError;
> import demo.Dark;
> rule "rule-1"
> salience 130
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID, $d: row[Dark.Xantor.wand] != null)
> $b: DataRow(viewId == Dark.Aragorn.$ID, row[Dark.Aragorn.sword] == $d)
> $c: DataRow(viewId == Dark.Tant.$ID, row[Dark.Tant.crown] == $d)
> then
> $a.setField(Dark.Xantor.sword, $c.getField(Dark.Tant.sword));
> $a.setField(Dark.Xantor.chainmail, $c.getField(Dark.Tant.tower));
> update($a);
> end
> rule "rule-2"
> salience 110
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID,
> $b: row[Dark.Xantor.wand] != null,
> row[Dark.Xantor.sword] == "claymore",
> row[Dark.Xantor.bow] == null)
> then
> throw new ExpectedError();
> end
> {code}
> initial facts:
> {code}
> Dark.Tant( crown: 123, sword: claymore )
> Dark.Aragorn( sword: 123 )
> Dark.Xantor( wand: 123 )
> {code}
> Expected to catch ExpectedError (rule-2 to be fired), but nothing happens.
> Detailed exploit attached as Maven project with two executable modules. Main650 class demonstrates positive scenario (it run rules with 6.5.0.Final), Main720 (runs the same rules with 7.2.0.Final) - negative. "Main" class contains basic scenario without link to drools version
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1737) Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1737?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1737:
--------------------------------
Sprint: 2017 Week 36-37
> Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
> ---------------------------------------------------------------
>
> Key: DROOLS-1737
> URL: https://issues.jboss.org/browse/DROOLS-1737
> Project: Drools
> Issue Type: Bug
> Reporter: Nikolay Plekhanov
> Assignee: Mario Fusco
> Attachments: drools720issue.zip
>
>
> We are trying to migrate project on newest version of drools, but had regression testing failure. We have extracted simplest scenario to reproduce it.
> {code}
> package demo
> import demo.DataRow;
> import demo.ExpectedError;
> import demo.Dark;
> rule "rule-1"
> salience 130
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID, $d: row[Dark.Xantor.wand] != null)
> $b: DataRow(viewId == Dark.Aragorn.$ID, row[Dark.Aragorn.sword] == $d)
> $c: DataRow(viewId == Dark.Tant.$ID, row[Dark.Tant.crown] == $d)
> then
> $a.setField(Dark.Xantor.sword, $c.getField(Dark.Tant.sword));
> $a.setField(Dark.Xantor.chainmail, $c.getField(Dark.Tant.tower));
> update($a);
> end
> rule "rule-2"
> salience 110
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID,
> $b: row[Dark.Xantor.wand] != null,
> row[Dark.Xantor.sword] == "claymore",
> row[Dark.Xantor.bow] == null)
> then
> throw new ExpectedError();
> end
> {code}
> initial facts:
> {code}
> Dark.Tant( crown: 123, sword: claymore )
> Dark.Aragorn( sword: 123 )
> Dark.Xantor( wand: 123 )
> {code}
> Expected to catch ExpectedError (rule-2 to be fired), but nothing happens.
> Detailed exploit attached as Maven project with two executable modules. Main650 class demonstrates positive scenario (it run rules with 6.5.0.Final), Main720 (runs the same rules with 7.2.0.Final) - negative. "Main" class contains basic scenario without link to drools version
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9364) Closing an EJBClientContext sometimes hangs causing high CPU usage
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9364?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-9364:
------------------------------------
I don't think there will be any more 10.x releases, but I am just a community member, so it's not an official word.
Having said that, looking at that stacktrace and from what you say about SSL, I think this issue might be related to REM3-262 which has been fixed in jboss-remoting https://github.com/jboss-remoting/jboss-remoting/commit/a9c227b712a3fd593.... What you could do is, *on the client application side* use 4.0.24.Final of jboss-remoting (currently the application you attached is using 4.0.21 shaded in the jboss-client.jar) and 3.4.6.Final of xnio libraries. How you set up your client side classpath with these set of versions is something that you will have to fiddle around a bit (these libraries won't end up in the shaded jboss-client.jar since that jar is provided by the WildFly distribution).
> Closing an EJBClientContext sometimes hangs causing high CPU usage
> ------------------------------------------------------------------
>
> Key: WFLY-9364
> URL: https://issues.jboss.org/browse/WFLY-9364
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: Server:
> - OS:
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> - JDK:
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
> - WildFly:
> WildFly 10.1.0.Final
> Client:
> - OS:
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> - JDK:
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
> Reporter: Marius Tantareanu
> Assignee: Jason Greene
> Attachments: echo-client.zip, output_rhel7.txt, output_win10.txt, simple-ear.ear, td_rhel7.txt, td_win10.txt
>
>
> EJBClientContext.close() sometimes hangs and causes high CPU usage. We have a WildFly client that uses EJB client API to invoke some EJBs remotely.
> Basically the client executes the following actions in a loop:
> - setup an EJBClientContext programatically
> - create a JNDI context
> - lookup an EJB and invoke some operations on it
> - close the JNDI context and the EJBClientContext
> After the client runs a few hundreds iterations (the actual number of iterations varies quite a lot from one run to another) it blocks while invoking EJBClientContext.close(). Also one XNIO thread in the client app is constantly consuming one CPU core (full thread dump from the client app is attached). I was only able to reproduce this when connecting over TLS (port 8443). When using the unsecure port (8080) the problem does not reproduce (or it reproduces much less frequently and I didn't run enough iterations to catch it).
> Once the client app enters this state, top shows something like (notice the CPU usage of thread 12512):
> >top -H -p 6463
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 12512 root 20 0 11.527g 222680 13788 R 99.3 0.7 141:10.99 java
> 6466 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:07.05 java
> 6467 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:06.97 java
> 6477 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:04.24 java
> 6463 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 6464 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:03.46 java
> 6465 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.94 java
> 6468 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:07.02 java
> 6469 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:16.42 java
> 6470 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.01 java
> 6471 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.01 java
> 6472 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 6473 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.87 java
> 6474 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.70 java
> 6475 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:03.09 java
> 6476 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12513 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12514 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12515 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12516 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12517 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12518 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12519 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12520 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12523 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12524 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> 12597 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java
> The thread that causes the CPU usage is the following:
> "Remoting "config-based-ejb-client-endpoint" I/O-1" #6025 daemon prio=5 os_prio=0 tid=0x00007f2f709d3000 nid=0x30e0 runnable [0x00007f2e7f9be000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x00000005cc1844e8> (a sun.nio.ch.Util$3)
> - locked <0x00000005cc19f258> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000005cc184468> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> The client app main thread is blocked as below:
> "main" #1 prio=5 os_prio=0 tid=0x00007f2f70008800 nid=0x1940 in Object.wait() [0x00007f2f76350000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190)
> - locked <0x00000005cc18de48> (a java.lang.Object)
> at org.jboss.ejb.client.remoting.ConnectionPool.safeClose(ConnectionPool.java:177)
> at org.jboss.ejb.client.remoting.ConnectionPool.release(ConnectionPool.java:104)
> - locked <0x00000005cbd369e0> (a org.jboss.ejb.client.remoting.ConnectionPool)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.close(ConnectionPool.java:198)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.safeClose(RemotingConnectionManager.java:65)
> - locked <0x00000005cc1a6840> (a java.util.Collections$SynchronizedRandomAccessList)
> at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector$ContextCloseListener.contextClosed(ConfigBasedEJBClientContextSelector.java:220)
> at org.jboss.ejb.client.EJBClientContext.close(EJBClientContext.java:1305)
> - locked <0x00000005cc1a6888> (a org.jboss.ejb.client.EJBClientContext)
> at com.microfocus.echoclient.EchoClient.disconnect(EchoClient.java:66)
> at com.microfocus.echoclient.EchoClient.connectDisconnect(EchoClient.java:54)
> at com.microfocus.echoclient.EchoClient.main(EchoClient.java:36)
> The problem also reproduces on Windows (full thread dump of the client app is attached).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1729) Unable to load rule with global variables via kiescanner.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1729?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1729:
--------------------------------
Sprint: 2017 Week 36-37
> Unable to load rule with global variables via kiescanner.
> ---------------------------------------------------------
>
> Key: DROOLS-1729
> URL: https://issues.jboss.org/browse/DROOLS-1729
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Pedro Almeida
> Assignee: Mario Fusco
> Priority: Blocker
>
> I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
> Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted for.
> *Errors:*
> 1) "A Sliding Window can only be assigned to types declared with @role( event )
> [Actually my object type is declared with role event on the master drl]
> 2) "isTest cannot be resolved"
> [isTest being my global variable]
> *Rule:*
> package rules;
> import model.Car;
> global Boolean isTest;
> rule "Red Car"
> when
> Car (color=="Red") over window:time(2h);
> then
> System.out.println("*** Red car");
> System.out.println("*** " + isTest);
> end
> *Master Drl*
> package rules;
> import model.Car;
> global Boolean isTest;
> declare Car
> @role( event )
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1729) Unable to load rule with global variables via kiescanner.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1729?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1729.
---------------------------------
Resolution: Cannot Reproduce Bug
> Unable to load rule with global variables via kiescanner.
> ---------------------------------------------------------
>
> Key: DROOLS-1729
> URL: https://issues.jboss.org/browse/DROOLS-1729
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Pedro Almeida
> Assignee: Mario Fusco
> Priority: Blocker
>
> I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
> Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted for.
> *Errors:*
> 1) "A Sliding Window can only be assigned to types declared with @role( event )
> [Actually my object type is declared with role event on the master drl]
> 2) "isTest cannot be resolved"
> [isTest being my global variable]
> *Rule:*
> package rules;
> import model.Car;
> global Boolean isTest;
> rule "Red Car"
> when
> Car (color=="Red") over window:time(2h);
> then
> System.out.println("*** Red car");
> System.out.println("*** " + isTest);
> end
> *Master Drl*
> package rules;
> import model.Car;
> global Boolean isTest;
> declare Car
> @role( event )
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1729) Unable to load rule with global variables via kiescanner.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1729?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1729:
-------------------------------------
I tried what you described with the test case that I'm pasting below, but everything works for me. Possibly try with a newer version of drools and if you can reproduce the problem also there, please provide a complete reproducer of your issue (possibly similar to my test case). I'll close this issue as "cannot reproduce" for now, but in case you'll be able to provide a reproducer feel free to reopen it.
{code}
@Test
public void testUpdateWithGlobalAndEventInSeparatedDRL() throws Exception {
String drl1 = "import " + FooEvent.class.getCanonicalName() + ";\n" +
"global Boolean isTest;\n" +
"declare FooEvent\n" +
" @timestamp( mytime )\n" +
" @role( event )\n" +
"end\n";
String drl2 = "global Boolean isTest;\n" +
"\n" +
"rule \"Red Car\"\n" +
"when\n" +
" FooEvent () over window:time(2h);\n" +
"then\n" +
" System.out.println(\"*** FooEvent\");\n" +
" System.out.println(\"*** \" + isTest);\n" +
"end\n";
String drl3 = "global Boolean isTest;\n" +
"\n" +
"rule \"Red Car\"\n" +
"when\n" +
" FooEvent () over window:time(3h);\n" +
"then\n" +
" System.out.println(\"$$$ FooEvent\");\n" +
" System.out.println(\"$$$ \" + isTest);\n" +
"end\n";
KieServices ks = KieServices.Factory.get();
KieModuleModel kproj = ks.newKieModuleModel();
KieBaseModel kieBaseModel1 = kproj.newKieBaseModel( "KBase1" ).setDefault( true )
.setEventProcessingMode( EventProcessingOption.STREAM );
KieSessionModel ksession1 = kieBaseModel1.newKieSessionModel( "KSession1" ).setDefault( true )
.setType( KieSessionModel.KieSessionType.STATEFUL )
.setClockType( ClockTypeOption.get( ClockType.PSEUDO_CLOCK.getId() ) );
// Create an in-memory jar for version 1.0.0
ReleaseId releaseId1 = ks.newReleaseId( "org.kie", "test-upgrade", "1.0.0" );
KieModule km = deployJar( ks, createKJar( ks, kproj, releaseId1, null, drl1, drl2 ) );
// Create a session and fire rules
KieContainer kc = ks.newKieContainer( km.getReleaseId() );
KieSession ksession = kc.newKieSession();
ksession.setGlobal( "isTest", true );
ksession.insert( new FooEvent( 0 ) );
assertEquals( 1, ksession.fireAllRules() );
// Create a new jar for version 1.1.0
ReleaseId releaseId2 = ks.newReleaseId( "org.kie", "test-upgrade", "1.1.0" );
km = deployJar( ks, createKJar( ks, kproj, releaseId2, null, drl1, drl3 ) );
// try to update the container to version 1.1.0
Results results = kc.updateToVersion( releaseId2 );
assertFalse("Errors detected on updateToVersion: " + results.getMessages(org.kie.api.builder.Message.Level.ERROR), results.hasMessages(org.kie.api.builder.Message.Level.ERROR));
// continue working with the session
ksession.insert( new FooEvent( 1 ) );
assertEquals( 2, ksession.fireAllRules() );
}
{code}
> Unable to load rule with global variables via kiescanner.
> ---------------------------------------------------------
>
> Key: DROOLS-1729
> URL: https://issues.jboss.org/browse/DROOLS-1729
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Pedro Almeida
> Assignee: Mario Fusco
> Priority: Blocker
>
> I have a master drl that has global *variables declaration* as well as *class role declarations*. Other drl files depend on those declarations.
> Build is successful and I'm able to use the engine as intended. The thing is when I use kiescanner to unload a rule and load it back, I get compilation errors that make it look like the master drl is not being accounted for.
> *Errors:*
> 1) "A Sliding Window can only be assigned to types declared with @role( event )
> [Actually my object type is declared with role event on the master drl]
> 2) "isTest cannot be resolved"
> [isTest being my global variable]
> *Rule:*
> package rules;
> import model.Car;
> global Boolean isTest;
> rule "Red Car"
> when
> Car (color=="Red") over window:time(2h);
> then
> System.out.println("*** Red car");
> System.out.println("*** " + isTest);
> end
> *Master Drl*
> package rules;
> import model.Car;
> global Boolean isTest;
> declare Car
> @role( event )
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9367) Parameters passed to standalone.sh are not printed on startup
by kobogian hitis (JIRA)
kobogian hitis created WFLY-9367:
------------------------------------
Summary: Parameters passed to standalone.sh are not printed on startup
Key: WFLY-9367
URL: https://issues.jboss.org/browse/WFLY-9367
Project: WildFly
Issue Type: Bug
Components: Scripts
Affects Versions: 10.1.0.Final
Environment: linux / windows
Reporter: kobogian hitis
Assignee: Tomaz Cerar
Priority: Minor
Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS).
Actually I think something like the output of `ps aux | grep "org.jboss.as.standalone"` should also be printed, when jboss starts.
Not printing them causes confusion between what is printed and what is actually applied.
If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100` and `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the latter will be printed but the first will be used.
Someone might argue about setting only JAVA_OPTS before running standalone.sh.
The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh, then the default Wildfly opts (-Djava.net.preferIPv4Stack=true" -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are never used, which causes other problems. This could be a bug byitself, but for now I consider it as expected behaviour.
So the most clean approach that I see for setting options in a single place (both with -D and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a wrapper script myapp-run.sh).
It should be possible however to be able to see them being printed somewhere.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9367) Parameters passed to standalone.sh are not printed on startup
by kobogian hitis (JIRA)
[ https://issues.jboss.org/browse/WFLY-9367?page=com.atlassian.jira.plugin.... ]
kobogian hitis updated WFLY-9367:
---------------------------------
Description:
Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS).
Actually I think something like the output of `ps aux | grep "org.jboss.as.standalone"` should also be printed, when jboss starts.
Not printing them causes confusion between what is printed and what is actually applied.
If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100` and at the same time `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the latter will be printed but the first will be used.
Someone might argue about setting only JAVA_OPTS before running standalone.sh.
The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh, then the default Wildfly opts (-Djava.net.preferIPv4Stack=true" -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are never used, which causes other problems. This could be a bug byitself, but for now I consider it as expected behaviour.
So the most clean approach that I see for setting options in a single place (both with -D and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a wrapper script myapp-run.sh).
It should be possible however to be able to see them being printed somewhere.
was:
Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS).
Actually I think something like the output of `ps aux | grep "org.jboss.as.standalone"` should also be printed, when jboss starts.
Not printing them causes confusion between what is printed and what is actually applied.
If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100` and `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the latter will be printed but the first will be used.
Someone might argue about setting only JAVA_OPTS before running standalone.sh.
The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh, then the default Wildfly opts (-Djava.net.preferIPv4Stack=true" -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are never used, which causes other problems. This could be a bug byitself, but for now I consider it as expected behaviour.
So the most clean approach that I see for setting options in a single place (both with -D and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a wrapper script myapp-run.sh).
It should be possible however to be able to see them being printed somewhere.
> Parameters passed to standalone.sh are not printed on startup
> -------------------------------------------------------------
>
> Key: WFLY-9367
> URL: https://issues.jboss.org/browse/WFLY-9367
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.1.0.Final
> Environment: linux / windows
> Reporter: kobogian hitis
> Assignee: Tomaz Cerar
> Priority: Minor
>
> Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS).
> Actually I think something like the output of `ps aux | grep "org.jboss.as.standalone"` should also be printed, when jboss starts.
> Not printing them causes confusion between what is printed and what is actually applied.
> If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100` and at the same time `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the latter will be printed but the first will be used.
> Someone might argue about setting only JAVA_OPTS before running standalone.sh.
> The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh, then the default Wildfly opts (-Djava.net.preferIPv4Stack=true" -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are never used, which causes other problems. This could be a bug byitself, but for now I consider it as expected behaviour.
> So the most clean approach that I see for setting options in a single place (both with -D and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a wrapper script myapp-run.sh).
> It should be possible however to be able to see them being printed somewhere.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months