April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-761) Guided decision trees - new test for testing of unmarshalling drls containing different line separators

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-761?page=com.atlassian.jira.plugin... ] Michael Anstis resolved DROOLS-761. ----------------------------------- Fix Version/s: 6.3.0.Beta1 Resolution: Done Pull Request merged. Thanks. > Guided decision trees - new test for testing of unmarshalling drls containing different line separators > ------------------------------------------------------------------------------------------------------- > > Key: DROOLS-761 > URL: https://issues.jboss.org/browse/DROOLS-761 > Project: Drools > Issue Type: Enhancement > Reporter: Tibor Zimányi > Assignee: Michael Anstis > Priority: Minor > Fix For: 6.3.0.Beta1 > > > Drls can be written on different operating systems so they can contain different line endings. There is a need for test that will test unmarshalling DRLs with different line endings into GuidedDecisionTree models. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-761) Guided decision trees - new test for testing of unmarshalling drls containing different line separators

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-761?page=com.atlassian.jira.plugin... ] Tibor Zimányi updated DROOLS-761: --------------------------------- Summary: Guided decision trees - new test for testing of unmarshalling drls containing different line separators (was: Guided decision trees - new test for testing of unmarshalling drls containing different line endings) > Guided decision trees - new test for testing of unmarshalling drls containing different line separators > ------------------------------------------------------------------------------------------------------- > > Key: DROOLS-761 > URL: https://issues.jboss.org/browse/DROOLS-761 > Project: Drools > Issue Type: Enhancement > Reporter: Tibor Zimányi > Assignee: Michael Anstis > Priority: Minor > > Drls can be written on different operating systems so they can contain different line endings. There is a need for test that will test unmarshalling DRLs with different line endings into GuidedDecisionTree models. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-640) Bad permissions on properties files when using add-user.bat for results in "JBAS015234: No mgmt-groups.properties files found"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-640?page=com.atlassian.jira.plugin... ] Darran Lofthouse moved WFLY-2456 to WFCORE-640: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-640 (was: WFLY-2456) Affects Version/s: (was: 8.0.0.Beta1) Component/s: Scripts (was: Scripts) Fix Version/s: (was: Awaiting Volunteers) > Bad permissions on properties files when using add-user.bat for results in "JBAS015234: No mgmt-groups.properties files found" > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-640 > URL: https://issues.jboss.org/browse/WFCORE-640 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Environment: Windows 7, 32-bit, jdk1.7.0_45 > Reporter: John Lusk > > 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 was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4500) CMResourceService#stop fails to clean up

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-4500?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-4500: ------------------------------------- Change looks good to me from the transaction managers perspective - thanks Philippe!! > CMResourceService#stop fails to clean up > ---------------------------------------- > > Key: WFLY-4500 > URL: https://issues.jboss.org/browse/WFLY-4500 > Project: WildFly > Issue Type: Patch > Components: Transactions > Reporter: Philippe Marschall > Assignee: Philippe Marschall > > CMResourceService#stop fails to clean up values that #start creates. > The issue is the line > {code} > jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(immediateCleanup); > {code} > immediateCleanup is a {{Boolean}} and the return type of {{getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap()}} is {{Map<String, Boolean>}} > So this line never does anything. The line should read > {code} > jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(jndiName); > {code} > because if we look a the #start method above we see > {code} > Map<String, Boolean> performImmediateCleanupOfConnectableResourceBranchesMap = jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap(); > performImmediateCleanupOfConnectableResourceBranchesMap.put(jndiName, immediateCleanup); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4500) CMResourceService#stop fails to clean up

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-4500?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned WFLY-4500: ----------------------------------- Assignee: Philippe Marschall (was: Tom Jenkinson) > CMResourceService#stop fails to clean up > ---------------------------------------- > > Key: WFLY-4500 > URL: https://issues.jboss.org/browse/WFLY-4500 > Project: WildFly > Issue Type: Patch > Components: Transactions > Reporter: Philippe Marschall > Assignee: Philippe Marschall > > CMResourceService#stop fails to clean up values that #start creates. > The issue is the line > {code} > jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(immediateCleanup); > {code} > immediateCleanup is a {{Boolean}} and the return type of {{getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap()}} is {{Map<String, Boolean>}} > So this line never does anything. The line should read > {code} > jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap().remove(jndiName); > {code} > because if we look a the #start method above we see > {code} > Map<String, Boolean> performImmediateCleanupOfConnectableResourceBranchesMap = jtaEnvironmentBean.getValue().getPerformImmediateCleanupOfCommitMarkableResourceBranchesMap(); > performImmediateCleanupOfConnectableResourceBranchesMap.put(jndiName, immediateCleanup); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4508) :read-resource(recursive, include-runtime) on undertow subsystem fails

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-4508?page=com.atlassian.jira.plugin.... ] Heiko Braun edited comment on WFLY-4508 at 4/13/15 7:21 AM: ------------------------------------------------------------ No, that's just been development misconfigurations. I get the same errors on a clean install. was (Author: heiko.braun): No, that's just development misconfigurations. I get the same errors on a clean install. > :read-resource(recursive,include-runtime) on undertow subsystem fails > --------------------------------------------------------------------- > > Key: WFLY-4508 > URL: https://issues.jboss.org/browse/WFLY-4508 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Web (Undertow) > Reporter: Heiko Braun > Assignee: Tomaz Cerar > Priority: Critical > Fix For: 9.0.0.CR1 > > > {code} > 08:28:21,470 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Beta1) started (with errors) in 3771ms - Started 201 of 381 services (1 services failed or missing dependencies, 210 services are lazy, passive or on-demand) > 08:28:50,778 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("read-attribute") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("https-listener" => "https") > ]): java.lang.NullPointerException > at org.wildfly.extension.undertow.ListenerResourceDefinition$ReadStatisticHandler.execute(ListenerResourceDefinition.java:224) > at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:212) > at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:141) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:220) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:487) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:795) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:201) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:128) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4508) :read-resource(recursive, include-runtime) on undertow subsystem fails

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-4508?page=com.atlassian.jira.plugin.... ] Heiko Braun commented on WFLY-4508: ----------------------------------- No, that's just development misconfigurations. I get the same errors on a clean install. > :read-resource(recursive,include-runtime) on undertow subsystem fails > --------------------------------------------------------------------- > > Key: WFLY-4508 > URL: https://issues.jboss.org/browse/WFLY-4508 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Web (Undertow) > Reporter: Heiko Braun > Assignee: Tomaz Cerar > Priority: Critical > Fix For: 9.0.0.CR1 > > > {code} > 08:28:21,470 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Beta1) started (with errors) in 3771ms - Started 201 of 381 services (1 services failed or missing dependencies, 210 services are lazy, passive or on-demand) > 08:28:50,778 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("read-attribute") failed - address: ([ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("https-listener" => "https") > ]): java.lang.NullPointerException > at org.wildfly.extension.undertow.ListenerResourceDefinition$ReadStatisticHandler.execute(ListenerResourceDefinition.java:224) > at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:212) > at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:141) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:220) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:487) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:795) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:201) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:128) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-722) SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-722?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-722: -------------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1085501|https://bugzilla.redhat.com/show_bug.cgi?id=1085501] from ON_QA to VERIFIED > SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available > ------------------------------------------------------------------------------------------------- > > Key: SECURITY-722 > URL: https://issues.jboss.org/browse/SECURITY-722 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_2_2_1 > Environment: RHEL6, JBoss EAP 6 > Reporter: flame liu > Assignee: Derek Horton > Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2 > > > I configured SPNEGO in EAP6. It works well both with EAP only and EAP6 + Apache httpd(mod_proxy). Users just run kinit and will be able to be successfully authenticated. > After that, I added the fallback-to-form files/configurations both in the web app and standalone-full.xml. The fallback-to-form works only if httpd stops. If httpd starts, 401 error will always be thrown out. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2456) Bad permissions on properties files when using add-user.bat for 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: ---------------------------------------- [~rgaisford] Sounds good and you are very welcome to take a look. As I mention above it could be tricky as permissions can make a file or folder appear missing even though there but not accessible but certainly open to someone exploring the possibilities. I am going to move this Jira issue to the WFCORE project in Jira as that is technically where the code lives: - https://github.com/wildfly/wildfly-core The code for the add user utility is under domain management and the entry point is a class called 'org.jboss.as.domain.management.security.adduser.AddUser', if you have not already seen it the following page should give you some starting points to get building a server https://developer.jboss.org/wiki/HackingOnWildFly (Although do note it is WildFly Core you need to be working on not WildFly) One final point I would only recommend working on this if you plan to work on it soon, that way it can reach WildFly 9 - for WildFly 10 there is going to be a lot of rework in this area possibly making a lot of this utility redundant. > Bad permissions on properties files when using add-user.bat for 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 > Components: Scripts > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7, 32-bit, jdk1.7.0_45 > Reporter: John Lusk > Fix For: Awaiting Volunteers > > > 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 was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-748) MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1).

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-748?page=com.atlassian.jira.plugin... ] Tibor Zimányi reopened DROOLS-748: ---------------------------------- > MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1). > ------------------------------------------------------------------------- > > Key: DROOLS-748 > URL: https://issues.jboss.org/browse/DROOLS-748 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Minor > > In MultithreadTest classes (there are two of them) method testSlidingTimeWindows() uses unreliable Thread.sleep(1) call for waiting for fact insertion. Thread.sleep(1) doesn't wait for exactly 1 millisecond, because there is overhead from thread scheduler. This overhead can be pretty large in contrast to expected 1ms sleep. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015