[JBoss JIRA] (WFLY-8969) wildfly-maven-plugin start stand alone instance with basedir different than standalone folder not working
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8969?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-8969:
------------------------------
Component/s: (was: Application Client)
> wildfly-maven-plugin start stand alone instance with basedir different than standalone folder not working
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8969
> URL: https://issues.jboss.org/browse/WFLY-8969
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Windows 7 using wildfly 10.0.0.Final and the latest version of the wildfly-maven-plugin
> Reporter: Nuno Godinho de Matos
> Assignee: Stuart Douglas
> Priority: Minor
>
> Hi.
> So far, I have not been successfuly having the wildfly maven plugin behave as the standalone.bat script, and use it to startup any standalone server whose base dir is not the "standalone" base dir folder itself.
> I believe the maven plugin is forcincing the convention that the stanadlone base dire has to be the standalone folder withing the wildfly home.
> Here is an example.
> If I am located at my WILDFLY_HOME\bin, I can trigger the following command line call to start up the appropriate standlone base dir with the appropriate configuration.
> standalone.bat --server-config=standalone-empty.xml -Djboss.server.base.dir=C:\dev\Widlfly10\wildfly-10.0.0.Final\standalone-cli
> On the other hand, If I were to try to the same thing using the maven plugin, I would be forced to run a "dirty command" (look at the relative path I am doing to access the configuration file) such as the following:
> mvn org.wildfly.plugins:wildfly-maven-plugin:1.2.0.Alpha5:start -Dwildfly.server.type=STANDALONE -Djboss-as.home=C:\dev\Widlfly10\wildfly-10.0.0.Final -Dwildfly.serverArgs="-Djboss.server.base.dir=C:/dev/Widlfly10/wildfly-10.0.0.Final/standalone-cli" -Dwildfly.serverConfig=../../standalone-cli/configuration/standalone-empty.xml
> The server starts up, but I can clearly see in jvisualvm that the base dir continues to be standalone folder.
> However, if I play with the value I am setting on the -Djboss.server.base.dir= and I write the value something that is an invalid path, then I correctly get an error telling me that my folder is invalid.
> This problem is also explained on the following stack over flow thread.
> https://stackoverflow.com/questions/44654819/wildfly-maven-plugin-is-ther...
> Am I making some sort of mistake on my configuration?
> Or is there a bug in the plugin and a fix should be added to ensure that asking the pluging to start a standalone server with a different base directory is working properly?
> My Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8969) wildfly-maven-plugin start stand alone instance with basedir different than standalone folder not working
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-8969:
-------------------------------------------
Summary: wildfly-maven-plugin start stand alone instance with basedir different than standalone folder not working
Key: WFLY-8969
URL: https://issues.jboss.org/browse/WFLY-8969
Project: WildFly
Issue Type: Bug
Components: Application Client
Affects Versions: 10.0.0.Final
Environment: Windows 7 using wildfly 10.0.0.Final and the latest version of the wildfly-maven-plugin
Reporter: Nuno Godinho de Matos
Assignee: Stuart Douglas
Priority: Minor
Hi.
So far, I have not been successfuly having the wildfly maven plugin behave as the standalone.bat script, and use it to startup any standalone server whose base dir is not the "standalone" base dir folder itself.
I believe the maven plugin is forcincing the convention that the stanadlone base dire has to be the standalone folder withing the wildfly home.
Here is an example.
If I am located at my WILDFLY_HOME\bin, I can trigger the following command line call to start up the appropriate standlone base dir with the appropriate configuration.
standalone.bat --server-config=standalone-empty.xml -Djboss.server.base.dir=C:\dev\Widlfly10\wildfly-10.0.0.Final\standalone-cli
On the other hand, If I were to try to the same thing using the maven plugin, I would be forced to run a "dirty command" (look at the relative path I am doing to access the configuration file) such as the following:
mvn org.wildfly.plugins:wildfly-maven-plugin:1.2.0.Alpha5:start -Dwildfly.server.type=STANDALONE -Djboss-as.home=C:\dev\Widlfly10\wildfly-10.0.0.Final -Dwildfly.serverArgs="-Djboss.server.base.dir=C:/dev/Widlfly10/wildfly-10.0.0.Final/standalone-cli" -Dwildfly.serverConfig=../../standalone-cli/configuration/standalone-empty.xml
The server starts up, but I can clearly see in jvisualvm that the base dir continues to be standalone folder.
However, if I play with the value I am setting on the -Djboss.server.base.dir= and I write the value something that is an invalid path, then I correctly get an error telling me that my folder is invalid.
This problem is also explained on the following stack over flow thread.
https://stackoverflow.com/questions/44654819/wildfly-maven-plugin-is-ther...
Am I making some sort of mistake on my configuration?
Or is there a bug in the plugin and a fix should be added to ensure that asking the pluging to start a standalone server with a different base directory is working properly?
My Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is not connected" error during shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1958?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1958:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1399195|https://bugzilla.redhat.com/show_bug.cgi?id=1399195] from ASSIGNED to VERIFIED
> RequestCorrelator "channel is not connected" error during shutdown
> ------------------------------------------------------------------
>
> Key: JGRP-1958
> URL: https://issues.jboss.org/browse/JGRP-1958
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.5
>
>
> Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply:
> ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1]
> [incoming JGroups message]
> It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message.
> It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1621) DMN validation fails when executed on IBM JDK when checking referenced types
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1621?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1621:
-------------------------------------
Assignee: Tibor Zimányi (was: Matteo Mortari)
> DMN validation fails when executed on IBM JDK when checking referenced types
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1621
> URL: https://issues.jboss.org/browse/DROOLS-1621
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Tibor Zimányi
> Labels: reported-by-qe
> Fix For: 7.1.0.Final
>
>
> When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
> It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
> Possible fix that adds toString() to appropriate validation rules can be found here [2].
> [1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
> [2] https://github.com/kiegroup/drools/pull/1332
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1621) DMN validation fails when executed on IBM JDK when checking referenced types
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1621?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1621:
----------------------------------
Sprint: 2017 Week 24-25 (was: 2017 Week 26-27)
> DMN validation fails when executed on IBM JDK when checking referenced types
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1621
> URL: https://issues.jboss.org/browse/DROOLS-1621
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Matteo Mortari
> Labels: reported-by-qe
> Fix For: 7.1.0.Final
>
>
> When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
> It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
> Possible fix that adds toString() to appropriate validation rules can be found here [2].
> [1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
> [2] https://github.com/kiegroup/drools/pull/1332
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1621) DMN validation fails when executed on IBM JDK when checking referenced types
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1621?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1621:
----------------------------------
Sprint: 2017 Week 26-27
> DMN validation fails when executed on IBM JDK when checking referenced types
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1621
> URL: https://issues.jboss.org/browse/DROOLS-1621
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Matteo Mortari
> Labels: reported-by-qe
> Fix For: 7.1.0.Final
>
>
> When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
> It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
> Possible fix that adds toString() to appropriate validation rules can be found here [2].
> [1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
> [2] https://github.com/kiegroup/drools/pull/1332
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8961) Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8961?page=com.atlassian.jira.plugin.... ]
Josef Cacek commented on WFLY-8961:
-----------------------------------
This issue was created (cloned) to have a WFLY one number to put into test {{@Ignore}} annotation value in the testsuite.
> Elytron in JMS: Unable to use authenticate with JBOSS-LOCAL-USER
> ----------------------------------------------------------------
>
> Key: WFLY-8961
> URL: https://issues.jboss.org/browse/WFLY-8961
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Josef Cacek
> Assignee: Jeff Mesnil
> Priority: Critical
> Labels: eap7.1.0-to-prd
>
> I'm not able to authenticate to JMS when using JBOSS-LOCAL-USER SASL mechanism. {{ConnectionFactory.createContext()}} call and the client call fails with:
> {noformat}
> javax.jms.JMSSecurityRuntimeException: AMQ119031: Unable to validate user
> {noformat}
> This issue is similar to JBEAP-10527, but for JBOSS-LOCAL-USER mechanism (compared to DIGEST-MD5 for instance) we don't have a username or password. This problem can be in other SASL mechanisms too (e.g. EXTERNAL - where we authenticate a user with client certificate).
> Code used for testing:
> {code:java}
> AuthenticationContext.empty()
> .with(MatchRule.ALL,
> AuthenticationConfiguration.empty().useProvidersFromClassLoader(getClass().getClassLoader())
> .setSaslMechanismSelector(SaslMechanismSelector.fromString("JBOSS-LOCAL-USER")))
> .run(() -> {
> try {
> // ... initialize naming etc. here
> ConnectionFactory connectionFactory = (ConnectionFactory) namingContext
> .lookup("jms/RemoteConnectionFactory");
> JMSContext context = connectionFactory.createContext();
> } catch (NamingException e) {
> // ...
> }
> });
> {code}
> Server log contains:
> {noformat}
> 2017-06-08 15:00:07,076 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Handling MechanismInformationCallback type='SASL' name='JBOSS-LOCAL-USER' host-name='localhost' protocol='remote'
> 2017-06-08 15:00:07,077 TRACE [org.wildfly.security] (default I/O-4) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@55b75111] for mechanism [JBOSS-LOCAL-USER]
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Handling NameCallback: authenticationName = $local
> 2017-06-08 15:00:07,083 TRACE [org.wildfly.security] (default task-2) Principal assigning: [$local], pre-realm rewritten: [$local], realm name: [local], post-realm rewritten: [$local], realm rewritten: [$local]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Role mapping: principal [$local] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [guest]
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing principal $local.
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Authorizing against the following attributes: [] => []
> 2017-06-08 15:00:07,084 TRACE [org.wildfly.security] (default task-2) Permission mapping: identity [$local] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Authorization succeed
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) RunAs authorization succeed - the same identity
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthorizeCallback: authenticationID = $local authorizationID = $local authorized = true
> 2017-06-08 15:00:07,095 TRACE [org.wildfly.security] (default task-2) Handling AuthenticationCompleteCallback: succeed
> 2017-06-08 15:00:07,099 TRACE [org.wildfly.security] (default task-2) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=$local, securityDomain=org.wildfly.security.auth.server.SecurityDomain@24c5501a, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='local', securityRealm=org.wildfly.security.auth.realm.SimpleMapBackedSecurityRealm@426b003b}, creationTime=2017-06-08T13:00:07.083Z}
> 2017-06-08 15:00:07,142 INFO [org.wildfly.naming] (default task-4) WildFly Naming version 1.0.0.Beta16
> 2017-06-08 15:00:07,908 TRACE [org.wildfly.security] (default I/O-3) Permission mapping: identity [anonymous] with roles [guest] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = false
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Couldn't find any bindings for address=activemq.notifications on message=ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250
> 2017-06-08 15:00:07,920 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (default I/O-3) Message ServerMessage[messageID=25,durable=true,userID=null,priority=0, bodySize=512, timestamp=0,expiration=0, durable=true, address=activemq.notifications,properties=TypedProperties[_AMQ_NotifType=SECURITY_AUTHENTICATION_VIOLATION,_AMQ_NotifTimestamp=1496926807920]]@1825253250 is not going anywhere as it didn't have a binding on address:activemq.notifications
> 2017-06-08 15:00:07,924 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1283)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:379)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:362)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:69)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {noformat}
> [~dlofthouse], [~jmesnil], Is there another way to use these SASL mechanisms (without username and password) to create JMSContext? If not then we should change priority to blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1621) DMN validation fails when executed on IBM JDK when checking referenced types
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1621?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1621:
-------------------------------------
Assignee: Matteo Mortari (was: Edson Tirelli)
> DMN validation fails when executed on IBM JDK when checking referenced types
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1621
> URL: https://issues.jboss.org/browse/DROOLS-1621
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Matteo Mortari
> Labels: reported-by-qe
> Fix For: 7.1.0.Final
>
>
> When running test method ValidatorTest.testVALIDATION(), the test fails with this output[1]. This is caused by rules _TYPEREF_NOT_FEEL_NOT_DEF_p1_ and _TYPEREF_NOT_FEEL_NOT_DEF_p2_ from _dmn-validation-rules-typeref.drl_ matching during validation and so triggering errors.
> It looks like this is caused by different evaluation of constraint _not( ItemDefinition( name == $typeRef ) )_ on IBM JDK. $typeRef is of type QName. It looks like that when running on ORacle JDK, the toString() method of QName is invoked automatically so the ItemDefinition is matched. Otherwise, when running on IBM JDK, the constraint must be changed to _not( ItemDefinition( name == $typeRef.toString() ) )_ so ItemDefinition is matched. I'm not sure if this is really the cause of this problem or just a workaround. The session looks properly populated with facts during validation.
> Possible fix that adds toString() to appropriate validation rules can be found here [2].
> [1] https://gist.github.com/baldimir/2dbc678886ad30a091a30bdb1d91f4cf
> [2] https://github.com/kiegroup/drools/pull/1332
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months