[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 single node boxed expression by providing node inputs (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.
Notes:
* Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
* Out of scope: Saving or exporting the "quick test."
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.
*Acceptance criteria*
Users are able to:
* Execute a single node boxed expression by providing node inputs (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.
Notes:
Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
> 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 single node boxed expression by providing node inputs (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.
> Notes:
> * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
> * Out of scope: Saving or exporting the "quick test."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13307) Different behaviour for concurrent StatefulSessionBean invocation
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13307?page=com.atlassian.jira.plugi... ]
Cheng Fang reassigned WFLY-13307:
---------------------------------
Assignee: Paul Ferraro (was: Cheng Fang)
> Different behaviour for concurrent StatefulSessionBean invocation
> -----------------------------------------------------------------
>
> Key: WFLY-13307
> URL: https://issues.redhat.com/browse/WFLY-13307
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.0.0.Final
> Reporter: Cheng Fang
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: clusteredServer_72.log, reproducer.zip, simpleServer_72.log
>
>
> According to the EJB contract a SFSB invocation is exclusive and the same instance can not be used concurrent.
> If done the invocation will wait to get the Lock for this and fail if the request takes too long.
> In case of a simple unclustered profile this is working and the exception is this:
> Exception in thread "main" javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SimpleStatefulBean - could not obtain lock within 5000 MILLISECONDS
> In case of a clustered server environment this is hidden by Infinispan ERROR
> Exception in thread "main" javax.ejb.EJBException: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key InfinispanBeanKey(UUIDSessionID [634883dc-e8a3-452e-ac15-d9a4ad6856e9]) and requestor GlobalTx:t460:7. Lock is held by GlobalTx:t460:6
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 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 single node boxed expression by providing node inputs (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.
Notes:
Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
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.
*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.
> 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 single node boxed expression by providing node inputs (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.
> Notes:
> Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13322) Ability to configure JSF Implementation instead of modifying the system module
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-13322?page=com.atlassian.jira.plugi... ]
Farah Juma commented on WFLY-13322:
-----------------------------------
{quote}
Modifying modules under modules/system/ should not be required as this breaks patching and requires users to keep re applying the configuration or copying jars around when a patch is applied.
The user should be able to create a module with a different JSF implementation and depend on org.jboss.as.jsf-injection or such and it work without having to modify the org.jboss.as.jsf-injection module.
{quote}
[~bmaxwell] Not quite sure what the above means. The procedure for installing a new JSF implementation does not modify the {{org.jboss.as.jsf-injection}} module. The process involves adding a custom module that contains a copy of the JSF injection JAR files from the original module.
> Ability to configure JSF Implementation instead of modifying the system module
> ------------------------------------------------------------------------------
>
> Key: WFLY-13322
> URL: https://issues.redhat.com/browse/WFLY-13322
> Project: WildFly
> Issue Type: Enhancement
> Components: JSF
> Reporter: Brad Maxwell
> Assignee: Farah Juma
> Priority: Major
>
> Modifying modules under modules/system/ should not be required as this breaks patching and requires users to keep re applying the configuration or copying jars around when a patch is applied.
> The user should be able to create a module with a different JSF implementation and depend on org.jboss.as.jsf-injection or such and it work without having to modify the org.jboss.as.jsf-injection module.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-11442) Remove unused dependencies from org.jboss.as.ejb3
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-11442?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana commented on WFLY-11442:
---------------------------------------------
Yes, your right. it is a bit tricky and with some subtleties. I should have discussed the methodology with Ranabir before moving on with this issue and advise about this. We didn't talked about it.
The process I follow is a bit complex, though. I use [https://docs.oracle.com/javase/9/tools/jdeps.htm|jdeps] to find out code dependencies together with a custom Java application that gives me a report based on module names, it is an orientative report, still manual process is needed to verify the uses. I'm not sure if it makes sense to make it available and count on it to find out dependencies, if so, I have to work on it to make it a bit more useful.
The resources root of the affected JBoss module must be reviewed to find out any class loading by using a String or other mechanism, service loader patterns should be also reviewed. In general they should have been covered by the previous step, because a class loading would require at minimum an interface, and if that interface exists, it will be found by jdeps. The implementations could be in a different module. Even though, I think we have to look for those patterns. A general knowledge of the module is also necessary, the component lead should know these details, but sometimes they are so hide that the removal is difficult to perform, even more when the component is big. This step usually is done at PR review.
Having say that, if we are not 100% sure the dependency is no longer used or we do not have a strong reason to remove it with a benefit, the best option is to not remove it.
> Remove unused dependencies from org.jboss.as.ejb3
> -------------------------------------------------
>
> Key: WFLY-11442
> URL: https://issues.redhat.com/browse/WFLY-11442
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Yeray Borges Santana
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Initial analisys checking only first level dependencies from the resource exposed by {{org.jboss.as.ejb3}} shows that these dependencies are being unused:
> * org.jboss.jts
> * org.wildfly.security.elytron-web.undertow-server
> * org.jboss.as.weld
> * org.wildfly.clustering.marshalling.spi
> * org.wildfly.clustering.marshalling.api
> * org.wildfly.client.config
> * org.hibernate
> The task here is verify that they are not used by any other machanism besides of being a first level dependency.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4900) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4900?page=com.atlassian.jira.plug... ]
Darran Lofthouse commented on WFCORE-4900:
------------------------------------------
[~tterem] What is the purpose of this Jira issue? From the comments the component upgrade has already been applied to WildFly Core so the upstream work is complete.
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFCORE-4900
> URL: https://issues.redhat.com/browse/WFCORE-4900
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Farah Juma
> 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)
6 years, 3 months
[JBoss JIRA] (WFCORE-4900) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4900?page=com.atlassian.jira.plug... ]
Darran Lofthouse moved WFLY-13320 to WFCORE-4900:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4900 (was: WFLY-13320)
Component/s: Security
(was: Security)
Affects Version/s: (was: 19.0.0.Final)
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFCORE-4900
> URL: https://issues.redhat.com/browse/WFCORE-4900
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Farah Juma
> 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)
6 years, 3 months