[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Liz Clayton (Jira)
Liz Clayton created DROOLS-3731:
-----------------------------------
Summary: DMN UX - More info overlaid on models.
Key: DROOLS-3731
URL: https://issues.jboss.org/browse/DROOLS-3731
Project: Drools
Issue Type: Story
Components: DMN Editor
Reporter: Liz Clayton
Assignee: Liz Clayton
As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11811) Default transaction timeout coud be wrongly configured because of the TM initiation race condition
by Ondra Chaloupka (Jira)
Ondra Chaloupka created WFLY-11811:
--------------------------------------
Summary: Default transaction timeout coud be wrongly configured because of the TM initiation race condition
Key: WFLY-11811
URL: https://issues.jboss.org/browse/WFLY-11811
Project: WildFly
Issue Type: Bug
Components: Transactions
Affects Versions: 16.0.0.Final
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
Transaction default timeout could be wrongly set up because of race condition in configuration of the {{CoordinatorEnvironmentBean}} and the {{TxControl}} class which is used on transaction begin and loads data from the coordinator bean to static variable.
The default transaction timeout defined by Narayana is 60 seconds. It's coded in source at https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...
The {{CoordinatorEnvironmentBean}} is instantiated with the default value or with value taken from system property or xml descriptor (https://jbossts.blogspot.com/2018/01/narayana-periodic-recovery-of-xa.htm...).
When new transaction is started it does not use directly the {{CoordinatorEnvironmentBean#getDefaultTimeout()}} but the {{TxControl#getDefaultTimeout()}} (https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaCore/arjuna/cl...).
>From the [~stephen.fikes] testing with Byteman[1] when there is used the environment property {{-Dcom.arjuna.ats.arjuna.coordinator.defaultTimeout=301}} (should not be used for WFLY) and WFLY model configuration {{<coordinator-environment default-timeout="302"/>}} we can see the {{CoordinatorEnvironmentBean.setDefaultTimeout}} is called twice. First time it's time of the bean initialization and the value of 301 is taken ({{BeanPopulator}} instantiates the bean and reset the default value of {{60}} to {{301}}. Next the ArjunaTransactionManagerService is started and set the value to 302 as model defines https://github.com/wildfly/wildfly/blob/16.0.0.Final/transactions/src/mai....
Unfortunately, there is no changes for the {{TxControl}} class which is used during transaction startup. If the {{TxControl}} would be initialized before the {{ArjunaTransactionService}} is started then the value defined in the WFLY model would not be considered until a change in the CLI ({{/subsystem=transactions:write-attribute(name=default-timeout, value=100)}}) is done. The cli command causes the {{TxControl}} is reset - https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
We should ensure the {{TxControl._defaultTimeout}} value is configured during {{ArjunaTransactionManagerService}} start up as well.
[1]
{code}
INFO [stdout] (MSC service thread 1-2) [BMAN]
CoordinatorEnvironmentBean.setDefaultTimeout(301)
com.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.setDefaultTimeout(CoordinatorEnvironmentBean.java:-1)
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
com.arjuna.common.internal.util.propertyservice.BeanPopulator.handleSimpleProperty(BeanPopulator.java:312)
com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:172)
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87)
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
com.arjuna.ats.arjuna.coordinator.BasicAction.<clinit>(BasicAction.java:3754)
com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.<clinit>(CommitMarkableResourceRecordRecoveryModule.java:79)
java.lang.Class.forName0(Class.java:-2)
java.lang.Class.forName(Class.java:264)
com.arjuna.common.internal.util.ClassloadingUtility.loadClass(ClassloadingUtility.java:57)
com.arjuna.common.internal.util.ClassloadingUtility.loadClass(ClassloadingUtility.java:85)
com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:117)
com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:192)
com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:465)
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:883)
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121)
com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:107)
com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:477)
com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:132)
com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:112)
com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54)
org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:126)
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:748)
INFO [stdout] (MSC service thread 1-2) [BMAN]
CoordinatorEnvironmentBean.setDefaultTimeout(302)
com.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.setDefaultTimeout(CoordinatorEnvironmentBean.java:-1)
org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:88)
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11565) WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204
by Soumya Khedagi (Jira)
[ https://issues.jboss.org/browse/WFLY-11565?page=com.atlassian.jira.plugin... ]
Soumya Khedagi commented on WFLY-11565:
---------------------------------------
Hi [~baranowb], gentle reminder. Please let me know if you need more info from us.
> WildFly Server Adds Transfer Encoding Chunk Header to the HttpResponse with status code 204
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11565
> URL: https://issues.jboss.org/browse/WFLY-11565
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Final
> Reporter: Deepak Sahu
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: API.war
>
>
> I am using WildFly Server 9.0.0 Final, Javax ws, Jersey for developing Rest APIs. For all the responses whose httpStatus code is 204, the wildfly server adds Transfer encoding Chunked in the response header, which is not correct as per the Rest Standards. Because of this behavior some of the RestAPI clients hang, as they keep waiting for the response (which is not at all there).
> To verify the issue, I tried the same with Springboot instead of deploying the war in WildFly and the Response Header was not added with Transfer Encoding Chuncked.
> Let me know if some other information is required to fix this issue, if this is already fixed is there any patch for this issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-4621) RESTEasy SMIME doesn't work with WildFly current module setup
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-4621?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-4621:
---------------------------------
[~mkopecky], what should I set as the Fix Value?
It looks like the problem was solved in RESTEasy 3.0.12.Final. Wildfly 9.0.2.Final shipped with RESTEasy 3.0.11.Final, and Wildfly 10.0.0.Final shipped with 3.0.14.Final, so I think I should use 10.0.0.Final as the Fix Version. But will that cause any problems?
-Ron
> RESTEasy SMIME doesn't work with WildFly current module setup
> -------------------------------------------------------------
>
> Key: WFLY-4621
> URL: https://issues.jboss.org/browse/WFLY-4621
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 9.0.0.CR1
> Reporter: Weinan Li
> Assignee: Weinan Li
> Priority: Major
> Attachments: patch_WFLY-4621_all, patch_WFLY-4621_new
>
>
> RESTEasy provides the functions of SMIME encryption and here is an example that can be deployed into WildFly:
> https://github.com/liweinan/digital-signatures/tree/master/smime
> And currently resteasy-crypto module doesn't work properly in WildFly unless applied the following patch:
> {code:diff}
> power:modules weinanli$ git diff
> warning: LF will be replaced by CRLF in system/layers/base/org/bouncycastle/main/module.xml.
> The file will have its original line endings in your working directory.
> diff --git a/system/layers/base/org/bouncycastle/main/module.xml b/system/layers/base/org/bouncycastle/main/module.xml
> index 5d13395..83ae97c 100644
> --- a/system/layers/base/org/bouncycastle/main/module.xml
> +++ b/system/layers/base/org/bouncycastle/main/module.xml
> @@ -24,12 +24,17 @@
> <module xmlns="urn:jboss:module:1.3" name="org.bouncycastle">
> <resources>
> + <!--
> <resource-root path="bcprov-jdk15on-1.52.jar"/>
> <resource-root path="bcmail-jdk15on-1.52.jar"/>
> + -->
> + <resource-root path="bcprov-jdk16-1.46.jar"/>
> + <resource-root path="bcmail-jdk16-1.46.jar"/>
> <resource-root path="bcpkix-jdk15on-1.52.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> + <module name="javax.mail.api"/>
> + <module name="javax.activation.api"/>
> </dependencies>
> -
> </module>
> {code}
> After applying the above patch then the example can pass all the tests:
> {code}
> power:smime weinanli$ mvn -q clean package
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> power:smime weinanli$ mvn -q wildfly:deploy
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> May 11, 2015 9:24:27 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.7.Final
> power:smime weinanli$ mvn -q integration-test
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.resteasy.tests.smime.SMIMETest
> Encrypted Message From Server:
> Customer{name='Bill'}
> Signed Message From Server:
> Customer{name='Bill'}
> Customer{name='Bill'}
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.682 sec - in org.jboss.resteasy.tests.smime.SMIMETest
> Results :
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
> power:smime weinanli$
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-4621) RESTEasy SMIME doesn't work with WildFly current module setup
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-4621?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-4621:
---------------------------------
[~mkopecky], it looks like this issue just fell through the cracks. That was before we had your eagle eyes on the job. ;-)
> RESTEasy SMIME doesn't work with WildFly current module setup
> -------------------------------------------------------------
>
> Key: WFLY-4621
> URL: https://issues.jboss.org/browse/WFLY-4621
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 9.0.0.CR1
> Reporter: Weinan Li
> Assignee: Weinan Li
> Priority: Major
> Attachments: patch_WFLY-4621_all, patch_WFLY-4621_new
>
>
> RESTEasy provides the functions of SMIME encryption and here is an example that can be deployed into WildFly:
> https://github.com/liweinan/digital-signatures/tree/master/smime
> And currently resteasy-crypto module doesn't work properly in WildFly unless applied the following patch:
> {code:diff}
> power:modules weinanli$ git diff
> warning: LF will be replaced by CRLF in system/layers/base/org/bouncycastle/main/module.xml.
> The file will have its original line endings in your working directory.
> diff --git a/system/layers/base/org/bouncycastle/main/module.xml b/system/layers/base/org/bouncycastle/main/module.xml
> index 5d13395..83ae97c 100644
> --- a/system/layers/base/org/bouncycastle/main/module.xml
> +++ b/system/layers/base/org/bouncycastle/main/module.xml
> @@ -24,12 +24,17 @@
> <module xmlns="urn:jboss:module:1.3" name="org.bouncycastle">
> <resources>
> + <!--
> <resource-root path="bcprov-jdk15on-1.52.jar"/>
> <resource-root path="bcmail-jdk15on-1.52.jar"/>
> + -->
> + <resource-root path="bcprov-jdk16-1.46.jar"/>
> + <resource-root path="bcmail-jdk16-1.46.jar"/>
> <resource-root path="bcpkix-jdk15on-1.52.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> + <module name="javax.mail.api"/>
> + <module name="javax.activation.api"/>
> </dependencies>
> -
> </module>
> {code}
> After applying the above patch then the example can pass all the tests:
> {code}
> power:smime weinanli$ mvn -q clean package
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> power:smime weinanli$ mvn -q wildfly:deploy
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> May 11, 2015 9:24:27 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.0.Final
> May 11, 2015 9:24:27 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.7.Final
> power:smime weinanli$ mvn -q integration-test
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.resteasy.tests.smime.SMIMETest
> Encrypted Message From Server:
> Customer{name='Bill'}
> Signed Message From Server:
> Customer{name='Bill'}
> Customer{name='Bill'}
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.682 sec - in org.jboss.resteasy.tests.smime.SMIMETest
> Results :
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
> power:smime weinanli$
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-2752) Using an injected UriInfo object by the JAX-RS runtime environment does not work
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-2752?page=com.atlassian.jira.plugin.... ]
Ron Sigal resolved WFLY-2752.
-----------------------------
Resolution: Out of Date
> Using an injected UriInfo object by the JAX-RS runtime environment does not work
> --------------------------------------------------------------------------------
>
> Key: WFLY-2752
> URL: https://issues.jboss.org/browse/WFLY-2752
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 8.0.0.CR1
> Reporter: Stan Zelivinski
> Assignee: Ron Sigal
> Priority: Major
>
> The code that works perfectly in WildFly.8.0.0.Beta:
> {code:java}
> package jdsu.vts.tcpcontroller.webservices.rest.resources;
> import java.net.URI;
> import javax.ws.rs.DELETE;
> import javax.ws.rs.GET;
> import javax.ws.rs.PUT;
> import javax.ws.rs.Path;
> import javax.ws.rs.PathParam;
> import javax.ws.rs.Produces;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.core.Context;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.core.UriInfo;
> import jdsu.vts.tcpcontroller.webservices.rest.application.V1_TCPController;
> import jdsu.vts.shared.transferobjects.V1_TCPSetups;
> @Path("/v1")
> public class V1_TCPControllerResource {
> @Context UriInfo uriInfo;
>
> @GET
> @Produces("application/json")
> public Response getControllers() {
> //String json = String.valueOf(m_testsMap.size());
> return Response.ok(V1_TCPController.getCollection()).build();
> }
>
> @PUT
> @Path("{id}")
> @Produces("application/json")
> public Response addController(@PathParam("id") String id) {
> V1_TCPController controller = V1_TCPController.find(id);
> if(controller != null) {
> return Response.status(Response.Status.CONFLICT).build();
> }
> controller = new V1_TCPController(id);
> URI uri = uriInfo.getAbsolutePathBuilder().path(id).build();
> return Response.created(uri).build();
> }
> }
> {code}
> does not work in WildFly.8.0.0.CR1. uriInfo is null in the call.
> Please help.
> Stan
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-2752) Using an injected UriInfo object by the JAX-RS runtime environment does not work
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-2752?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-2752:
---------------------------------
[~stanzelivinski], we are not currently able to reproduce this problem, so I am closing the issue as out-of-date. You can re-open it if you still have trouble.
> Using an injected UriInfo object by the JAX-RS runtime environment does not work
> --------------------------------------------------------------------------------
>
> Key: WFLY-2752
> URL: https://issues.jboss.org/browse/WFLY-2752
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 8.0.0.CR1
> Reporter: Stan Zelivinski
> Assignee: Ron Sigal
> Priority: Major
>
> The code that works perfectly in WildFly.8.0.0.Beta:
> {code:java}
> package jdsu.vts.tcpcontroller.webservices.rest.resources;
> import java.net.URI;
> import javax.ws.rs.DELETE;
> import javax.ws.rs.GET;
> import javax.ws.rs.PUT;
> import javax.ws.rs.Path;
> import javax.ws.rs.PathParam;
> import javax.ws.rs.Produces;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.core.Context;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.core.UriInfo;
> import jdsu.vts.tcpcontroller.webservices.rest.application.V1_TCPController;
> import jdsu.vts.shared.transferobjects.V1_TCPSetups;
> @Path("/v1")
> public class V1_TCPControllerResource {
> @Context UriInfo uriInfo;
>
> @GET
> @Produces("application/json")
> public Response getControllers() {
> //String json = String.valueOf(m_testsMap.size());
> return Response.ok(V1_TCPController.getCollection()).build();
> }
>
> @PUT
> @Path("{id}")
> @Produces("application/json")
> public Response addController(@PathParam("id") String id) {
> V1_TCPController controller = V1_TCPController.find(id);
> if(controller != null) {
> return Response.status(Response.Status.CONFLICT).build();
> }
> controller = new V1_TCPController(id);
> URI uri = uriInfo.getAbsolutePathBuilder().path(id).build();
> return Response.created(uri).build();
> }
> }
> {code}
> does not work in WildFly.8.0.0.CR1. uriInfo is null in the call.
> Please help.
> Stan
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months