[JBoss JIRA] (WFLY-13320) Wildfly-openssl can not load library wfssl on RHEL6
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFLY-13320?page=com.atlassian.jira.plugi... ]
Jan Stourac updated WFLY-13320:
-------------------------------
Fix Version/s: (was: 19.0.0.Final)
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFLY-13320
> URL: https://issues.redhat.com/browse/WFLY-13320
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Final
> Reporter: Tomas Terem
> Assignee: Flavia Rainone
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> 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:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13321) Update references to WildFlyElytronProvider in the Elytron documentation
by Farah Juma (Jira)
Farah Juma created WFLY-13321:
---------------------------------
Summary: Update references to WildFlyElytronProvider in the Elytron documentation
Key: WFLY-13321
URL: https://issues.redhat.com/browse/WFLY-13321
Project: WildFly
Issue Type: Task
Components: Documentation, Security
Reporter: Farah Juma
When Elytron was converted to a multi-module project, [WildFlyElytronProvider|https://wildfly-security.github.io/wildfly-elytron/master/org/wildfly/security/WildFlyElytronProvider.html] was deprecated and provider implementations were added for the individual modules (e.g., [WildFlyElytronPasswordProvider|https://wildfly-security.github.io/wildfly-elytron/1.11.x/api-javadoc/org/wildfly/security/password/WildFlyElytronPasswordProvider.html], [WildFlyElytronCredentialStoreProvider|https://wildfly-security.github.io/wildfly-elytron/1.11.x/api-javadoc/org/wildfly/security/credential/store/WildFlyElytronCredentialStoreProvider.html], etc.). However, the [Elytron security guide|https://docs.wildfly.org/19/WildFly_Elytron_Security.html] still references the deprecated {{WildFlyElytronProvider}} class instead of referencing the new provider implementations. This should be updated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13304) JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13304?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13304:
------------------------------------
Workaround Description: Define the auth-method within a web.xml deployment descriptor, the web.xml takes priority over the annotation so the code triggering the NPE will be skipped if already defined in the web.xml.
Workaround: Workaround Exists
> JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
> -------------------------------------------------------------------------
>
> Key: WFLY-13304
> URL: https://issues.redhat.com/browse/WFLY-13304
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Affects Versions: 19.0.0.Final
> Reporter: Michael Edgar
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 19.0.1.Final, 20.0.0.Beta1
>
>
> When starting a Microprofile application utilizing the {{org.eclipse.microprofile.auth.LoginConfig}} annotation, a {{NullPointerException}} is thrown if the annotation does not declare the {{realmName}} property.
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) {} MSC000001: Failed to start service jboss.deployment.unit."example.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."example.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "example.war"
> at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.microprofile.jwt-smallrye@19.0.0.Final//org.wildfly.extension.microprofile.jwt.smallrye.JwtActivationProcessor.deploy(JwtActivationProcessor.java:80)
> at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13320) Wildfly-openssl can not load library wfssl on RHEL6
by Tomas Terem (Jira)
Tomas Terem created WFLY-13320:
----------------------------------
Summary: Wildfly-openssl can not load library wfssl on RHEL6
Key: WFLY-13320
URL: https://issues.redhat.com/browse/WFLY-13320
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 19.0.0.Final
Reporter: Tomas Terem
Assignee: Flavia Rainone
Fix For: 19.0.0.Final
Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
{code:java}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
at java.security.Provider$Service.newInstance(Provider.java:1617)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
... 8 more
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.wildfly.openssl.SSL.init(SSL.java:87)
at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
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:423)
at java.security.Provider$Service.newInstance(Provider.java:1595)
... 12 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.wildfly.openssl.SSL.init(SSL.java:82)
... 19 more
Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
at java.lang.Runtime.loadLibrary0(Runtime.java:871)
at java.lang.System.loadLibrary(System.java:1124)
at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
... 24 more
{code}
The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13304) JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13304?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13304:
------------------------------------
Fix Version/s: 19.0.1.Final
> JwtActivationProcessor throws NPE when LoginConfig#realmName not declared
> -------------------------------------------------------------------------
>
> Key: WFLY-13304
> URL: https://issues.redhat.com/browse/WFLY-13304
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Affects Versions: 19.0.0.Final
> Reporter: Michael Edgar
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 19.0.1.Final, 20.0.0.Beta1
>
>
> When starting a Microprofile application utilizing the {{org.eclipse.microprofile.auth.LoginConfig}} annotation, a {{NullPointerException}} is thrown if the annotation does not declare the {{realmName}} property.
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) {} MSC000001: Failed to start service jboss.deployment.unit."example.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."example.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "example.war"
> at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.microprofile.jwt-smallrye@19.0.0.Final//org.wildfly.extension.microprofile.jwt.smallrye.JwtActivationProcessor.deploy(JwtActivationProcessor.java:80)
> at org.jboss.as.server@11.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13293) When deploying "ROOT.war" in EAP7.x, the context root value output through jboss-cli is not valid
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFLY-13293?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero commented on WFLY-13293:
------------------------------------------------
[~flavia.rainone] [~brian.stansberry] I have worked on the second option, check this:
https://github.com/wildfly/wildfly/compare/master...rmartinc:WFLY-13161-n...
When you have time, take a look and let me know if this makes sense or I'm just going nuts (the alias is just commented out for the moment, but you can see the idea, it's not definitive yet).
> When deploying "ROOT.war" in EAP7.x, the context root value output through jboss-cli is not valid
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-13293
> URL: https://issues.redhat.com/browse/WFLY-13293
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Final
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> *When deploying "ROOT.war" default context-root is "/" even though i set a specific context-root in jboss-web.xml. However, If I check resources by jboss-cli, it seems like context-root value refers to jboss-web.xml and this value is invalid.*
> ROOT.war/WEB-INF/jboss-web.xml
> {code}
> <jboss-web version="7.0"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-web_7_0.xsd">
> <context-root>/hello</context-root>
> </jboss-web>{code}
> {code}[standalone@192.168.122.1:10090 /] deployment-info
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> ROOT.war ROOT.war true true OK
> {code}
> server.log
> {code}
> 2020-03-24 10:35:56,344 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/' for server 'default-server'
> 2020-03-24 10:35:56,354 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "ROOT.war" (runtime-name : "ROOT.war")
> {code}
> However, If I check resource by jboss-cli, it seems like context-root value refers to jboss-web.xml and this vaule is invalid.
> {code}
> [standalone@192.168.122.1:10090 /] /deployment=ROOT.war/subsystem=undertow:read-resource(include-runtime=true)
> {
> "outcome" => "success",
> "result" => {
> "active-sessions" => 0,
> "context-root" => "/hello", => this is invalid, the real value is "/"
> "expired-sessions" => 0,
> "highest-session-count" => 0,
> "max-active-sessions" => -1,
> "rejected-sessions" => 0,
> "server" => "default-server",
> "session-avg-alive-time" => 0,
> "session-max-alive-time" => 0,
> "sessions-created" => 0,
> "virtual-host" => "default-host",
> "servlet" => undefined,
> "websocket" => undefined
> }
> }
> {code}
> valid context-root is "/"
> {code}
> [hyoskim@hyoskim sophia]$ curl -v http://192.168.122.1:8180/test.jsp
> * About to connect() to 192.168.122.1 port 8180 (#0)
> * Trying 192.168.122.1...
> * Connected to 192.168.122.1 (192.168.122.1) port 8180 (#0)
> > GET /test.jsp HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: 192.168.122.1:8180
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Connection: keep-alive
> < X-Powered-By: JSP/2.3
> < Set-Cookie: JSESSIONID=_Ej56uTEuy1B0U2Oi94pcVtCNwg7ngRNr7HO7TQ7.worker1; path=/
> < Content-Type: text/html;charset=ISO-8859-1
> < Content-Length: 6
> < Date: Tue, 24 Mar 2020 01:37:53 GMT
> <
> hello
> [hyoskim@hyoskim sophia]$ curl -v http://192.168.122.1:8180/hello/test.jsp
> * About to connect() to 192.168.122.1 port 8180 (#0)
> * Trying 192.168.122.1...
> * Connected to 192.168.122.1 (192.168.122.1) port 8180 (#0)
> > GET /hello/test.jsp HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: 192.168.122.1:8180
> > Accept: */*
> >
> < HTTP/1.1 404 Not Found
> < Connection: keep-alive
> < Content-Type: text/html;charset=UTF-8
> < Content-Length: 74
> < Date: Tue, 24 Mar 2020 01:37:23 GMT
> <
> * Connection #0 to host 192.168.122.1 left intact
> <html><head><title>Error</title></head><body>/hello/test.jsp</body></html>{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool
by Elizabeth Clayton (Jira)
[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ]
Elizabeth Clayton updated DROOLS-4746:
--------------------------------------
Description:
As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
When the user run the test he can get back the results of the DMN execution.
Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
*Acceptance criteria*
Users are able to:
* Execute a Scenario test for a single test scenario against a single DMN decision (node) from directly within the DMN editor.
* Explore the DMN model and provide inputs necessary to run a scenario test.
* Obtain results (Expected) within the DMN editor once the test is run.
* Understand that the inline "quick test" does not persist unless they explicitly Save the test to a new or existing Test Scenario.
* Save the "quick test" to a new or existing Test Scenario.
was:
As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
When the user run the test he can get back the results of the DMN execution.
Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
> UX for DMN "quick test" tool
> ----------------------------
>
> Key: DROOLS-4746
> URL: https://issues.redhat.com/browse/DROOLS-4746
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
>
> As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
> When the user run the test he can get back the results of the DMN execution.
> Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
> *Acceptance criteria*
> Users are able to:
> * Execute a Scenario test for a single test scenario against a single DMN decision (node) from directly within the DMN editor.
> * Explore the DMN model and provide inputs necessary to run a scenario test.
> * Obtain results (Expected) within the DMN editor once the test is run.
> * Understand that the inline "quick test" does not persist unless they explicitly Save the test to a new or existing Test Scenario.
> * Save the "quick test" to a new or existing Test Scenario.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (AG-137) Fix shared connection warning
by Luis Barreiro (Jira)
Luis Barreiro created AG-137:
--------------------------------
Summary: Fix shared connection warning
Key: AG-137
URL: https://issues.redhat.com/browse/AG-137
Project: Agroal
Issue Type: Bug
Components: pool
Affects Versions: 1.7
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 1.8
There is an incorrect warning of a connection shared by the same thread.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months