[JBoss JIRA] (WFLY-13925) Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
by r searls (Jira)
[ https://issues.redhat.com/browse/WFLY-13925?page=com.atlassian.jira.plugi... ]
r searls reassigned WFLY-13925:
-------------------------------
Assignee: (was: r searls)
> Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13925
> URL: https://issues.redhat.com/browse/WFLY-13925
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client, REST
> Affects Versions: 21.0.0.Beta1
> Reporter: Martin Stefanko
> Priority: Major
>
> Quoting [~rsearls]:
>
> This appears to be an issue in wfly deployment processing.
> I can confirm when deploying the app that contains resteasy-client-microprofile
> the servlet executed by undertow is io.undertow.servlet.handlers.DefaultServlet.
> When the app does not contain resteasy-client-microprofile the servlet executed
> by undertow is org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher.
> Setting a breakpoint in io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy
> line 300, method start() you will see ServletInfo\{mappings=[], servletClass=class io.undertow.servlet.handlers.DefaultServlet, name='default'}
> when the app contains resteasy-client-microprofile and value
> ServletInfo\{mappings=[/*], servletClass=class org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher, name='io.xstefank.RestApplication'}
> when it does not.
> In wfly I looked at the jaxrs deployment code. I can see that for both
> apps, servletClass is assigned org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
> but when resteasy-client-microprofile is present some wfly process that runs after
> jaxrs overwrites this information with servletClass=class io.undertow.servlet.handlers.DefaultServlet.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 5 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2504:
--------------------------------
Taking me a little longer; I'm taking the opportunity for some refactoring.
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java, delay-ip.sh
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 5 months
[JBoss JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ]
Jan Stourac commented on WFLY-13924:
------------------------------------
Thanks for the mention, Darran. I've put WF21 there.
> HTTP2 is not working with Oracle JDK8 u261
> ------------------------------------------
>
> Key: WFLY-13924
> URL: https://issues.redhat.com/browse/WFLY-13924
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Flavia Rainone
> Priority: Blocker
> Fix For: 21.0.0.Final
>
>
> There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1.
> There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.
> This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726.
> There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed).
> *What is the issue here:*
> This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ]
Jan Stourac updated WFLY-13924:
-------------------------------
Fix Version/s: 21.0.0.Final
> HTTP2 is not working with Oracle JDK8 u261
> ------------------------------------------
>
> Key: WFLY-13924
> URL: https://issues.redhat.com/browse/WFLY-13924
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Flavia Rainone
> Priority: Blocker
> Fix For: 21.0.0.Final
>
>
> There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1.
> There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.
> This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726.
> There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed).
> *What is the issue here:*
> This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFWIP-310) Insufficient validation for WildFlyServer without applicationImage and applicationSource
by Jan Blizňák (Jira)
[ https://issues.redhat.com/browse/WFWIP-310?page=com.atlassian.jira.plugin... ]
Jan Blizňák closed WFWIP-310.
-----------------------------
Resolution: Out of Date
[~jmesnil] FYI I guess we can now close this as EAP7-1337 turned out to take another approach. I am closing this as Out of Date.
> Insufficient validation for WildFlyServer without applicationImage and applicationSource
> ----------------------------------------------------------------------------------------
>
> Key: WFWIP-310
> URL: https://issues.redhat.com/browse/WFWIP-310
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jeff Mesnil
> Priority: Major
>
> Operator phase 2 EAP7-1337 extends WildFlyServer CRD with applicationSource spec.
> According to analysis, one of these _must_ be specifed:
> * applicationImage
> * applicationSource
> However, creating CR without any of these passes, without any validation error or log for end user, but such operator is then useless.
> I am using wildfly-operator image build from latest https://github.com/wildfly/wildfly-operator/pull/132
> {code:java}
> # given you have WildFlyServer CRD already installed on cluster
> cat > demo.yaml << EOF
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: demo-should-fail
> spec:
> replicas: 1
> EOF
> oc create -f demo.yaml
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[JBoss JIRA] (WFLY-11630) JDBC datasource should be granted the connect SocketPermission
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-11630?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-11630:
-----------------------------------
[~istudens] any updates? We are still seeing WildFly CI failures caused by this issue as reported in WFLY-12465.
> JDBC datasource should be granted the connect SocketPermission
> --------------------------------------------------------------
>
> Key: WFLY-11630
> URL: https://issues.redhat.com/browse/WFLY-11630
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Security
> Affects Versions: 16.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Ivo Studensky
> Priority: Major
> Labels: security-manager
> Attachments: DataSourceDefinitionJPATestCase-output-missing_SocketPermission_Connect.txt
>
>
> When a deployment uses connection on a JDBC datasource, the deployment needs the {{connect}} {{SocketPermission}} granted.
> For example
> {noformat}
> ...
> DataSource ds = (DataSource) ctx.lookup("java:jboss/datasources/ExampleDS");
> Connection conn = ds.getConnection();
> ...
> {noformat}
> may require {{permissions.xml}} like
> {noformat}
> <permissions version="7">
> <!-- Connections to databases -->
> <permission>
> <class-name>java.net.SocketPermission</class-name>
> <name>*</name> <!-- This can be hardened by using specific URLs/IPs -->
> <actions>resolve,connect</actions>
> </permission>
> </permissions>
> {noformat}
> However, {{resolve}} {{SocketPermission}} should be enough. The JCA spec states, at the 21.2 session (SecurityPermissions), the rar should always be granted the {{connect}} {{SocketPermission.}} JDBC extends the JCA spec.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months