[JBoss JIRA] (WFLY-10143) Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10143?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-10143:
---------------------------------------
[~jmesnil] Yes, i've just tried it with Wildfly master (0fa3f2a06fbeff769d0f94e6aab5279f78e2cf92) and it works. Thanks!
> Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10143
> URL: https://issues.jboss.org/browse/WFLY-10143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 13.0.0.Beta1
>
>
> If standalone JMS client is using only jboss-client.jar on classpath then during look up of connection factory fails with:
> {code}
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError: javax/json/JsonValue
> at org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:44)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
> at org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.newLocator(ServerLocatorImpl.java:411)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:209)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:202)
> at org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory.<init>(ActiveMQJMSConnectionFactory.java:34)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructor(SerializableClass.java:340)
> at org.jboss.marshalling.reflect.SerializableClass.callNoArgConstructor(SerializableClass.java:292)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1408)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:243)
> at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
> at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
> at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
> at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.jms.client.ProducerTransAck.run(ProducerTransAck.java:78)
> Caused by: java.lang.ClassNotFoundException: javax.json.JsonValue
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 33 more
> {code}
> This is because javax.json-api jar is missing.
> Wildfly 12 jms-client-bom does not suffer by this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-9699) Add attribute to model which will indicate that backup is synchronized with live server
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9699?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-9699:
---------------------------------
Assignee: (was: Jeff Mesnil)
> Add attribute to model which will indicate that backup is synchronized with live server
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-9699
> URL: https://issues.jboss.org/browse/WFLY-9699
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Priority: Critical
>
> If HA is configured with replicated journal then it takes some time to backup to synchronize with live server. Once backup is in sync with live then following information appears in server.log:
> {code}
> 13:20:00,739 INFO [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-457000966)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=bc015b34-fd73-11e5-80ca-1b35f669abb8 is synchronized with live-server.
> 13:20:01,500 INFO [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@41f992ab-83559664)) AMQ221031: backup announced
> {code}
> Reading server logs to see whether backup is in sync is not convinient and user friendly way. Could we add this information to model so it can be detected through CLI command?
> New attribute with name {{synchronized-with-live}} should be added to {{/subsystem=messaging-activemq/server=default/ha-policy=replication-slave}}
> This information can be gathered by calling: {{SharedNothingBackupActivation.isRemoteBackupUpToDate()}}
> Additionally we should provide this attribute also in replicated live server in: {{/subsystem=messaging-activemq/server=default/ha-policy=replication-master}} as Administrator might want to know whether live can be shutdown.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-10143) Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10143?page=com.atlassian.jira.plugin... ]
Jeff Mesnil resolved WFLY-10143.
--------------------------------
Fix Version/s: 13.0.0.Beta1
Resolution: Done
The missing javax.json classes are back in jboss-client.jar
> Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10143
> URL: https://issues.jboss.org/browse/WFLY-10143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 13.0.0.Beta1
>
>
> If standalone JMS client is using only jboss-client.jar on classpath then during look up of connection factory fails with:
> {code}
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError: javax/json/JsonValue
> at org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:44)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
> at org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.newLocator(ServerLocatorImpl.java:411)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:209)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:202)
> at org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory.<init>(ActiveMQJMSConnectionFactory.java:34)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructor(SerializableClass.java:340)
> at org.jboss.marshalling.reflect.SerializableClass.callNoArgConstructor(SerializableClass.java:292)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1408)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:243)
> at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
> at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
> at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
> at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.jms.client.ProducerTransAck.run(ProducerTransAck.java:78)
> Caused by: java.lang.ClassNotFoundException: javax.json.JsonValue
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 33 more
> {code}
> This is because javax.json-api jar is missing.
> Wildfly 12 jms-client-bom does not suffer by this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-10143) Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10143?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10143:
------------------------------------
[~mnovak] I confirm that I can reproduce this issue with WildFly 12.0.0.Final but this is fixed in WildFly master branch (commit 0fa3f2a06fbeff769d0f94e6aab5279f78e2cf92)
In WildFly 12.0.0.Final, the jboss-client.jar was not containing the JsonValue class:
{code}
$ jar tvf ~/Developer/wildfly/dist/target/wildfly-12.0.0.Final/bin/client/jboss-client.jar | ack JsonValue
$
{code}
but in master branch, this has been fixed:
{code}
$ jar tvf ~/Developer/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/bin/client/jboss-client.jar | ack JsonValue
...
651 Tue Apr 03 10:22:22 CEST 2018 javax/json/JsonValue.class
{code}
> Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10143
> URL: https://issues.jboss.org/browse/WFLY-10143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> If standalone JMS client is using only jboss-client.jar on classpath then during look up of connection factory fails with:
> {code}
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError: javax/json/JsonValue
> at org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:44)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
> at org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.newLocator(ServerLocatorImpl.java:411)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:209)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:202)
> at org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory.<init>(ActiveMQJMSConnectionFactory.java:34)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructor(SerializableClass.java:340)
> at org.jboss.marshalling.reflect.SerializableClass.callNoArgConstructor(SerializableClass.java:292)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1408)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:243)
> at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
> at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
> at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
> at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.jms.client.ProducerTransAck.run(ProducerTransAck.java:78)
> Caused by: java.lang.ClassNotFoundException: javax.json.JsonValue
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 33 more
> {code}
> This is because javax.json-api jar is missing.
> Wildfly 12 jms-client-bom does not suffer by this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-6412) Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
by Anton Skolznev (JIRA)
[ https://issues.jboss.org/browse/WFLY-6412?page=com.atlassian.jira.plugin.... ]
Anton Skolznev commented on WFLY-6412:
--------------------------------------
I'm facing the same problem on 11.0.0.Final running on Oracle 12c:
2018-04-03 07:14:13,199 ERROR [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0164: Exception running timer task for timer [id=f82cc1e5-544d-4720-8548-52f8d513fa86 timedObjectId=maxoptra.gt-services.PlanFactTimer auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@21529634 initialExpiration=Tue Apr 03 07:07:12 UTC 2018 intervalDuration(in milli sec)=60000 nextExpiration=Tue Apr 03 07:15:12 UTC 2018 timerState=ACTIVE info=null] on EJB maxoptra.gt-services.PlanFactTimer: java.lang.RuntimeException: java.lang.RuntimeException: java.sql.SQLException: ORA-08177: can't serialize access for this transaction
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:615)
at org.jboss.as.ejb3.timerservice.TimerTask.postTimeoutProcessing(TimerTask.java:255)
at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:175)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1220)
at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
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.lang.RuntimeException: java.sql.SQLException: ORA-08177: can't serialize access for this transaction
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.persistTimer(DatabaseTimerPersistence.java:378)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:610)
... 8 more
I have two servers running in cluster. When i set transaction isolation level to READ_COMMITTED instead of TRANSACTION_SERIALIZABLE, i get the following error during the deploy:
2018-04-03 08:48:36,024 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "ejb-timers")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.data-source.ejb-timers" => "WFLYJCA0033: Error during the deployment of ejb-timers
Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}}
2018-04-03 08:48:36,057 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "ejb-timers")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.data-source.ejb-timers" => "WFLYJCA0033: Error during the deployment of ejb-timers
Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYJCA0032: Unable to start the ds because it generated more than one cf"}}
> Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
> ----------------------------------------------------------------------
>
> Key: WFLY-6412
> URL: https://issues.jboss.org/browse/WFLY-6412
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Environment: Linux, JDK8, Oracle DB 11g
> Reporter: Gábor Péntek
> Assignee: Stuart Douglas
> Fix For: 11.0.0.Alpha1
>
>
> If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the
> UPDATE JBOSS_EJB_TIMER..
> the other nodes throw an
> ORA-08177: can't serialize access for this transaction
> exception.
> The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
> The serialization exception is also thrown upon server/application startup sometimes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2423) [DMN Designer] Clear command caches context entries
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2423?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2423:
--------------------------------
Description:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548] (/)
# check scenario from DROOLS-2424 (/)
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2 (/)
-- 3 (/)
was:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
# check scenario from DROOLS-2424 (/)
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2 (/)
-- 3 (/)
> [DMN Designer] Clear command caches context entries
> ---------------------------------------------------
>
> Key: DROOLS-2423
> URL: https://issues.jboss.org/browse/DROOLS-2423
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Attachments: Screenshot from 2018-03-27 11-31-01.png, Screenshot from 2018-03-27 11-31-34.png, Screenshot from 2018-03-27 11-32-52.png
>
>
> This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
> If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
> h2. Acceptance test
> # check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548] (/)
> # check scenario from DROOLS-2424 (/)
> # Steps to reproduce fixed - Clear the context entry at depth:
> -- 0 (/)
> -- 1 (/)
> -- 2 (/)
> -- 3 (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2423) [DMN Designer] Clear command caches context entries
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2423?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2423:
--------------------------------
Description:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
# check scenario from DROOLS-2424 (/)
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2 (/)
-- 3 (/)
was:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
# check scenario from DROOLS-2424
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2 (/)
-- 3 (/)
> [DMN Designer] Clear command caches context entries
> ---------------------------------------------------
>
> Key: DROOLS-2423
> URL: https://issues.jboss.org/browse/DROOLS-2423
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Attachments: Screenshot from 2018-03-27 11-31-01.png, Screenshot from 2018-03-27 11-31-34.png, Screenshot from 2018-03-27 11-32-52.png
>
>
> This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
> If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
> h2. Acceptance test
> # check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
> # check scenario from DROOLS-2424 (/)
> # Steps to reproduce fixed - Clear the context entry at depth:
> -- 0 (/)
> -- 1 (/)
> -- 2 (/)
> -- 3 (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2423) [DMN Designer] Clear command caches context entries
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2423?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2423:
--------------------------------
Description:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
# check scenario from DROOLS-2424
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2 (/)
-- 3 (/)
was:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
# check scenario from DROOLS-2424
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2 (/)
-- 3
> [DMN Designer] Clear command caches context entries
> ---------------------------------------------------
>
> Key: DROOLS-2423
> URL: https://issues.jboss.org/browse/DROOLS-2423
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Attachments: Screenshot from 2018-03-27 11-31-01.png, Screenshot from 2018-03-27 11-31-34.png, Screenshot from 2018-03-27 11-32-52.png
>
>
> This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
> If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
> h2. Acceptance test
> # check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
> # check scenario from DROOLS-2424
> # Steps to reproduce fixed - Clear the context entry at depth:
> -- 0 (/)
> -- 1 (/)
> -- 2 (/)
> -- 3 (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2423) [DMN Designer] Clear command caches context entries
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2423?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2423:
--------------------------------
Description:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
# check scenario from DROOLS-2424
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2 (/)
-- 3
was:
This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
h2. Acceptance test
# check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
# check scenario from DROOLS-2424
# Steps to reproduce fixed - Clear the context entry at depth:
-- 0 (/)
-- 1 (/)
-- 2
-- 3
> [DMN Designer] Clear command caches context entries
> ---------------------------------------------------
>
> Key: DROOLS-2423
> URL: https://issues.jboss.org/browse/DROOLS-2423
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Attachments: Screenshot from 2018-03-27 11-31-01.png, Screenshot from 2018-03-27 11-31-34.png, Screenshot from 2018-03-27 11-32-52.png
>
>
> This issue was spotted during review of DROOLS-2392, however relation is not probable between both.
> If user clears the top level context entry and then select same context entry exactly the same context entry will appear. There should appear context entry with default values.
> h2. Acceptance test
> # check scenario described in [PR comments|https://github.com/kiegroup/kie-wb-common/pull/1548]
> # check scenario from DROOLS-2424
> # Steps to reproduce fixed - Clear the context entry at depth:
> -- 0 (/)
> -- 1 (/)
> -- 2 (/)
> -- 3
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months