[JBoss JIRA] (WFCORE-4158) RootSubsystemOperationsTestCase periodically fails on Windows
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4158?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-4158:
---------------------------------------
I can't seem to duplicate this locally. However I noticed the test {{KernelServices}} has a {{shutdown()}} method which is never being invoked in the logging tests. This could be the issue if this would close the handlers.
There may be a need for a special shutdown hook, not a {{Runtime.addShutdownHook()}}, that would clean up the {{LogContextConfiguration}} closing the handlers which should free the file lock.
> RootSubsystemOperationsTestCase periodically fails on Windows
> -------------------------------------------------------------
>
> Key: WFCORE-4158
> URL: https://issues.jboss.org/browse/WFCORE-4158
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> The {{RootSubsystemOperationsTestCase}} periodically fails on Windows. The failure occurs in a {{@BeforeClass}} setup which attempts to clear the log directory. A file appears to still be locked by something from a previous test, likely the {{LoggingSubsystemTestCase}}. The failures seem to be consistent with the {{another.log}} being locked.
> {code}
> [00:47:20][Step 3/5] [INFO] Running org.jboss.as.logging.LoggingSubsystemTestCase
> [00:47:34][Step 3/5] [INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.059 s - in org.jboss.as.logging.LoggingSubsystemTestCase
> [00:47:34][Step 3/5] [INFO] Running org.jboss.as.logging.logmanager.Log4jAppenderTestCase
> [00:47:34][Step 3/5] [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in org.jboss.as.logging.logmanager.Log4jAppenderTestCase
> [00:47:34][Step 3/5] [INFO] Running org.jboss.as.logging.RootSubsystemOperationsTestCase
> [00:47:34][Step 3/5] [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.001 s <<< FAILURE! - in org.jboss.as.logging.RootSubsystemOperationsTestCase
> [00:47:34][Step 3/5] [ERROR] org.jboss.as.logging.RootSubsystemOperationsTestCase Time elapsed: 0.001 s <<< ERROR!
> [00:47:34][Step 3/5] java.nio.file.FileSystemException:
> [00:47:34][Step 3/5] C:\buildAgent\work\e9bccef30f12678d\logging\target\logs\another.log: The process cannot access the file because it is being used by another process.
> [00:47:34][Step 3/5]
> [00:47:34][Step 3/5] at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> [00:47:34][Step 3/5] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> [00:47:34][Step 3/5] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> [00:47:34][Step 3/5] at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> [00:47:34][Step 3/5] at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> [00:47:34][Step 3/5] at java.nio.file.Files.delete(Files.java:1126)
> [00:47:34][Step 3/5] at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:502)
> [00:47:34][Step 3/5] at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:499)
> [00:47:34][Step 3/5] at java.nio.file.Files.walkFileTree(Files.java:2670)
> [00:47:34][Step 3/5] at java.nio.file.Files.walkFileTree(Files.java:2742)
> [00:47:34][Step 3/5] at org.jboss.as.logging.AbstractLoggingSubsystemTest.clearDirectory(AbstractLoggingSubsystemTest.java:499)
> [00:47:34][Step 3/5] at org.jboss.as.logging.AbstractOperationsTestCase.setupLoggingDir(AbstractOperationsTestCase.java:53)
> [00:47:34][Step 3/5] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [00:47:34][Step 3/5] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [00:47:34][Step 3/5] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [00:47:34][Step 3/5] at java.lang.reflect.Method.invoke(Method.java:498)
> [00:47:34][Step 3/5] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> [00:47:34][Step 3/5] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> [00:47:34][Step 3/5] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> [00:47:34][Step 3/5] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> [00:47:34][Step 3/5] at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> [00:47:34][Step 3/5] at org.junit.runners.Suite.runChild(Suite.java:128)
> [00:47:34][Step 3/5] at org.junit.runners.Suite.runChild(Suite.java:27)
> [00:47:34][Step 3/5] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> [00:47:34][Step 3/5] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> [00:47:34][Step 3/5] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> [00:47:34][Step 3/5] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> [00:47:34][Step 3/5] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> [00:47:34][Step 3/5] at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> [00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> [00:47:34][Step 3/5]
> [00:47:34][Step 3/5] [INFO] Running org.jboss.as.logging.validators.SuffixValidatorTestCase
> [00:47:34][Step 3/5] [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in org.jboss.as.logging.validators.SuffixValidatorTestCase
> [00:47:34][Step 3/5] org.jboss.as.logging.RootSubsystemOperationsTestCase
> [00:47:34][org.jboss.as.logging.RootSubsystemOperationsTestCase] RootSubsystemOperationsTestCase
> [00:47:34][RootSubsystemOperationsTestCase] java.nio.file.FileSystemException: C:\buildAgent\work\e9bccef30f12678d\logging\target\logs\another.log: The process cannot access the file because it is being used by another process.
> [00:47:34][RootSubsystemOperationsTestCase] java.nio.file.FileSystemException:
> C:\buildAgent\work\e9bccef30f12678d\logging\target\logs\another.log: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:502)
> at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:499)
> at java.nio.file.Files.walkFileTree(Files.java:2670)
> at java.nio.file.Files.walkFileTree(Files.java:2742)
> at org.jboss.as.logging.AbstractLoggingSubsystemTest.clearDirectory(AbstractLoggingSubsystemTest.java:499)
> at org.jboss.as.logging.AbstractOperationsTestCase.setupLoggingDir(AbstractOperationsTestCase.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> [00:47:08][Step 3/5] Failed tests detected
> [00:47:34][Step 3/5] [INFO]
> [00:47:34][Step 3/5] [INFO] Results:
> [00:47:34][Step 3/5] [INFO]
> [00:47:34][Step 3/5] [ERROR] Errors:
> [00:47:34][Step 3/5] [ERROR] RootSubsystemOperationsTestCase>AbstractOperationsTestCase.setupLoggingDir:53->AbstractLoggingSubsystemTest.clearDirectory:499 ¯ FileSystem
> [00:47:34][Step 3/5] [INFO]
> [00:47:34][Step 3/5] [ERROR] Tests run: 71, Failures: 0, Errors: 1, Skipped: 9
> [00:47:34][Step 3/5] [INFO]
> [00:47:34][Step 3/5] [ERROR] There are test failures.
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (LOGMGR-205) Add ability to watch a logging configuration file for changes and reconfigure the log manager based on the new configuation
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/LOGMGR-205?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on LOGMGR-205:
-----------------------------------------
This might be very useful in the cloud.
A container is "immutable", except when it isn't. ;-) And AFAICT the biggest use case for "mutable" is tweaking logging. Currently to do that with an WF/EAP based container the user needs to open a terminal in the container and then run the CLI. Which is very WF/EAP specific.
Any kind of more general purpose solution would require some kind of "logging configuration API." And for Java, some logging.properties dialect variant (presumably jul) is a _possible _part of that. The other part possibly being use of ConfigMap. So, users configure logging via a logging.properties in the correct dialect in a ConfigMap. And if they update the config map the container detects and reacts. Or probably the default config is in standalone.xml with the ConfigMap only being a way to override the default or push changes.
There are a lot of issues with this idea, e.g. the scope of the config map content both across pods and across time (ConfigMap is not versioned), so what I describe above is nothing more than vague handwaving thought. But anyway, this RFE opens up some possibilities.
[~rcernich] FYI.
> Add ability to watch a logging configuration file for changes and reconfigure the log manager based on the new configuation
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: LOGMGR-205
> URL: https://issues.jboss.org/browse/LOGMGR-205
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> It could be useful to add a utility to watch a {{logging.properties}} file for changes and reconfigure the log manager based on these changes.
> As a test I've created an [example|https://gist.github.com/jamezp/68cd45982ba2b75aa2e95465695ec061] which could use some better options for removing no longer used configured objects.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11129) Temporary files not cleaned up after build
by Alexey Loubyansky (Jira)
[ https://issues.jboss.org/browse/WFLY-11129?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFLY-11129:
------------------------------------------
Could you please try with 2.0.1.Final and <version.org.wildfly.galleon-plugins>2.0.1.Final</version.org.wildfly.galleon-plugins>? It's galleon-plugins that should contain the fix.
> Temporary files not cleaned up after build
> ------------------------------------------
>
> Key: WFLY-11129
> URL: https://issues.jboss.org/browse/WFLY-11129
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 14.0.1.Final
> Environment: Solaris SPARC 10, Oracle JDK 1.80,0_181
> Reporter: Frank Langelage
> Assignee: Yeray Borges
> Priority: Major
> Labels: maven
>
> After building WildFly 14 from sources I have a lot of files in /var/tmp folder under a unique folder.
> {{sb2000.[neu2l]/mbi/mbi2e_all. ls -l /var/tmp
> total 5356
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:47 1397ea75-a91c-490a-9860-0041c101ef3a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:47 23d28bb9-0bdd-4991-aa9b-8805d613e720
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:34 2c3bd18e-8b83-46d3-b06f-18378e1cb12d
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:56 396f75f7-45b0-4b50-9607-9060cabf018b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:48 521e2a76-764c-4f5a-8a6e-282dd5978991
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:35 5430e295-1afa-4257-a2e0-e08b980b7e35
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:53 5a265551-8f04-48c9-8945-abf830e54852
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:46 70a1f863-7e84-40df-9206-23690bcf3ef6
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:02 7186627a-5a89-4334-bdc2-8bfb944e3841
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:52 85663b19-7e4e-48e9-8988-bd24c11fe4d4
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:39 8842f374-85b7-4018-a1fc-6274cb704785
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:05 973d7e32-efe5-4ffa-8f02-079cb7f29e71
> drwxr-x--- 3 oracle dba 2560 Aug 30 00:00 CVU_18.0.0.0.0_oracle
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:06 b8975817-9381-41a3-a512-e8fc6596fa7a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:40 bd0c1dd7-e8c6-413d-b658-f3c5236bba34
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:54 c3aa3f01-66df-4066-bb35-fed4bd0ad559
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:32 c66c2972-ad28-49e9-a7ff-a7ceed5b7ea3
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:24 ca8816d8-ad10-4860-a18b-0c09b37ed88b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:50 cc799f82-ed02-4dc4-b56e-ffe0d8eeab75
> drwx------ 2 langfr staff 512 Nov 15 2006 orbit-lafr
> -rw-rw-rw- 1 langfr staff 2383862 Oct 5 03:17 patchdiag.xref
> -rw------- 1 root root 314461 Oct 6 15:32 wscon-:0-5saqic}}
> {{sb2000.[neu2l]/var/tmp. ls -l 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/*/current
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-core/current:
> total 2
> drwxr-xr-x 7 jboss informix 512 Oct 6 14:55 6.0.2.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-servlet/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final}}
> Created by galleon feature pack build (galleon-pack/wildfly-feature-pack-build.xml).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFCORE-4158) RootSubsystemOperationsTestCase periodically fails on Windows
by James Perkins (Jira)
James Perkins created WFCORE-4158:
-------------------------------------
Summary: RootSubsystemOperationsTestCase periodically fails on Windows
Key: WFCORE-4158
URL: https://issues.jboss.org/browse/WFCORE-4158
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
The {{RootSubsystemOperationsTestCase}} periodically fails on Windows. The failure occurs in a {{@BeforeClass}} setup which attempts to clear the log directory. A file appears to still be locked by something from a previous test, likely the {{LoggingSubsystemTestCase}}. The failures seem to be consistent with the {{another.log}} being locked.
{code}
[00:47:20][Step 3/5] [INFO] Running org.jboss.as.logging.LoggingSubsystemTestCase
[00:47:34][Step 3/5] [INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.059 s - in org.jboss.as.logging.LoggingSubsystemTestCase
[00:47:34][Step 3/5] [INFO] Running org.jboss.as.logging.logmanager.Log4jAppenderTestCase
[00:47:34][Step 3/5] [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in org.jboss.as.logging.logmanager.Log4jAppenderTestCase
[00:47:34][Step 3/5] [INFO] Running org.jboss.as.logging.RootSubsystemOperationsTestCase
[00:47:34][Step 3/5] [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.001 s <<< FAILURE! - in org.jboss.as.logging.RootSubsystemOperationsTestCase
[00:47:34][Step 3/5] [ERROR] org.jboss.as.logging.RootSubsystemOperationsTestCase Time elapsed: 0.001 s <<< ERROR!
[00:47:34][Step 3/5] java.nio.file.FileSystemException:
[00:47:34][Step 3/5] C:\buildAgent\work\e9bccef30f12678d\logging\target\logs\another.log: The process cannot access the file because it is being used by another process.
[00:47:34][Step 3/5]
[00:47:34][Step 3/5] at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
[00:47:34][Step 3/5] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
[00:47:34][Step 3/5] at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
[00:47:34][Step 3/5] at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
[00:47:34][Step 3/5] at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
[00:47:34][Step 3/5] at java.nio.file.Files.delete(Files.java:1126)
[00:47:34][Step 3/5] at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:502)
[00:47:34][Step 3/5] at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:499)
[00:47:34][Step 3/5] at java.nio.file.Files.walkFileTree(Files.java:2670)
[00:47:34][Step 3/5] at java.nio.file.Files.walkFileTree(Files.java:2742)
[00:47:34][Step 3/5] at org.jboss.as.logging.AbstractLoggingSubsystemTest.clearDirectory(AbstractLoggingSubsystemTest.java:499)
[00:47:34][Step 3/5] at org.jboss.as.logging.AbstractOperationsTestCase.setupLoggingDir(AbstractOperationsTestCase.java:53)
[00:47:34][Step 3/5] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[00:47:34][Step 3/5] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[00:47:34][Step 3/5] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[00:47:34][Step 3/5] at java.lang.reflect.Method.invoke(Method.java:498)
[00:47:34][Step 3/5] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
[00:47:34][Step 3/5] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
[00:47:34][Step 3/5] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
[00:47:34][Step 3/5] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
[00:47:34][Step 3/5] at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
[00:47:34][Step 3/5] at org.junit.runners.Suite.runChild(Suite.java:128)
[00:47:34][Step 3/5] at org.junit.runners.Suite.runChild(Suite.java:27)
[00:47:34][Step 3/5] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
[00:47:34][Step 3/5] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
[00:47:34][Step 3/5] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
[00:47:34][Step 3/5] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
[00:47:34][Step 3/5] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
[00:47:34][Step 3/5] at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
[00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
[00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
[00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
[00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
[00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
[00:47:34][Step 3/5] at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
[00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
[00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
[00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
[00:47:34][Step 3/5] at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
[00:47:34][Step 3/5]
[00:47:34][Step 3/5] [INFO] Running org.jboss.as.logging.validators.SuffixValidatorTestCase
[00:47:34][Step 3/5] [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in org.jboss.as.logging.validators.SuffixValidatorTestCase
[00:47:34][Step 3/5] org.jboss.as.logging.RootSubsystemOperationsTestCase
[00:47:34][org.jboss.as.logging.RootSubsystemOperationsTestCase] RootSubsystemOperationsTestCase
[00:47:34][RootSubsystemOperationsTestCase] java.nio.file.FileSystemException: C:\buildAgent\work\e9bccef30f12678d\logging\target\logs\another.log: The process cannot access the file because it is being used by another process.
[00:47:34][RootSubsystemOperationsTestCase] java.nio.file.FileSystemException:
C:\buildAgent\work\e9bccef30f12678d\logging\target\logs\another.log: The process cannot access the file because it is being used by another process.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:502)
at org.jboss.as.logging.AbstractLoggingSubsystemTest$1.visitFile(AbstractLoggingSubsystemTest.java:499)
at java.nio.file.Files.walkFileTree(Files.java:2670)
at java.nio.file.Files.walkFileTree(Files.java:2742)
at org.jboss.as.logging.AbstractLoggingSubsystemTest.clearDirectory(AbstractLoggingSubsystemTest.java:499)
at org.jboss.as.logging.AbstractOperationsTestCase.setupLoggingDir(AbstractOperationsTestCase.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
[00:47:08][Step 3/5] Failed tests detected
[00:47:34][Step 3/5] [INFO]
[00:47:34][Step 3/5] [INFO] Results:
[00:47:34][Step 3/5] [INFO]
[00:47:34][Step 3/5] [ERROR] Errors:
[00:47:34][Step 3/5] [ERROR] RootSubsystemOperationsTestCase>AbstractOperationsTestCase.setupLoggingDir:53->AbstractLoggingSubsystemTest.clearDirectory:499 ¯ FileSystem
[00:47:34][Step 3/5] [INFO]
[00:47:34][Step 3/5] [ERROR] Tests run: 71, Failures: 0, Errors: 1, Skipped: 9
[00:47:34][Step 3/5] [INFO]
[00:47:34][Step 3/5] [ERROR] There are test failures.
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11129) Temporary files not cleaned up after build
by Frank Langelage (Jira)
[ https://issues.jboss.org/browse/WFLY-11129?page=com.atlassian.jira.plugin... ]
Frank Langelage commented on WFLY-11129:
----------------------------------------
I'm building / testing WildFly-Core 6.0.2.Final and WildFly-14.0.1.Final as you can see in my original post.
Both versions have
<version.org.jboss.galleon>2.0.0.Final</version.org.jboss.galleon>
in their pom.xml.
> Temporary files not cleaned up after build
> ------------------------------------------
>
> Key: WFLY-11129
> URL: https://issues.jboss.org/browse/WFLY-11129
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 14.0.1.Final
> Environment: Solaris SPARC 10, Oracle JDK 1.80,0_181
> Reporter: Frank Langelage
> Assignee: Yeray Borges
> Priority: Major
> Labels: maven
>
> After building WildFly 14 from sources I have a lot of files in /var/tmp folder under a unique folder.
> {{sb2000.[neu2l]/mbi/mbi2e_all. ls -l /var/tmp
> total 5356
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:47 1397ea75-a91c-490a-9860-0041c101ef3a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:47 23d28bb9-0bdd-4991-aa9b-8805d613e720
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:34 2c3bd18e-8b83-46d3-b06f-18378e1cb12d
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:56 396f75f7-45b0-4b50-9607-9060cabf018b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:48 521e2a76-764c-4f5a-8a6e-282dd5978991
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:35 5430e295-1afa-4257-a2e0-e08b980b7e35
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:53 5a265551-8f04-48c9-8945-abf830e54852
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:46 70a1f863-7e84-40df-9206-23690bcf3ef6
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:02 7186627a-5a89-4334-bdc2-8bfb944e3841
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:52 85663b19-7e4e-48e9-8988-bd24c11fe4d4
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:39 8842f374-85b7-4018-a1fc-6274cb704785
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:05 973d7e32-efe5-4ffa-8f02-079cb7f29e71
> drwxr-x--- 3 oracle dba 2560 Aug 30 00:00 CVU_18.0.0.0.0_oracle
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:06 b8975817-9381-41a3-a512-e8fc6596fa7a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:40 bd0c1dd7-e8c6-413d-b658-f3c5236bba34
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:54 c3aa3f01-66df-4066-bb35-fed4bd0ad559
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:32 c66c2972-ad28-49e9-a7ff-a7ceed5b7ea3
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:24 ca8816d8-ad10-4860-a18b-0c09b37ed88b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:50 cc799f82-ed02-4dc4-b56e-ffe0d8eeab75
> drwx------ 2 langfr staff 512 Nov 15 2006 orbit-lafr
> -rw-rw-rw- 1 langfr staff 2383862 Oct 5 03:17 patchdiag.xref
> -rw------- 1 root root 314461 Oct 6 15:32 wscon-:0-5saqic}}
> {{sb2000.[neu2l]/var/tmp. ls -l 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/*/current
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-core/current:
> total 2
> drwxr-xr-x 7 jboss informix 512 Oct 6 14:55 6.0.2.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-servlet/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final}}
> Created by galleon feature pack build (galleon-pack/wildfly-feature-pack-build.xml).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11129) Temporary files not cleaned up after build
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11129?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-11129:
---------------------------------------
Assignee: Yeray Borges (was: Jason Greene)
[~yersan] Could you handle this one? It may already be fixed in which case it's just a matter resolving it, otherwise please look into it.
> Temporary files not cleaned up after build
> ------------------------------------------
>
> Key: WFLY-11129
> URL: https://issues.jboss.org/browse/WFLY-11129
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 14.0.1.Final
> Environment: Solaris SPARC 10, Oracle JDK 1.80,0_181
> Reporter: Frank Langelage
> Assignee: Yeray Borges
> Priority: Major
> Labels: maven
>
> After building WildFly 14 from sources I have a lot of files in /var/tmp folder under a unique folder.
> {{sb2000.[neu2l]/mbi/mbi2e_all. ls -l /var/tmp
> total 5356
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:47 1397ea75-a91c-490a-9860-0041c101ef3a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:47 23d28bb9-0bdd-4991-aa9b-8805d613e720
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:34 2c3bd18e-8b83-46d3-b06f-18378e1cb12d
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:56 396f75f7-45b0-4b50-9607-9060cabf018b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:48 521e2a76-764c-4f5a-8a6e-282dd5978991
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:35 5430e295-1afa-4257-a2e0-e08b980b7e35
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:53 5a265551-8f04-48c9-8945-abf830e54852
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:46 70a1f863-7e84-40df-9206-23690bcf3ef6
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:02 7186627a-5a89-4334-bdc2-8bfb944e3841
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:52 85663b19-7e4e-48e9-8988-bd24c11fe4d4
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:39 8842f374-85b7-4018-a1fc-6274cb704785
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:05 973d7e32-efe5-4ffa-8f02-079cb7f29e71
> drwxr-x--- 3 oracle dba 2560 Aug 30 00:00 CVU_18.0.0.0.0_oracle
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:06 b8975817-9381-41a3-a512-e8fc6596fa7a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:40 bd0c1dd7-e8c6-413d-b658-f3c5236bba34
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:54 c3aa3f01-66df-4066-bb35-fed4bd0ad559
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:32 c66c2972-ad28-49e9-a7ff-a7ceed5b7ea3
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:24 ca8816d8-ad10-4860-a18b-0c09b37ed88b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:50 cc799f82-ed02-4dc4-b56e-ffe0d8eeab75
> drwx------ 2 langfr staff 512 Nov 15 2006 orbit-lafr
> -rw-rw-rw- 1 langfr staff 2383862 Oct 5 03:17 patchdiag.xref
> -rw------- 1 root root 314461 Oct 6 15:32 wscon-:0-5saqic}}
> {{sb2000.[neu2l]/var/tmp. ls -l 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/*/current
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-core/current:
> total 2
> drwxr-xr-x 7 jboss informix 512 Oct 6 14:55 6.0.2.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-servlet/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final}}
> Created by galleon feature pack build (galleon-pack/wildfly-feature-pack-build.xml).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-2133) Rule Unit unbind using `run` causes wrong lookup of DS on the wrong unit
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2133?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2133.
---------------------------------
Fix Version/s: 7.13.0.Final
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/f5d4c900ef39901cff6448a8ebc0382...
> Rule Unit unbind using `run` causes wrong lookup of DS on the wrong unit
> ------------------------------------------------------------------------
>
> Key: DROOLS-2133
> URL: https://issues.jboss.org/browse/DROOLS-2133
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.13.0.Final
>
>
> Please reference test {{testGuardAndRunBack}}
> {code:java}
> public static class MainHouseUnit implements RuleUnit {
> private DataSource<Date> now;
> private DataSource<String> part;
> private DataSource<Boolean> switch1;
> public MainHouseUnit() {
> super();
> }
> public DataSource<Date> getNow() {
> return now;
> }
> public DataSource<String> getPart() {
> return part;
> }
> public DataSource<Boolean> getSwitch1() {
> return switch1;
> }
> }
> public static class DayPartUnit implements RuleUnit {
> private DataSource<Date> now;
> private DataSource<Date> aScopedDS;
> private DataSource<String> part;
> public DayPartUnit() {
> super();
> }
> public DataSource<Date> getNow() {
> return now;
> }
> public DataSource<String> getPart() {
> return part;
> }
> public DataSource<Date> getaScopedDS() {
> return aScopedDS;
> }
> }
> public static class SwitchUnit implements RuleUnit {
> private DataSource<String> part;
> private DataSource<Boolean> switch1;
> public SwitchUnit() {
> super();
> }
> public DataSource<String> getPart() {
> return part;
> }
> public DataSource<Boolean> getSwitch1() {
> return switch1;
> }
> }
> private KieBase kieBaseMainGuardSubunitRunBackToMain(boolean currentStyle) {
> // use "hammer" approach with external multiple call to fire, or "drools.run()" approach in rules.
> System.out.println("Running with style: " + currentStyle);
> String drl1 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(MainHouseUnit.class) + "\n" +
> "import " + DayPartUnit.class.getCanonicalName() + "\n" +
> "import " + SwitchUnit.class.getCanonicalName() + "\n" +
> "rule GuardDayPartUnit when\n" +
> " Object() from now \n" +
> " not( String() from part ) \n" +
> "then\n" +
> " System.out.println(\"Guarding DayPartUnit\");\n" +
> " drools.guard(DayPartUnit.class);\n" +
> "end\n" +
> "rule GuardSwitchUnit when\n" +
> " String() from part \n" +
> " not( Boolean() from switch1 ) \n" +
> "then\n" +
> " System.out.println(\"Guarding SwitchUnit\");\n" +
> " drools.guard(SwitchUnit.class);\n" +
> "end\n";
> String drl2 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(DayPartUnit.class) + "\n" +
> "import " + MainHouseUnit.class.getCanonicalName() + "\n" +
> "rule doDayPartUnit when\n" +
> " $n : Object() from now \n" +
> "then\n" +
> " System.out.println(\"Inside DayPartUnit: \"+$n);\n" +
> " part.insert(\"Morning\");\n" +
> (currentStyle ? "//" : "") + " drools.run(MainHouseUnit.class);\n" +
> "end\n";
> String drl3 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(SwitchUnit.class) + "\n" +
> "import " + MainHouseUnit.class.getCanonicalName() + "\n" +
> "rule doSwitchUnit when\n" +
> " $n : String() from part \n" +
> "then\n" +
> " System.out.println(\"Inside SwitchUnit: \"+$n);\n" +
> " switch1.insert(true);\n" +
> (currentStyle ? "//" : "") + " drools.run(MainHouseUnit.class);\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent(drl1, ResourceType.DRL)
> .addContent(drl2, ResourceType.DRL)
> .addContent(drl3, ResourceType.DRL)
> .build();
> return kbase;
> }
> @Test
> public void testMainGuardSubunitRunBackToMain_usingHammerStyle() throws Exception {
> KieBase kbase = kieBaseMainGuardSubunitRunBackToMain(true);
> RuleUnitExecutor executor = RuleUnitExecutor.create().bind(kbase);
> executor.newDataSource("now", LocalDateTime.now());
> executor.newDataSource("part");
> executor.newDataSource("aScopedDS");
> DataSource<Boolean> switch1 = executor.newDataSource("switch1");
> RuleUnit adultUnit = new MainHouseUnit();
> executor.run(adultUnit);
> // need a second, "hammer" run.
> executor.run(adultUnit);
> assertEquals(true, switch1.iterator().next());
> }
> @Test
> public void testMainGuardSubunitRunBackToMain_usingRunStyle() throws Exception {
> KieBase kbase = kieBaseMainGuardSubunitRunBackToMain(false);
> RuleUnitExecutor executor = RuleUnitExecutor.create().bind(kbase);
> executor.newDataSource("now", LocalDateTime.now());
> executor.newDataSource("part");
> executor.newDataSource("aScopedDS");
> DataSource<Boolean> switch1 = executor.newDataSource("switch1");
> RuleUnit adultUnit = new MainHouseUnit();
> executor.run(adultUnit); // FAILs with trying to lookup method getaScopedDS() on the MainHouseUnit (which is not correct unit).
> // does NOT need a second, "hammer" run.
> assertEquals(true, switch1.iterator().next());
> }
> public static class EmptyUnit implements RuleUnit {
> public EmptyUnit() {
> // no-args constructor.
> }
> }
> public static class StringDSUnit implements RuleUnit {
> private DataSource<String> strings;
> public StringDSUnit() {
> // no-args constructor.
> }
> public DataSource<String> getStrings() {
> return strings;
> }
> }
> @Test
> public void testGuardAndRunBack() {
> String drl1 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(EmptyUnit.class) + "\n" +
> "import " + StringDSUnit.class.getCanonicalName() + "\n" +
> "rule RGuard when\n" +
> "then\n" +
> " System.out.println(\"Guarding StringDSUnit\");\n" +
> " drools.guard(StringDSUnit.class);\n" +
> "end\n";
> String drl2 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(StringDSUnit.class) + "\n" +
> "import " + EmptyUnit.class.getCanonicalName() + "\n" +
> "rule RGoBack when\n" +
> "then\n" +
> " System.out.println(\"Inside StringDSUnit: \");\n" +
> " drools.run(EmptyUnit.class);\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent(drl1, ResourceType.DRL)
> .addContent(drl2, ResourceType.DRL)
> .build();
> RuleUnitExecutor executor = RuleUnitExecutor.create().bind(kbase);
> executor.newDataSource("strings", "abc", "xyz");
> RuleUnit adultUnit = new EmptyUnit();
> executor.run(adultUnit); // FAILs with trying to lookup method getStrings() on the EmptyUnit (which is not correct unit).
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11129) Temporary files not cleaned up after build
by Alexey Loubyansky (Jira)
[ https://issues.jboss.org/browse/WFLY-11129?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFLY-11129:
------------------------------------------
Please check the version of galleon-plugins in pom.xml. If it's 2.0.0.Final it might already be fixed. The build has upgraded to 2.0.1.Final today.
> Temporary files not cleaned up after build
> ------------------------------------------
>
> Key: WFLY-11129
> URL: https://issues.jboss.org/browse/WFLY-11129
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 14.0.1.Final
> Environment: Solaris SPARC 10, Oracle JDK 1.80,0_181
> Reporter: Frank Langelage
> Assignee: Jason Greene
> Priority: Major
> Labels: maven
>
> After building WildFly 14 from sources I have a lot of files in /var/tmp folder under a unique folder.
> {{sb2000.[neu2l]/mbi/mbi2e_all. ls -l /var/tmp
> total 5356
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:47 1397ea75-a91c-490a-9860-0041c101ef3a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:47 23d28bb9-0bdd-4991-aa9b-8805d613e720
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:34 2c3bd18e-8b83-46d3-b06f-18378e1cb12d
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:56 396f75f7-45b0-4b50-9607-9060cabf018b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:48 521e2a76-764c-4f5a-8a6e-282dd5978991
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:35 5430e295-1afa-4257-a2e0-e08b980b7e35
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:53 5a265551-8f04-48c9-8945-abf830e54852
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:46 70a1f863-7e84-40df-9206-23690bcf3ef6
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:02 7186627a-5a89-4334-bdc2-8bfb944e3841
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:52 85663b19-7e4e-48e9-8988-bd24c11fe4d4
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:39 8842f374-85b7-4018-a1fc-6274cb704785
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:05 973d7e32-efe5-4ffa-8f02-079cb7f29e71
> drwxr-x--- 3 oracle dba 2560 Aug 30 00:00 CVU_18.0.0.0.0_oracle
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:06 b8975817-9381-41a3-a512-e8fc6596fa7a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:40 bd0c1dd7-e8c6-413d-b658-f3c5236bba34
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:54 c3aa3f01-66df-4066-bb35-fed4bd0ad559
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:32 c66c2972-ad28-49e9-a7ff-a7ceed5b7ea3
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:24 ca8816d8-ad10-4860-a18b-0c09b37ed88b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:50 cc799f82-ed02-4dc4-b56e-ffe0d8eeab75
> drwx------ 2 langfr staff 512 Nov 15 2006 orbit-lafr
> -rw-rw-rw- 1 langfr staff 2383862 Oct 5 03:17 patchdiag.xref
> -rw------- 1 root root 314461 Oct 6 15:32 wscon-:0-5saqic}}
> {{sb2000.[neu2l]/var/tmp. ls -l 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/*/current
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-core/current:
> total 2
> drwxr-xr-x 7 jboss informix 512 Oct 6 14:55 6.0.2.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-servlet/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final}}
> Created by galleon feature pack build (galleon-pack/wildfly-feature-pack-build.xml).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3085) Add index info to ScenarioException
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-3085?page=com.atlassian.jira.plugi... ]
Daniele Zonca updated DROOLS-3085:
----------------------------------
Description: Improve error reporting and use index as information instead of require scenario description (was: accessing Scenario.getDescription() throws exception. Refactor to avoid that *or* catch all throwned exceptions.)
> Add index info to ScenarioException
> -------------------------------------
>
> Key: DROOLS-3085
> URL: https://issues.jboss.org/browse/DROOLS-3085
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Daniele Zonca
> Priority: Major
>
> Improve error reporting and use index as information instead of require scenario description
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months