[JBoss JIRA] (DROOLS-325) Conditional named consequences don't allow references to public fields
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-325?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-325.
--------------------------------
Resolution: Cannot Reproduce Bug
I added this test case demonstrating that it is working as expected
https://github.com/droolsjbpm/drools/commit/4934b87c4#diff-b48e3d5a1a0d2b...
> Conditional named consequences don't allow references to public fields
> ----------------------------------------------------------------------
>
> Key: DROOLS-325
> URL: https://issues.jboss.org/browse/DROOLS-325
> 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, Oracle Hotspot 1.7.0_45
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Labels: conditional, consequences, 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, references the public fields Message.HELLO and Message.GOODBYE in the conditional 'if' statement, i.e. "if (m.status == Message.HELLO) break [sayHello]". The compiler throws this error:
> Rule Compilation error HELLO cannot be resolved or is not a field.
> When I use the actual value of Message.HELLO and Message.GOODBYE, as shown in the second rule 'if (m.getStatus() == 0) break [sayHello]', everything works fine.
> Please note that there is also an issue with using MVEL expressions in Conditional named consequences (as you can see in my example rules). That issue is tracked in JIRA DROOLS-324.
--
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 reassigned DROOLS-324:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> 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] (DROOLS-325) Conditional named consequences don't allow references to public fields
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-325?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-325:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Conditional named consequences don't allow references to public fields
> ----------------------------------------------------------------------
>
> Key: DROOLS-325
> URL: https://issues.jboss.org/browse/DROOLS-325
> 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, Oracle Hotspot 1.7.0_45
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Labels: conditional, consequences, 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, references the public fields Message.HELLO and Message.GOODBYE in the conditional 'if' statement, i.e. "if (m.status == Message.HELLO) break [sayHello]". The compiler throws this error:
> Rule Compilation error HELLO cannot be resolved or is not a field.
> When I use the actual value of Message.HELLO and Message.GOODBYE, as shown in the second rule 'if (m.getStatus() == 0) break [sayHello]', everything works fine.
> Please note that there is also an issue with using MVEL expressions in Conditional named consequences (as you can see in my example rules). That issue is tracked in JIRA DROOLS-324.
--
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-1145) missing beans.xml in archive using javax.inject shouldn't *silently* ignore injection sites
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-1145?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger resolved WFLY-1145.
-----------------------------------
Resolution: Out of Date
This was already implemented in WildFly.
> missing beans.xml in archive using javax.inject shouldn't *silently* ignore injection sites
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-1145
> URL: https://issues.jboss.org/browse/WFLY-1145
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Environment: N/A, any Java EE 6
> Reporter: Craig Ringer
> Priority: Minor
> Labels: cdi, injection, injectionpoint, usability
>
> It's common, especially for new users of Java EE and CDI, for confusion to arise because of a missing or misplaced beans.xml file. Injection sites that should be injected are null, interceptors don't run, etc. People experienced with CDI immediately spot what's wrong, but if you haven't worked with EE much it can throw you quite badly.
> It's particularly problematic when beans.xml exists, but isn't where the server expects it to be. This can happen when a jar-layout archive is deployed as a .war or vice versa (something newbies can and will do), or when beans.xml is placed in META-INF/ for a war archive where it's supposed to be in WEB-INF/ .
> It would be very helpful if it were possible to efficiently detect an archive that uses javax.inject.* annotations without a beans.xml file and issue a warning. To enhance the usability of CDI and its accessibility to new developers, IMO the spec should encourage this.
> A deployment error when javax.inject.Inject etc are used without a beans.xml file isn't appropriate, as there may be non-CDI code using those annotations, but a warning would make a big difference to usability.
> It's possible this is better done in an application-server specific context rather than as anything to do with the CDI specification, since the AS is scanning the archive during deployment anyway. If that's the case, it's probably best to move this issue to the JBoss AS 7 JIRA.
> If it's possible for a CDI impl to *efficiently* detect javax.inject.* and warn, though, it'd be a good thing to encourage in the spec.
--
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-2457) HttpUpgradeHandlerInjectionSupportTestCase fails on Windows
by Jozef Hartinger (JIRA)
Jozef Hartinger created WFLY-2457:
-------------------------------------
Summary: HttpUpgradeHandlerInjectionSupportTestCase fails on Windows
Key: WFLY-2457
URL: https://issues.jboss.org/browse/WFLY-2457
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Reporter: Jozef Hartinger
Assignee: Jozef Hartinger
{quote}
This test fails on windows and I am not 100% sure why. I think it would be something to do with the different line endings, although I can't see why this would affect it
{quote}
--
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-2278) Deployer can't modify data source when datasources set as application resources
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]
I can confirm that the workaround with xa-data-source works. I filed bug 1027586 for tracking and I'm moving this to verified again. The main issue is indeed solved.
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
> Key: WFLY-2278
> URL: https://issues.jboss.org/browse/WFLY-2278
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.
--
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-2278) Deployer can't modify data source when datasources set as application resources
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786] from ON_QA to VERIFIED
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
> Key: WFLY-2278
> URL: https://issues.jboss.org/browse/WFLY-2278
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.
--
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 John Lusk (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
John Lusk commented on WFLY-2456:
---------------------------------
Oy.
Ok, user error.
c:\usr\local isn't accessible to mere mortal users on my machine, you have to be admin (I have kids that use this machine).
My DOS cmd window wasn't running as admin. (Yay, good habits.)
When I ran it as admin, I had no problems.
> 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: Thomas Diesler
>
> 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 John Lusk (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
John Lusk updated WFLY-2456:
----------------------------
Environment: Windows 7, 32-bit, jdk1.7.0_45 (was: Windows 7, 32-bit, cygwin, jdk1.7.0_45)
> 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: Thomas Diesler
>
> 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