July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBVFS-198) Correct or remove usage of finalize in VFS, TempDir, and TempFileProvider

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBVFS-198?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated JBVFS-198: ------------------------------ Fix Version/s: 3.2.13.Final (was: 3.2.12.Final) > Correct or remove usage of finalize in VFS, TempDir, and TempFileProvider > ------------------------------------------------------------------------- > > Key: JBVFS-198 > URL: https://issues.jboss.org/browse/JBVFS-198 > Project: JBoss VFS > Issue Type: Task > Reporter: Jason Greene > Assignee: Tomaz Cerar > Fix For: 3.2.13.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5858) Testsuite on windows sometimes fails with file locks on standalone-*.xml

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5858?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-5858. ------------------------------- Resolution: Done > Testsuite on windows sometimes fails with file locks on standalone-*.xml > ------------------------------------------------------------------------- > > Key: WFLY-5858 > URL: https://issues.jboss.org/browse/WFLY-5858 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 10.0.0.CR3 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 10.1.0.Final > > > ModelPersistenceTestCase.testSimpleOperation occasionally fails with the following pattern: > {code} > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.jboss.as.test.integration.management.api.ModelPersistenceTestCase.testSimpleOperation(ModelPersistenceTestCase.java:119) > ------- Stdout: ------- > 14:06:18,604 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml > at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:552) > at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:65) > at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58) > at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:780) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147) > 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:147) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519) > 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) > Caused by: java.nio.file.FileSystemException: C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone_xml_history\standalone.last.xml: 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.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at org.jboss.as.controller.persistence.FilePersistenceUtils.copyFile(FilePersistenceUtils.java:73) > at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:550) > ... 23 more > {code} > The test fails because the standalone.last.xml file isn't being updated as expected; the file isn't updated due to the "The process cannot access the file because it is being used by another process" IOException. > 3 generally possibilities come to mind: > 1) There's some other process on the CI server that really is using the file. Something like antivirus that touches lots of files briefly. (Not suggesting its actually AV.) It's odd we don't get other failures though; e.g. failures to persist the main config file. > 2) It's the test driver process that's holding the file, conflicting with the server process. This is certainly possible. I've looked though and the test driver seems to be correct in terms of how it handles the file, reading it to calculate a CRC and then closing the stream used to do that in a finally block. It's also odd that this would only happen on Windows CI. Still, since we know we have 2 processes, test driver and server, both touching a file and we are getting an exception about 2 processes conflicting over that file, something in this area seems most likely. > 3) There's some flaw in ConfigurationFile itself. But it's odd that a flaw there would produce an exception talking about how the file "is being used by another process". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1197) Enhance missing capability logging during subsystem testing

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1197?page=com.atlassian.jira.plugi... ] Tomaz Cerar resolved WFCORE-1197. --------------------------------- Fix Version/s: 3.0.0.Alpha3 (was: 3.0.0.Alpha4) Resolution: Done This was already fixed if you still see it, please reopen. > Enhance missing capability logging during subsystem testing > ----------------------------------------------------------- > > Key: WFCORE-1197 > URL: https://issues.jboss.org/browse/WFCORE-1197 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 2.0.4.Final > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 3.0.0.Alpha3 > > > Making changes to the Undertow subsystem I was presented with the following failure: - > {noformat} > <testcase name="testRuntime" classname="org.wildfly.extension.undertow.UndertowSubsystemTestCase" time="1.611"> > <error type="java.lang.NullPointerException:">java.lang.NullPointerException: null > at org.wildfly.extension.undertow.UndertowSubsystemTestCase.testRuntime(UndertowSubsystemTestCase.java:118) > {noformat} > It was only after enabling other logging I found the real cause: - > {noformat} > ec 08, 2015 6:19:22 PM org.jboss.as.controller.OperationContextImpl validateCapabilities > ERROR: WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/application-security-domain=other' are not available: > org.wildfly.security.http-server-mechanism-factory.elytron-factory; There are no known registration points which can provide this capability. > {noformat} > The NullPointerException above is because it is detected the booting failed but the error was never made available. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ] Matteo Mortari closed DROOLS-1215. ---------------------------------- Resolution: Won't Fix > import function(s) with collision on declared Pojo field names odd behavior and no warning > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1215 > URL: https://issues.jboss.org/browse/DROOLS-1215 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Attachments: DROOLS-1215.zip > > > Hello, > not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype: > {code} > global java.util.Set controlSet; > rule "will execute per each Measurement having ID color" > no-loop > when > WantToKeep( condition == "color" ) > Measurement( id == "color", $colorVal : val ) > then > controlSet.add($colorVal); > end > declare WantToKeep > condition : String > end > rule "kickstart" > salience 999 > when > eval( true ) > then > insert(new WantToKeep( "color" )); > end > {code} > This works as expected until adding the following import statement: > {code} > import function org.jooq.impl.DSL.*; > {code} > and then the test will fail. > I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form. > I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking. > I will attach reproducer and workaround in the appropriate sections. > Thank you, > Ciao, > MM -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1215: ---------------------------------------- This is not strictly related to Drools issue and more MVEL related.(in details, this is related to the order by which MVEL would resolve between imports, variables and fields, both during compilation phase and evaluation phase). Given workarounds do exist and are effective, will close as won't fix. Other identified workarounds (beside the original one noted above): * in the LHS, call the getter by explicit method instead of mvel style, i.e.: avoid {{WantToKeep( condition ...}} and use {{WantToKeep( getCondition() ...}} instead. * in the use-case presented in this reproducer, the import-star is used to enable all the (jOOQ's) DSL methods. Instead of using the import-star, do import only those DSL methods really required to avoid name conflict. * in the use-case presented in this reproducer, use separation of concern, and keep the (jOOQ's) DSL usage in a separate DRL file, or even better refactor the (jOOQ's) DSL code into a dedicated Java class > import function(s) with collision on declared Pojo field names odd behavior and no warning > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1215 > URL: https://issues.jboss.org/browse/DROOLS-1215 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Attachments: DROOLS-1215.zip > > > Hello, > not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype: > {code} > global java.util.Set controlSet; > rule "will execute per each Measurement having ID color" > no-loop > when > WantToKeep( condition == "color" ) > Measurement( id == "color", $colorVal : val ) > then > controlSet.add($colorVal); > end > declare WantToKeep > condition : String > end > rule "kickstart" > salience 999 > when > eval( true ) > then > insert(new WantToKeep( "color" )); > end > {code} > This works as expected until adding the following import statement: > {code} > import function org.jooq.impl.DSL.*; > {code} > and then the test will fail. > I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form. > I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking. > I will attach reproducer and workaround in the appropriate sections. > Thank you, > Ciao, > MM -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ] Matteo Mortari reassigned DROOLS-1215: -------------------------------------- Assignee: Matteo Mortari (was: Mario Fusco) > import function(s) with collision on declared Pojo field names odd behavior and no warning > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1215 > URL: https://issues.jboss.org/browse/DROOLS-1215 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Attachments: DROOLS-1215.zip > > > Hello, > not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype: > {code} > global java.util.Set controlSet; > rule "will execute per each Measurement having ID color" > no-loop > when > WantToKeep( condition == "color" ) > Measurement( id == "color", $colorVal : val ) > then > controlSet.add($colorVal); > end > declare WantToKeep > condition : String > end > rule "kickstart" > salience 999 > when > eval( true ) > then > insert(new WantToKeep( "color" )); > end > {code} > This works as expected until adding the following import statement: > {code} > import function org.jooq.impl.DSL.*; > {code} > and then the test will fail. > I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form. > I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking. > I will attach reproducer and workaround in the appropriate sections. > Thank you, > Ciao, > MM -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6852) Upgrade mod_cluster to 1.3.3.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6852?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6852: --------------------------------- Description: Resolves WFLY-6294 and bring in fix for MODCLUSTER-509. (was: Resolves WFLY-6294.) > Upgrade mod_cluster to 1.3.3.Final > ---------------------------------- > > Key: WFLY-6852 > URL: https://issues.jboss.org/browse/WFLY-6852 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 10.1.0.Final > > > Resolves WFLY-6294 and bring in fix for MODCLUSTER-509. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6853) Picketlink does not return SessionIndex in LogoutRequest

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6853?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6853: ----------------------------------------------- Vlado Pakan <vpakan(a)redhat.com> changed the Status of [bug 1353338|https://bugzilla.redhat.com/show_bug.cgi?id=1353338] from ASSIGNED to POST > Picketlink does not return SessionIndex in LogoutRequest > -------------------------------------------------------- > > Key: WFLY-6853 > URL: https://issues.jboss.org/browse/WFLY-6853 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Vlado Pakan > Assignee: Vlado Pakan > > When logged out from application SAML logout message does not contain SessionIndex tag. > See referenced bugzilla for more information -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6236) Remove RTS dependency on resteasy-jettison-provider

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-6236?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on WFLY-6236: --------------------------------------- They've only been added to Narayana endpoints. I cannot think of a way how user functionality could be affected by this. > Remove RTS dependency on resteasy-jettison-provider > --------------------------------------------------- > > Key: WFLY-6236 > URL: https://issues.jboss.org/browse/WFLY-6236 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 10.1.0.Final > > > resteasy-jettison-provider is going to be deprecated so ti would be good to remove the dependency on it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1231) Container is not upgraded until restarted

by Maciej Swiderski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1231?page=com.atlassian.jira.plugi... ] Maciej Swiderski moved RHBPMS-4111 to DROOLS-1231: -------------------------------------------------- Project: Drools (was: JBoss BPMS Platform) Key: DROOLS-1231 (was: RHBPMS-4111) Workflow: GIT Pull Request workflow (was: CDW v1) Docs QE Status: NEW Component/s: core engine kie server (was: Kie-Server) Affects Version/s: 7.0.0.Beta1 (was: 6.3.0.GA) QE Status: NEW > Container is not upgraded until restarted > ----------------------------------------- > > Key: DROOLS-1231 > URL: https://issues.jboss.org/browse/DROOLS-1231 > Project: Drools > Issue Type: Bug > Components: core engine, kie server > Affects Versions: 7.0.0.Beta1 > Reporter: Maciej Swiderski > Assignee: Mario Fusco > > If you create a container, and then upgrade it to a higher kjar version - the resources (processes, rules) are not actually upgraded until you STOP/START this container -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016