October 2020 - jboss-jira - Jboss List Archives

[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)

5 years, 7 months

1
0
0 / 0

[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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-13897: --------------------------------------- If authentication worked, the subsequent problem is ISPN-12374 which is that the JVM never quits due to a hanging thread. > infinispan-server instances provisioned by testsuite never shutdown > ------------------------------------------------------------------- > > Key: WFLY-13897 > URL: https://issues.redhat.com/browse/WFLY-13897 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 21.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > > Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5685) ClearActivationGroup command changed its behaviour

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5685?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5685: ----------------------------------- Story Points: 3 Sprint: 2020 Week 40-42 (from Sep 28) > ClearActivationGroup command changed its behaviour > -------------------------------------------------- > > Key: DROOLS-5685 > URL: https://issues.redhat.com/browse/DROOLS-5685 > Project: Drools > Issue Type: Bug > Components: core engine, kie server > Affects Versions: 7.44.0.Final > Reporter: Karel Suta > Assignee: Matteo Mortari > Priority: Major > Labels: regression > > ClearActivationGroupCommand command in Kie server changed its behaviour, right now it doesn't seem to remove the activation group. This issue is caused by https://github.com/kiegroup/drools/pull/3125 , when I revert the commit then ClearActivationGroupCommand works again as before. > Can be reproduced using Kie server integration test [ActivationGroupIntegrationTest.testClearActivationGroup()|https://github....]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[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"> >  > <permission> > <class-name>java.net.SocketPermission</class-name> > <name>*</name>  > <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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13926) Upgrade Hibernate ORM from 5.3.18 to 5.3.19

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13926?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-13926: --------------------------------- Labels: downstream_dependency (was: ) > Upgrade Hibernate ORM from 5.3.18 to 5.3.19 > ------------------------------------------- > > Key: WFLY-13926 > URL: https://issues.redhat.com/browse/WFLY-13926 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13926) Upgrade Hibernate ORM from 5.3.18 to 5.3.19

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13926?page=com.atlassian.jira.plugi... ] Ilia Vassilev moved JBEAP-20287 to WFLY-13926: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13926 (was: JBEAP-20287) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System (was: Build System) Affects Version/s: (was: 7.3.4.GA) > Upgrade Hibernate ORM from 5.3.18 to 5.3.19 > ------------------------------------------- > > Key: WFLY-13926 > URL: https://issues.redhat.com/browse/WFLY-13926 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5072) DMN wire DT static analysis to kie-maven-plugin

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5072?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5072: ----------------------------------- Summary: DMN wire DT static analysis to kie-maven-plugin (was: DMN investigate wire DT static analysis to kie-maven-plugin) > DMN wire DT static analysis to kie-maven-plugin > ----------------------------------------------- > > Key: DROOLS-5072 > URL: https://issues.redhat.com/browse/DROOLS-5072 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > followup [DROOLS-5020] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13925) Deployment with the `resteasy-client-microprofile` dependency causes JAX-RS endpoints to not be exposed

by Martin Stefanko (Jira)

Martin Stefanko created WFLY-13925: -------------------------------------- Summary: 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 Assignee: r searls 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)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13924: ------------------------------------ Component/s: Security > 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 > > 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)

5 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020