[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2456:
----------------------------------------
Going to keep this open for now, will review if we have an Java 7 options to detect if this is a missing file or a permissions issue and log a more appropriate error if we can.
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2456
> URL: https://issues.jboss.org/browse/WFLY-2456
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Environment: Windows 7, 32-bit, jdk1.7.0_45
> Reporter: John Lusk
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-130) Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-130?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on WFLY-130:
---------------------------------------
For those of you using cygwin you are more than welcome to submit a pull request to the git repo with the script modified.
Realistically getting to a Windows VM with cygwin to test this further is not something I am likely to have time to do in the short term with the other tasks we need to get completed for WildFly 8 so as I say - contributions more than welcome, especially as you guys already have the environments to reproduce the failure ;-)
> Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-130
> URL: https://issues.jboss.org/browse/WFLY-130
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
> Reporter: Bernard Giroud
> Assignee: Darran Lofthouse
> Labels: as7, management
> Fix For: 9.0.0.CR1
>
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
> cygwin = true;
> {code}
> It should read:
> {code}
> cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-2456:
--------------------------------------
Assignee: Darran Lofthouse (was: Thomas Diesler)
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2456
> URL: https://issues.jboss.org/browse/WFLY-2456
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ConfigAdmin
> Affects Versions: 8.0.0.Beta1
> Environment: Windows 7, 32-bit, jdk1.7.0_45
> Reporter: John Lusk
> Assignee: Darran Lofthouse
>
> Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2456:
-----------------------------------
Component/s: Scripts
(was: ConfigAdmin)
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2456
> URL: https://issues.jboss.org/browse/WFLY-2456
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Environment: Windows 7, 32-bit, jdk1.7.0_45
> Reporter: John Lusk
> Assignee: Darran Lofthouse
>
> Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2456:
-----------------------------------
Fix Version/s: 8.0.0.CR1
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2456
> URL: https://issues.jboss.org/browse/WFLY-2456
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Environment: Windows 7, 32-bit, jdk1.7.0_45
> Reporter: John Lusk
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (DROOLS-324) Conditional named consequences don't allow MVEL expressions in the condition of an if statement
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/DROOLS-324?page=com.atlassian.jira.plugin... ]
Duncan Doyle commented on DROOLS-324:
-------------------------------------
Yes, my mistake. I wrongly assumed the default dialect is MVEL. It works in my test as well when I explicitly set the dialect to MVEL.
> Conditional named consequences don't allow MVEL expressions in the condition of an if statement
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-324
> URL: https://issues.jboss.org/browse/DROOLS-324
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Labels: conditional, consequences, drools, mvel, named
>
> See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
> As you can see in the 'src/main/resources/rules/Sample.drl', the first rule, which is commented out, uses an MVEL expression in the conditional 'if' statement, i.e. "if (m.status == Message.HELLO) break [sayHello]". The compiler throws this error:
> Rule Compilation error The field DroolsTest.Message.status is not visible.
> When I use a Java dialect and define the conditional if as " if (m.getStatus() == 0) break [sayHello]", as shown in the second rule everything works fine.
> Note that there is also an issue with using public constants in the condition, but I'll open another JIRA for that issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2427) Launcher API
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on WFLY-2427:
-------------------------------------------
btw. at little more background:
We don't call the OS specific script for one primary reason:
There is no portable way of calling these scripts AND have control over the Java process (i.e. we need to be able to kill it in case the user already have a running server on the same port. JBoss will start up saying it cannot use the port but will not exit - and any attempt to kill it via management would kill the other running server.)
The main problem not using the scripts are that user customized fields/properties are *not* honored.
Things like memory settings edit in run.conf or run.conf.bat wont be understood by the tooling.
We would optimally prefer we could simply do this:
java -jar jboss-modules.jar -properties run.properties
And then whatever settings there are in run.properties gets applied/honored.
That can work for majority of the jboss properties, but for vm flags like memory settings and properties that could be relevant before jboss-modules kicks in (i.e. -Djava.net.preferIPv4Stack=true) would be necessary to read some otherway and done by the servers script files.
> Launcher API
> ------------
>
> Key: WFLY-2427
> URL: https://issues.jboss.org/browse/WFLY-2427
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now.
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope.
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2427) Launcher API
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on WFLY-2427:
-------------------------------------------
If this library should be useful from tools perspective it should *not* be tied to a specifc version of the server since we need to launch many different versions of various jboss servers.
This kind of client launcher library would also be interesting for [~aslak] in the Arquillian project.
> Launcher API
> ------------
>
> Key: WFLY-2427
> URL: https://issues.jboss.org/browse/WFLY-2427
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now.
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope.
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (DROOLS-324) Conditional named consequences don't allow MVEL expressions in the condition of an if statement
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-324?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-324.
--------------------------------
Resolution: Cannot Reproduce Bug
I added this test case demonstrating that is working as expected
https://github.com/droolsjbpm/drools/commit/4934b87c4#diff-b48e3d5a1a0d2b...
Note that the default dialect is java, not mvel.
Also note that in the condition the last pattern is the implicit 'this', so in your case it is not necessary to explicitly referring to it. In other words:
if (status == 0)
works with both mvel and java dialect.
> Conditional named consequences don't allow MVEL expressions in the condition of an if statement
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-324
> URL: https://issues.jboss.org/browse/DROOLS-324
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Labels: conditional, consequences, drools, mvel, named
>
> See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
> As you can see in the 'src/main/resources/rules/Sample.drl', the first rule, which is commented out, uses an MVEL expression in the conditional 'if' statement, i.e. "if (m.status == Message.HELLO) break [sayHello]". The compiler throws this error:
> Rule Compilation error The field DroolsTest.Message.status is not visible.
> When I use a Java dialect and define the conditional if as " if (m.getStatus() == 0) break [sayHello]", as shown in the second rule everything works fine.
> Note that there is also an issue with using public constants in the condition, but I'll open another JIRA for that issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months