[JBoss JIRA] (WFLY-11406) Reflection exception at org.jboss.classfilewriter.ClassFile on JDK12
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11406?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11406:
-----------------------------------------
Requiring an agent in order to deploy an application is pretty nasty.
We already ship ByteBuddy which is a code generation library that supports JDK 11 and 12. Perhaps it got caught by this same issue, but a quick commit scan shows this which looks like an attempt to work around it:
https://github.com/raphw/byte-buddy/commit/209ae272cb18e201d35bbaa2d38558...
Perhaps MethodHandles.Lookup.defineClass could work for this too but it may not and in any case is only available from JDK 9 on.
> Reflection exception at org.jboss.classfilewriter.ClassFile on JDK12
> --------------------------------------------------------------------
>
> Key: WFLY-11406
> URL: https://issues.jboss.org/browse/WFLY-11406
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Richard Opalka
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: jdk12
> Fix For: 16.0.0.Beta1
>
>
> When running WildFly on JDK12 I'm observing this exception due to Unsafe changes in recent JDK Early Access builds:
> [0m[31m16:47:17,739 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."ws-endpoint-example.war".IN
> <------>at org.jboss.as.server@7.0.0.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> <------>at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> <------>at java.base/java.lang.Thread.run(Thread.java:835)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0024: Could not configure component TestService
> <------>at org.jboss.as.ee@15.0.0.CR1-SNAPSHOT//org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:106)
> <------>at org.jboss.as.server@7.0.0.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
> <------>... 8 more
> Caused by: java.lang.Error: java.lang.NoSuchFieldException: override
> <------>at org.jboss.classfilewriter@1.2.3.Final//org.jboss.classfilewriter.ClassFile$1.run(ClassFile.java:394)
> <------>at org.jboss.classfilewriter@1.2.3.Final//org.jboss.classfilewriter.ClassFile$1.run(ClassFile.java:385)
> <------>at java.base/java.security.AccessController.doPrivileged(AccessController.java:551)
> <------>at org.jboss.classfilewriter(a)1.2.3.Final//org.jboss.classfilewriter.ClassFile.<clinit>(ClassFile.java:385)
> <------>at org.jboss.invocation(a)1.5.1.Final//org.jboss.invocation.proxy.AbstractClassFactory.<init>(AbstractClassFactory.java:97)
> <------>at org.jboss.invocation(a)1.5.1.Final//org.jboss.invocation.proxy.AbstractSubclassFactory.<init>(AbstractSubclassFactory.java:87)
> <------>at org.jboss.invocation(a)1.5.1.Final//org.jboss.invocation.proxy.AbstractProxyFactory.<init>(AbstractProxyFactory.java:69)
> <------>at org.jboss.invocation(a)1.5.1.Final//org.jboss.invocation.proxy.ProxyFactory.<init>(ProxyFactory.java:256)
> <------>at org.jboss.as.ee@15.0.0.CR1-SNAPSHOT//org.jboss.as.ee.component.DefaultComponentViewConfigurator.configure(DefaultComponentViewConfigurator.java:86)
> <------>at org.jboss.as.ee@15.0.0.CR1-SNAPSHOT//org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:92)
> <------>... 9 more
> Caused by: java.lang.NoSuchFieldException: override
> <------>at java.base/java.lang.Class.getDeclaredField(Class.java:2410)
> <------>at org.jboss.classfilewriter@1.2.3.Final//org.jboss.classfilewriter.ClassFile$1.run(ClassFile.java:392)
> <------>... 18 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-3406) [DMN Designer] Decision Service splitter should be movable
by Roger Martínez (Jira)
[ https://issues.jboss.org/browse/DROOLS-3406?page=com.atlassian.jira.plugi... ]
Roger Martínez commented on DROOLS-3406:
----------------------------------------
Hey [~manstis]
Yeah I see - well that's in fact "up to you"... :)
I mean, when we built this initially we tried to split the presenter/handlers and the views, in case at some further point, we decide to change from lienzo to any other third party canvas library... that's something difficult to happen, but as in the rest of the platform, the idea is try to isolate the code, you know...
So in Stunner some of the most used user related events, like click, drag, etc, are being provided by the API, and mostly all of the canvas controls are just relying on those.
This doesn't mean we have to move all lienzo events to Stunner. In fact, probably in your case, it makes no sense to me as well, as it's likely domain specific stuff. So here up to you, but you can for example create a canvas control class, which does not really depends on lienzo, and create a view interface for it. The implementation for the view can be placed on any module that depends on lienzo, and as we use to do, keep a reference to the presenter. This way you can listen for the lienzo events on the view side, and just call the right callback methods on the presenter.
Does that works for you? Anyway feel free to choose your approach considering there is no need to move lienzo events to stunner, for me np!
Thanks!
> [DMN Designer] Decision Service splitter should be movable
> ----------------------------------------------------------
>
> Key: DROOLS-3406
> URL: https://issues.jboss.org/browse/DROOLS-3406
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> The _splitter_ within a Decision Service is static.
> It needs to be movable (vertically) maintaining it's alignment with the Decision Service bounds. At this point we need to either decide to add _result_ decision(s) and _encapsulated_ decisions to the Decision Service by Command (depending on where the node is dropped) or update the Marshaller to determine the type of decision based on its vertical positioning and location of the _splitter_.
> h2. Acceptance test
> Decision state is updated according to _splitter_ movement. Example if area of result decision expanded so some decision belongs there now, this decision should have state _rusult decision_
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-9673) NullPointerException with JDK9 + wildfly-openssl + Http2 utilized
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-9673?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-9673.
------------------------------------
Fix Version/s: 14.0.0.Final
Resolution: Done
Resolving against WF 14.0.0.Final based on input that the problem no longer occurred with JDK 11 and a build of master shortly before that release.
We're not concerned with JDK 9 beyond using it as a way to identify things to correct with the next LTS Java release.
> NullPointerException with JDK9 + wildfly-openssl + Http2 utilized
> -----------------------------------------------------------------
>
> Key: WFLY-9673
> URL: https://issues.jboss.org/browse/WFLY-9673
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Stuart Douglas
> Priority: Major
> Fix For: 14.0.0.Final
>
>
> I can see bunch of NPEs and IllegalStateExceptions when I execute [http2 testsuite|https://github.com/summerwind/h2spec] against running Wildfly server (build from master/62583a78a850ba3fb182dda9b5ed35d99e016960 revision) running with JDK9 and wildfly-openssl (my openssl version is {{OpenSSL 1.1.0g-fips 2 Nov 2017}}):
> {code}
> 2018-01-15 13:15:04,095 ERROR [io.undertow.request.io] (default I/O-16) UT005090: Unexpected failure: java.lang.NullPointerException
> at io.undertow.core//io.undertow.protocols.http2.Http2Channel.sendPing(Http2Channel.java:794)
> at io.undertow.core//io.undertow.protocols.http2.Http2Channel.createChannelImpl(Http2Channel.java:489)
> at io.undertow.core//io.undertow.protocols.http2.Http2Channel.createChannel(Http2Channel.java:342)
> at io.undertow.core//io.undertow.protocols.http2.Http2Channel.createChannel(Http2Channel.java:68)
> at io.undertow.core//io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:451)
> at io.undertow.core//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:109)
> at io.undertow.core//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:60)
> at org.jboss.xnio//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.core//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:921)
> at io.undertow.core//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:902)
> at org.jboss.xnio//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.core//io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1145)
> at io.undertow.core//io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:168)
> at org.jboss.xnio.nio//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.jboss.xnio.nio//org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> 14:32:23,593 ERROR [io.undertow.request] (default task-128) UT005071: Undertow request failed HttpServerExchange{ POST / request {Host=[127.0.0.1:8443]} response {Last-Modified=[Mon, 15 Jan 2018 07:43:34 GMT], X-Powered-By=[Undertow/1], Server=[WildFly/11], Content-Length=[2438], Content-Type=[text/html], Accept-Ranges=[bytes]}}: java.lang.IllegalStateException: UT000127: Response has already been sent
> at io.undertow.core//io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:122)
> at io.undertow.core//io.undertow.server.handlers.resource.PathResource$1ServerTask.run(PathResource.java:184)
> at io.undertow.core//io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:253)
> at io.undertow.core//io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:111)
> at io.undertow.core//io.undertow.server.handlers.resource.ResourceHandler$1.handleRequest(ResourceHandler.java:337)
> at io.undertow.core//io.undertow.server.Connectors.executeRootHandler(Connectors.java:332)
> at io.undertow.core//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {code}
> All exceptions seems to repeat. This causes 16 tests to fail. When I use JDK8 or when I switch back to JSSE ALPN instead of wildfly-openssl, no test fail at all and there are no NPEs in server.log anymore, although the IllegalStateExceptions still remains there.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-9020) Wildfly 10 - JPA Entity deserialization problem on @Transient field
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-9020?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-9020.
------------------------------------
Resolution: Out of Date
> Wildfly 10 - JPA Entity deserialization problem on @Transient field
> -------------------------------------------------------------------
>
> Key: WFLY-9020
> URL: https://issues.jboss.org/browse/WFLY-9020
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 10.0.0.Final
> Environment: Windows 7, Eclipselink 2.6.4 integration, Widlfly 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Priority: Minor
>
> In Wildfly 10,
> We have some system tests that sporadically fail when the client of the application loads an entity, connected to other sub-entities, where one of these sub-entities has a @Transient field.
> In Particular, we have an entity Attributes that has a field of the form:
> {panel}
> @Transient
> private Map<String, String> attributeMap = new TreeMap<String, String>();
> {panel}
> The root cause of the deserialization problem is of the form:
> {panel}
> Caused by: an exception which occurred:
> in object of type java.util.TreeMap
> in field attributeMap
> in object of type basepackage.entity.Attributes
> in field attributes
> in object of type basepackage.entity.SubEntityB
> in element at index [0] of size [1]
> in field delegate
> in object of type org.eclipse.persistence.internal.indirection.jdk8.IndirectList
> in field loadUnits
> in object of type basepackage.entity.ParentEntityA
> {panel}
> The de-serialization execution stack looks as follows:
> {panel}
> Caused by: java.io.OptionalDataException
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:147)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2567)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2583)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2508)
> at java.util.TreeMap.readObject(TreeMap.java:2454)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:776)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:675)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:104)
> {panel}
> We are using the following cliean library:
> {panel}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-client-all</artifactId>
> <version>10.0.0.Final</version>
> <scope>test</scope>
> <optional>true</optional>
> <exclusions>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-commons</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-core-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-jms-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-hqclient-protocol</artifactId>
> </exclusion>
> <exclusion>
> <groupId> org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {panel}
> Currently no sample application exists to reproduce the issue.
> On weblogic the deserialization process goes without incident.
> Could the @Transient annotation and the eventual (empty map vs popuated attribtues map) play a role on this issue?
> Kindest regards.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-11535) Cluster fails to merge if instances started simultaneously
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11535?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-11535:
---------------------------------------
Component/s: Clustering
Assignee: Paul Ferraro (was: Jason Greene)
> Cluster fails to merge if instances started simultaneously
> ----------------------------------------------------------
>
> Key: WFLY-11535
> URL: https://issues.jboss.org/browse/WFLY-11535
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.Final
> Environment: Keycloak 4.6.0 official docker image, AWS ECS cluster
> Reporter: Ian Rodgers
> Assignee: Paul Ferraro
> Priority: Major
>
> Our Keycloak docker cluster has four instances, clustered using Jgroups/Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members).
> We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of a single cluster which subsequent instances join.
> This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away, Unfortunately we need 4.6.0 for an important fix.
> On 4.5.0 we get the message "Received new, MERGED cluster view for channel ejb: MergeView::" when it detects a number of subgroups to merge. This never appears in 4.6.0.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-3446) Data type constraints: Basic interaction/workflow
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3446?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-3446:
--------------------------------
Description:
Background
Persona: Business analyst or Rules practitioner
Use Cases:
* From the DMN canvas view:
As a user, I want to be able to set data type constraints for an input value in a Decision Table, so that this constraint is valid _*only*_ in the context of this specific input in this Decision Table.
* From the Data Types tab:
As a user I want the ability to define constraints for data type definitions in use within the DMN file.
Functional considerations/ pre conditions:
* Consider interaction in light of Property panel and consistency.
* Underscore the notion of one-off constraints.
Verification conditions:
* Scrum team and PO review.
was:
Background
Persona: Business analyst or Rules practitioner
Use Cases:
* From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
* From the Data Types tab - as a user I want the ability to define constraints for data type definitions in use in my file.
Functional considerations/ pre conditions:
* Consider interaction in light of Property panel and consistency.
* Underscore the notion of one-off constraints.
Verification conditions:
* Scrum team and PO review.
> Data type constraints: Basic interaction/workflow
> -------------------------------------------------
>
> Key: DROOLS-3446
> URL: https://issues.jboss.org/browse/DROOLS-3446
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
>
> Background
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view:
> As a user, I want to be able to set data type constraints for an input value in a Decision Table, so that this constraint is valid _*only*_ in the context of this specific input in this Decision Table.
> * From the Data Types tab:
> As a user I want the ability to define constraints for data type definitions in use within the DMN file.
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months