[JBoss JIRA] (WFLY-12298) Allow to change RESTEasy settings via CLI
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12298?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12298:
---------------------------------
Fix Version/s: 18.0.0.Final
(was: 18.0.0.Beta1)
> 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
> 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] (WFLY-12291) SaslException: Authentication failed when XA Recovery tries to call remote server
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12291?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12291:
---------------------------------
Fix Version/s: 18.0.0.Final
(was: 18.0.0.Beta1)
> SaslException: Authentication failed when XA Recovery tries to call remote server
> ---------------------------------------------------------------------------------
>
> Key: WFLY-12291
> URL: https://issues.jboss.org/browse/WFLY-12291
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Critical
> Fix For: 18.0.0.Final
>
>
> This is caused by how the current AuthenticationContext is captured when wildfly-transaction-client tries to do transaction recovery. It essentially calls ElytronXmlParser.parseAuthenticationClientConfiguration(), which calls org.wildfly.client.config.ClientConfiguration#getInstance(), which only looks for wildfly-config in various locations.
> Also see DefaultAuthenticationContextProvider
> {code}
> 13:30:06,851 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.2.GA (WildFly Core 6.0.14.Final-redhat-00001) started in 3798ms - Started 308 of 528 services (319 services are lazy, passive or on-demand)
> 13:30:46,524 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:201)
> at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:203)
> at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:199)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:622)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:214)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:159)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:444)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:587)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:553)
> at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:82)
> at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:55)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:499)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:445)
> at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:52)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
> ... 8 more
> 13:31:16,537 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:726)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:507)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:258)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12045) Some clustering test cases do not close JNDI InitialContext between tests
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12045?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12045:
---------------------------------
Fix Version/s: 18.0.0.Final
(was: 18.0.0.Beta1)
> Some clustering test cases do not close JNDI InitialContext between tests
> -------------------------------------------------------------------------
>
> Key: WFLY-12045
> URL: https://issues.jboss.org/browse/WFLY-12045
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 17.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 18.0.0.Final
>
>
> The test case RemoteStatelessFailoverTestCase makes use of the helper class EJBRemoteDirectory to lookup JNDI names for beans in test cases. The EJB client then uses the resulting proxies to make invocations on the beans.
> This helper class is defined statically and initialized before any of the test cases run. Consequenty, the InitialContext created by the helper class is used across multiple test cases. The effect of this is that all of the proxies used in the test case are created from the same InitialContext. Consequently, they share a RemoteEJBDiscoveryProvider instance which is a class used to maintain information about server and module deployments which the EJB client references during invocation to find a suitable target for the invocation.
> This means that any server startup or shutdown activities are passed from one test case to another. This is not wanted as crash failures or shutdowns in one test will contaminate the next test, and this is exactly what is happening in a particular failure of this test.
> If your test class only involves one test, then static usage will work, but probably not recommended.
> UPDATE: This problem is present in a few other test cases, so I have updated them.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11943:
---------------------------------
Fix Version/s: 18.0.0.Final
(was: 18.0.0.Beta1)
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
> Labels: affects-model
> Fix For: 18.0.0.Final
>
>
> Provide statistics on REST endpoints in the jaxrs subsystem.
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12429) MockitoException in InfinispanBeanTestCase on latest JDK13
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12429?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12429:
---------------------------------
Fix Version/s: 18.0.0.Final
(was: 18.0.0.Beta1)
> MockitoException in InfinispanBeanTestCase on latest JDK13
> ----------------------------------------------------------
>
> Key: WFLY-12429
> URL: https://issues.jboss.org/browse/WFLY-12429
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Richard Opalka
> Assignee: Paul Ferraro
> Priority: Major
> Labels: jdk13
> Fix For: 18.0.0.Final
>
>
> [INFO] Running org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.929 s <<< FAILURE! - in org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] isExpired(org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase) Time elapsed: 0.027 s <<< ERROR!
> org.mockito.exceptions.base.MockitoException:
> Cannot call abstract real method on java object!
> Calling real methods is only possible when mocking non abstract method.
> //correct example:
> when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase.isExpired(InfinispanBeanTestCase.java:104)
> 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:567)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months