[JBoss JIRA] (WFCORE-823) Undeprecate ExtensionContext.isRegisterTransformers()
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-823?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-823:
----------------------------------
Assignee: Tomaz Cerar (was: Kabir Khan)
> Undeprecate ExtensionContext.isRegisterTransformers()
> -----------------------------------------------------
>
> Key: WFCORE-823
> URL: https://issues.jboss.org/browse/WFCORE-823
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Priority: Minor
>
> Feel free to just reject this if you think the @Deprecated should remain. It's no big deal.
> I don't have anything specific in mind re: how transformers get registered, and it's quite likely the existing way will remain for the life of EAP 7. So I'm comfortable removing the @Deprecated from this method if you are.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5930) Unable to load deployments
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5930?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-5930.
-------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Done
should be addressed as part of WFLY-6600
> Unable to load deployments
> --------------------------
>
> Key: WFLY-5930
> URL: https://issues.jboss.org/browse/WFLY-5930
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management, Web (Undertow)
> Affects Versions: 9.0.2.Final
> Reporter: Hamed Abdollahpour
> Assignee: Tomaz Cerar
> Fix For: 10.1.0.Final
>
>
> Fail to get list of deployment on application server with this error:
> 12:19:40,130 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "discripto-ear.ear"),
> ("subdeployment" => "discripto-rest.war"),
> ("subsystem" => "undertow"),
> ("servlet" => "com.wpic.discripto.rest.App")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> 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.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 12:21:20,258 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "discripto-ear.ear"),
> ("subdeployment" => "discripto-rest.war"),
> ("subsystem" => "undertow"),
> ("servlet" => "com.wpic.discripto.rest.App")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> 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.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> It works perfect after restarting.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Will Wright (JIRA)
[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ]
Will Wright commented on JGRP-2090:
-----------------------------------
Thanks for getting back. I can see what the underlying issue was now. My publisher was running 3.6.6 and the receiver was on 3.6.10. Looks like this change does not maintain binary compatibility between the micro version, however, the checks in Version.isBinaryCompatible assume it does.
> JGRP000027: failed passing message up
> -------------------------------------
>
> Key: JGRP-2090
> URL: https://issues.jboss.org/browse/JGRP-2090
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Will Wright
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
> The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
> java.lang.NullPointerException: null
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months