[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-3778:
---------------------------------------
I do not see these problems anymore for a quite long time now.
Feel free to close this issue.
> Tests in Manualmode test suite fail occasionally
> ------------------------------------------------
>
> Key: WFLY-3778
> URL: https://issues.jboss.org/browse/WFLY-3778
> Project: WildFly
> Issue Type: Bug
> Components: Remoting, Test Suite
> Affects Versions: 9.0.0.Alpha1
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
>
>
> I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
> But I saw a very similar failure today on Linux first time for PR 6638.
> See https://github.com/wildfly/wildfly/pull/6638.
> Last failure on my machine:
> {noformat}
> Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
> java.lang.AssertionError: Password should be right and authentication successful
> Expected: a string containing "\"outcome\" => \"success\""
> but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
> INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
> INFO [org.xnio] XNIO version 3.3.0.Beta1
> INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
> INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
> "
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBAS-8481) Avoid warning about missing AIO when not on Linux
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/JBAS-8481?page=com.atlassian.jira.plugin.... ]
Frank Langelage closed JBAS-8481.
---------------------------------
Fix Version/s: (was: No Release)
Resolution: Out of Date
This message was changed a couple of month ago in 9.x or 10.x.
Currently I get:
{code:java}
26.11. 11:12:45,535 INFO [org.wildfly.extension.messaging-activemq#start] WFLYMSGAMQ0001: AIO wasn't located on this platform, it will fall back to using pure Java NIO.
{code}
which is fine for me.
> Avoid warning about missing AIO when not on Linux
> -------------------------------------------------
>
> Key: JBAS-8481
> URL: https://issues.jboss.org/browse/JBAS-8481
> Project: Application Server 3 4 5 and 6
> Issue Type: Feature Request
> Components: JMS (HornetQ)
> Affects Versions: 6.0.0.M5
> Environment: JBoss svn checkout on Solaris 10 using Sun JDK 1.6.0_21.
> Reporter: Frank Langelage
>
> On startup of JBossAS-6.0.0-SNAPSHOT I get two times this warning:
> 22:00:07,984 WARNING [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
> ...
> 22:01:02,245 WARNING [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
> By evaluating the property os.name JBoss should find out if it's a Linux system or not and raise this warning only if it's a Linux system.
> In my case the property os.name is SunOS so this warnings are not relevant in my understanding.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-1791) Unable to use Filter Expressions in filter-spec
by Miguel Moquillon (JIRA)
[ https://issues.jboss.org/browse/WFLY-1791?page=com.atlassian.jira.plugin.... ]
Miguel Moquillon commented on WFLY-1791:
----------------------------------------
Hum ... I'm sorry but in Wildfly-9.0.2 this doesn't work when using levelRange expression, whatever the coma is or not escaped:
write-attribute(name=filter-spec, value=levelRange["ERROR"\, "DEBUG"])
The error that is displayed:
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0097: Wrong type for filter-spec. Expected [EXPRESSION, STRING] but was LIST"}}
> Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
> Key: WFLY-1791
> URL: https://issues.jboss.org/browse/WFLY-1791
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Reporter: ehsavoie Hugonnet
> Assignee: Alexey Loubyansky
> Priority: Minor
> Fix For: 8.0.0.Beta1
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-4065) Warning about private module use issued twice
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-4065?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-4065:
---------------------------------------
Still the same with WildFly Full 10.0.0.CR5-SNAPSHOT (WildFly Core 2.0.3.Final):
{code:java}
26.11. 11:13:33,880 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.hsk2e-langfr-sb2000-ipc.ear.ejb-session-common.jar" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
26.11. 11:13:33,883 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.hsk2e-langfr-sb2000-ipc.ear.ejb-session-common.jar" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
{code}
> Warning about private module use issued twice
> ---------------------------------------------
>
> Key: WFLY-4065
> URL: https://issues.jboss.org/browse/WFLY-4065
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR5
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Priority: Minor
>
> My web app is using some modules of WildFly AS which are not public.
> The warning about using private modules is issued twice for every module:
> 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-4065) Warning about private module use issued twice
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-4065?page=com.atlassian.jira.plugin.... ]
Frank Langelage updated WFLY-4065:
----------------------------------
Affects Version/s: 10.0.0.CR5
(was: 9.0.0.Beta1)
> Warning about private module use issued twice
> ---------------------------------------------
>
> Key: WFLY-4065
> URL: https://issues.jboss.org/browse/WFLY-4065
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR5
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Priority: Minor
>
> My web app is using some modules of WildFly AS which are not public.
> The warning about using private modules is issued twice for every module:
> 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBMETA-391) web-app_x_y.xsd is missing in metadata common schema folder
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/JBMETA-391?page=com.atlassian.jira.plugin... ]
Jim Ma commented on JBMETA-391:
-------------------------------
It looks only the schema files packaged in Metadata can be loaded locally. xsd files under wildfly-10.0.0.CR5-SNAPSHOT/docs/schema can not be reached by org.jboss.metadata.parser.util.XMLSchemaValidator.
> web-app_x_y.xsd is missing in metadata common schema folder
> -----------------------------------------------------------
>
> Key: JBMETA-391
> URL: https://issues.jboss.org/browse/JBMETA-391
> Project: JBoss Metadata
> Issue Type: Task
> Components: common
> Affects Versions: 10.0.0.Beta1
> Reporter: Jim Ma
>
> What's the criteria for putting xsd files under schema folder ? I saw the web-app_x_y.xsd files are all missing in common schema folder. This leads web-app xsd is downloaded for each web deployment when system property "org.jboss.metadata.parser.validate" is set to true.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-991) File KnowledgeRuntimeLogger does not produce file until close() operation is closed
by Anton Giertli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-991?page=com.atlassian.jira.plugin... ]
Anton Giertli updated DROOLS-991:
---------------------------------
Priority: Minor (was: Major)
> File KnowledgeRuntimeLogger does not produce file until close() operation is closed
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-991
> URL: https://issues.jboss.org/browse/DROOLS-991
> Project: Drools
> Issue Type: Enhancement
> Reporter: Anton Giertli
> Assignee: Mario Fusco
> Priority: Minor
>
> When you use file logger, like this:
> KieServices.Factory.get().getLoggers().newFileLogger(session, fileName)
> The actual file does not get created until you call close() method.
> While this may be beneficial in many use cases(probably the reasoning behind this is performance aspect), when debugging a rule execution, where rule are getting stuck - i.e. the whole JVM becomes unresponsive, then the actual log file will never be created.
> Therefore, it would be nice to have this configurable, i.e.
> 1) Create log file when the close() method is called - better performance - this could be the default behavior.
> 2) Create log file immediately, and update it whenever there is something new to be logged - worse performance, but there will be some log available even if the rule execution will get stuck - this could be the configurable behavior
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-991) File KnowledgeRuntimeLogger does not produce file until close() operation is closed
by Anton Giertli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-991?page=com.atlassian.jira.plugin... ]
Anton Giertli reassigned DROOLS-991:
------------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> File KnowledgeRuntimeLogger does not produce file until close() operation is closed
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-991
> URL: https://issues.jboss.org/browse/DROOLS-991
> Project: Drools
> Issue Type: Enhancement
> Reporter: Anton Giertli
> Assignee: Mario Fusco
>
> When you use file logger, like this:
> KieServices.Factory.get().getLoggers().newFileLogger(session, fileName)
> The actual file does not get created until you call close() method.
> While this may be beneficial in many use cases(probably the reasoning behind this is performance aspect), when debugging a rule execution, where rule are getting stuck - i.e. the whole JVM becomes unresponsive, then the actual log file will never be created.
> Therefore, it would be nice to have this configurable, i.e.
> 1) Create log file when the close() method is called - better performance
> 2) Create log file immediately, and update it whenever there is something new to be logged - worse performance, but there will be some log available even if the rule execution will get stuck
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-991) File KnowledgeRuntimeLogger does not produce file until close() operation is closed
by Anton Giertli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-991?page=com.atlassian.jira.plugin... ]
Anton Giertli updated DROOLS-991:
---------------------------------
Description:
When you use file logger, like this:
KieServices.Factory.get().getLoggers().newFileLogger(session, fileName)
The actual file does not get created until you call close() method.
While this may be beneficial in many use cases(probably the reasoning behind this is performance aspect), when debugging a rule execution, where rule are getting stuck - i.e. the whole JVM becomes unresponsive, then the actual log file will never be created.
Therefore, it would be nice to have this configurable, i.e.
1) Create log file when the close() method is called - better performance - this could be the default behavior.
2) Create log file immediately, and update it whenever there is something new to be logged - worse performance, but there will be some log available even if the rule execution will get stuck - this could be the configurable behavior
was:
When you use file logger, like this:
KieServices.Factory.get().getLoggers().newFileLogger(session, fileName)
The actual file does not get created until you call close() method.
While this may be beneficial in many use cases(probably the reasoning behind this is performance aspect), when debugging a rule execution, where rule are getting stuck - i.e. the whole JVM becomes unresponsive, then the actual log file will never be created.
Therefore, it would be nice to have this configurable, i.e.
1) Create log file when the close() method is called - better performance
2) Create log file immediately, and update it whenever there is something new to be logged - worse performance, but there will be some log available even if the rule execution will get stuck
> File KnowledgeRuntimeLogger does not produce file until close() operation is closed
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-991
> URL: https://issues.jboss.org/browse/DROOLS-991
> Project: Drools
> Issue Type: Enhancement
> Reporter: Anton Giertli
> Assignee: Mario Fusco
>
> When you use file logger, like this:
> KieServices.Factory.get().getLoggers().newFileLogger(session, fileName)
> The actual file does not get created until you call close() method.
> While this may be beneficial in many use cases(probably the reasoning behind this is performance aspect), when debugging a rule execution, where rule are getting stuck - i.e. the whole JVM becomes unresponsive, then the actual log file will never be created.
> Therefore, it would be nice to have this configurable, i.e.
> 1) Create log file when the close() method is called - better performance - this could be the default behavior.
> 2) Create log file immediately, and update it whenever there is something new to be logged - worse performance, but there will be some log available even if the rule execution will get stuck - this could be the configurable behavior
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months