[JBoss JIRA] (WFLY-12298) Allow to change RESTEasy settings via CLI
by Harald Pehl (Jira)
[ https://issues.jboss.org/browse/WFLY-12298?page=com.atlassian.jira.plugin... ]
Harald Pehl updated WFLY-12298:
-------------------------------
Labels: affects-model (was: )
> Allow to change RESTEasy settings via CLI
> -----------------------------------------
>
> Key: WFLY-12298
> URL: https://issues.jboss.org/browse/WFLY-12298
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Marek Kopecky
> Assignee: Ronald Sigal
> Priority: Major
> Labels: affects-model
> Fix For: 18.0.0.Final
>
>
> Many RESTEasy properties can be set in web.xml. CLI should be able to show values of these properties per each deployment by this command:
> {noformat}
> /deployment=${NAME_OF_DEPLOYMENT}/subsystem=jaxrs:read-resource
> {noformat}
> CLI should be able to set values of this properties per each deployment:
> {noformat}
> /deployment=${NAME_OF_DEPLOYMENT}/subsystem=jaxrs:write-attribute(name=resteasy.use.builtin.providers,value=false)
> {noformat}
> CLI should be able to specify values of this attributes globally for all deployments (global settings override deployment settings):
> {noformat}
> /subsystem=jaxrs:write-attribute(name=resteasy.media.type.mappings,value="html : text/html, txt : text/plain")
> {noformat}
> We should consider which properties should be available via CLI.
> ----
> Default providers, interceptors, etc. are set in many javax.ws.rs.ext.Providers files in RESTEasy sources:
> {noformat}
> ./providers/jackson2/src/main/resources/META-INF/services/javax.ws.rs.ext.Providers
> ./providers/yaml/src/main/resources/META-INF/services/javax.ws.rs.ext.Providers
> ./resteasy-jaxrs/src/main/resources/META-INF/services/javax.ws.rs.ext.Providers
> ...
> {noformat}
> CLI shoud allow to add other providers, interceptors, etc., or disable some in global level for all deployments. CLI should allow to add or disable it for specific deployment. Disabling should have higher priority then allowing. Global settings override deployment settings.
> Proposal for CLI attributes (list-add is standard CLI function) - examples:
> {noformat}
> /subsystem=jaxrs:list-add(name=disabled-providers,value=org.jboss.resteasy.plugins.providers.DataSourceProvider)
> /subsystem=jaxrs:list-add(name=allowed-providers,value=org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor)
> /deployment=${NAME_OF_DEPLOYMENT}/subsystem=jaxrs:list-add(name=disabled-providers,value=org.jboss.resteasy.plugins.providers.DataSourceProvider)
> /deployment=${NAME_OF_DEPLOYMENT}/subsystem=jaxrs:list-add(name=allowed-providers,value=org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor)
> {noformat}
> ----
> *Example without this RFE:*
> Let's say that server admin needs to disable DataSourceProvider for all deployments on server. Now, AFAIK, he needs to:
> * set "resteasy.use.builtin.providers" property in web.xml of all deployments to "false"
> ** It disable all default providers.
> * explicitly set providers used in each deployment by "resteasy.providers" property in web.xml of all deployments
> These steps are really uncomfortable, server admin needs to manually update all deployments in server
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (JGRP-2372) LeaveTest fails frequently
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2372?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2372.
----------------------------
Resolution: Done
> LeaveTest fails frequently
> --------------------------
>
> Key: JGRP-2372
> URL: https://issues.jboss.org/browse/JGRP-2372
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.5
>
>
> Ditto for ASYM_ENCRYPT_LeaveTest and ASYM_ENCRYPT_LeaveTestKeyExchange. Multiple members leaving seems to leave some members behind; the view is never correct.
> This happens only when running the entire test suite; running a test individually, or running all encryption tests ({{ant encrypt}}) almost never reproduces the errors.
> This is possibly caused by the high load of running a lot of tests concurrently, and the subsequent delays resulting from it. Nevertheless, these tests should not fail.
> Error message:
> {noformat}
> Timeout 30000 kicked in, views are: 9: [7|15] (4) [7, 8, 9, 10] 10: [7|15] (4) [7, 8, 9, 10]
> java.util.concurrent.TimeoutException
> at org.jgroups.util.Util.waitUntilAllChannelsHaveSameView(Util.java:293)
> at org.jgroups.tests.BaseLeaveTest.testConcurrentLeaves(BaseLeaveTest.java:189)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfFirstNMembers(BaseLeaveTest.java:214)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfCoordAndNext8(BaseLeaveTest.java:146)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:583)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:719)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:989)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (DROOLS-4483) [DMN Designer] Data Types - Create a drag and drop mechanism
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4483?page=com.atlassian.jira.plugi... ]
Guilherme Gomes updated DROOLS-4483:
------------------------------------
Sprint: (was: 2019 Week 35-37)
> [DMN Designer] Data Types - Create a drag and drop mechanism
> -------------------------------------------------------------
>
> Key: DROOLS-4483
> URL: https://issues.jboss.org/browse/DROOLS-4483
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: 2019-08-27 12.16.20.gif, mockup.png, vertical-and-horizontal.png
>
>
> !mockup.png|thumbnail! This JIRA comprehends only the drag and drop mechanism.
> The component must allow horizontal and vertical indentation:
> !vertical-and-horizontal.png|width=600!
> Vertical behaviour: when a row is vertically dragged, it must follow a grid of rows (like this: https://gist.github.com/karreiro/3e5fbf6b363f30eed0268e0a01190096)
> !2019-08-27 12.16.20.gif|width=300!
> Horizontal behaviour: when a row is horizontally dragged, it doesn't follow a grid, but when it's dropped, it must be nested to the element that the horizontal level:
> !mockup.png|width=600!
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12477) CommandDispatcher commands cannot read application jndi namespace
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12477?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12477:
--------------------------------
Description:
A command containing the following code:
{noformat}
public class MyCommand implements Command<Void, Void> {
public Void execute(Void context) throws Exception {
new InitialContext().lookup("java:comp/env/existing-resource");
}
}
{noformat}
currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command.
A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace.
In fact, the following application callbacks from the clustering API are all unable to read from the application's JNDI namespace:
* CommandDispatcher command execution
* CommandDispatcherFactory cluster membership listener
* Cache topology membership listener
* Registry listener
* ServiceProviderRegistry listener
was:
A command containing the following code:
{noformat}
public class MyCommand implements Command<Void, Void> {
public Void execute(Void context) throws Exception {
new InitialContext().lookup("java:comp/env/existing-resource");
}
}
{noformat}
currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command.
A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace.
In fact, the following application callbacks from the clustering API are unable to read from the application's JNDI namespace:
* CommandDispatcher command execution
* CommandDispatcherFactory cluster membership listener
* Cache topology membership listener
* Registry listener
* ServiceProviderRegistry listener
> CommandDispatcher commands cannot read application jndi namespace
> -----------------------------------------------------------------
>
> Key: WFLY-12477
> URL: https://issues.jboss.org/browse/WFLY-12477
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 17.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> A command containing the following code:
> {noformat}
> public class MyCommand implements Command<Void, Void> {
> public Void execute(Void context) throws Exception {
> new InitialContext().lookup("java:comp/env/existing-resource");
> }
> }
> {noformat}
> currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command.
> A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace.
> In fact, the following application callbacks from the clustering API are all unable to read from the application's JNDI namespace:
> * CommandDispatcher command execution
> * CommandDispatcherFactory cluster membership listener
> * Cache topology membership listener
> * Registry listener
> * ServiceProviderRegistry listener
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months