[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes commented on JBJCA-1389:
--------------------------------------
The root cause seems to be that, unlike other code paths, there is no {{checkStatus()}} call prior to the execution of {{mc.getRealConnection()}} in {{getWrappedObject()}}.
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1389:
---------------------------------
Description:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
The NPE obscures the usage issue.
was:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
> The NPE obscures the usage issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1389:
---------------------------------
Description:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed (i.e. returned to the pool, managed connection disassociated) previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
The NPE obscures the usage issue.
was:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
The NPE obscures the usage issue.
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed (i.e. returned to the pool, managed connection disassociated) previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
> The NPE obscures the usage issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1389:
---------------------------------
Description:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
was:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException }} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
Stephen Fikes created JBJCA-1389:
------------------------------------
Summary: NullPointerException raised when calling isWrapperFor(...) on a closed connection
Key: JBJCA-1389
URL: https://issues.jboss.org/browse/JBJCA-1389
Project: IronJacamar
Issue Type: Bug
Components: JDBC
Affects Versions: 1.4.9
Reporter: Stephen Fikes
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException }} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
I have created a proposed fix for the NullPointerException above. The draft is in the following branches:
https://github.com/tadamski/jboss-classfilewriter/tree/WFLY-11566
https://github.com/tadamski/core/tree/WFLY-11566
I'm still having some errors:
{code}
CDIValidationCoreTest.testInputsInvalid
CDIValidationCoreTest.testInputsInvalidNoExecutableValidation
CDIValidationCoreTest.testInputsInvalidNoParameters
{code}
The thing is that I see the same errors on current head without the fix applied.
[~mkopecky][~ron_sigal] Could you please double check that?
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (WFLY-12042) EE Concurrency SetupContextHandle impls do not declare serialVersionUID
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12042:
---------------------------------------
Summary: EE Concurrency SetupContextHandle impls do not declare serialVersionUID
Key: WFLY-12042
URL: https://issues.jboss.org/browse/WFLY-12042
Project: WildFly
Issue Type: Bug
Components: Concurrency Utilities
Affects Versions: 16.0.0.Final
Reporter: Brian Stansberry
Assignee: Eduardo Martins
The org.glassfish.enterprise.concurrent.spi.ContextHandle interface extends Serializable but the various impls in WildFly are not declaring a serialVersionUID.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (DROOLS-3954) Document UX solutions for communicating errors in graphs & grids.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3954?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3954:
--------------------------------------
Description:
Scenario, DMN, and Process modeler share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) To assure consistency while also documenting unique solutions per context.
Current DM context specific "design pattern" document: https://docs.google.com/document/d/1fX9K_fDjEO4_wDLK9EDDb0OtEFir7S6nFH9cn...
was:Scenario, DMN, and Process modeler share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) To assure consistency while also documenting unique solutions per context.
> Document UX solutions for communicating errors in graphs & grids.
> ------------------------------------------------------------------
>
> Key: DROOLS-3954
> URL: https://issues.jboss.org/browse/DROOLS-3954
> Project: Drools
> Issue Type: Story
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Tao Zhu
> Priority: Optional
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
>
> Scenario, DMN, and Process modeler share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) To assure consistency while also documenting unique solutions per context.
> Current DM context specific "design pattern" document: https://docs.google.com/document/d/1fX9K_fDjEO4_wDLK9EDDb0OtEFir7S6nFH9cn...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months