March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11915) Test for WFLY-11866

by Teresa Miyar Gil (Jira)

Teresa Miyar Gil created WFLY-11915: --------------------------------------- Summary: Test for WFLY-11866 Key: WFLY-11915 URL: https://issues.jboss.org/browse/WFLY-11915 Project: WildFly Issue Type: Task Components: EJB Reporter: Teresa Miyar Gil Assignee: Teresa Miyar Gil Fix For: 17.0.0.Beta1 A test case for passing a remote EJB Exception by reference. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Sebastian Laskawiec (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec updated WFLY-11007: --------------------------------------- Steps to Reproduce: - Start OpenShift local cluster - {{oc cluster up}} - Download the template - {{wget https://gist.githubusercontent.com/slaskawi/57ed810a7109a02a9d884b61ce2e7... - Create an app - {{oc new-app -f keycloak.json}} - Locate the IP of the server - {{oc get pods -o wide}} - Use curl on HTTPs port - {{curl -vk https://172.17.0.4:8443/auth}} was: - Start OpenShift local cluster - {{oc cluster up}} - Download the template - {{wget https://gist.githubusercontent.com/slaskawi/57ed810a7109a02a9d884b61ce2e7... - Create an app - {{oc new-app -f keycloak.json}} - Locate the IP of the server - {{oc get pods -o wide}} - Use curl on HTTPs port > Using OpenShift generated certificates and client auth cause TLS errors > ----------------------------------------------------------------------- > > Key: WFLY-11007 > URL: https://issues.jboss.org/browse/WFLY-11007 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 13.0.0.Final > Reporter: Sebastian Laskawiec > Assignee: Stuart Douglas > Priority: Major > > h2. Summary > It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. > h2. Explanation > I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. > I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. > h2. Possible solution > Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. > Links: > - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 > - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 > - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 > - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... > - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... > - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Sebastian Laskawiec (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec updated WFLY-11007: --------------------------------------- Steps to Reproduce: - Start OpenShift local cluster - {{oc cluster up}} - Download the template - {{wget https://gist.githubusercontent.com/slaskawi/57ed810a7109a02a9d884b61ce2e7... - Create an app - {{oc new-app -f keycloak.json}} - Locate the IP of the server - {{oc get pods -o wide}} - Use curl on HTTPs port > Using OpenShift generated certificates and client auth cause TLS errors > ----------------------------------------------------------------------- > > Key: WFLY-11007 > URL: https://issues.jboss.org/browse/WFLY-11007 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 13.0.0.Final > Reporter: Sebastian Laskawiec > Assignee: Stuart Douglas > Priority: Major > > h2. Summary > It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. > h2. Explanation > I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. > I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. > h2. Possible solution > Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. > Links: > - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 > - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 > - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 > - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... > - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... > - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-675) UI Automations - Sync up automated testcases with Polarion

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-675: ------------------------------------ Summary: UI Automations - Sync up automated testcases with Polarion Key: SWSQE-675 URL: https://issues.jboss.org/browse/SWSQE-675 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11891) Add tests that enable JPA entity class bytecode enhancement

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11891?page=com.atlassian.jira.plugin... ] Scott Marlow edited comment on WFLY-11891 at 3/28/19 9:33 AM: -------------------------------------------------------------- [~tomekadamski] Thanks for volunteering to look at this, at this point, I think its best for the Hibernate team try to solve first ([~gbadner] has been working on it). was (Author: smarlow): [~tomekadamski] Thanks for volunteering to look at this, at this point, I think its best of the Hibernate team try to solve first ([~gbadner] has been working on it). > Add tests that enable JPA entity class bytecode enhancement > ----------------------------------------------------------- > > Key: WFLY-11891 > URL: https://issues.jboss.org/browse/WFLY-11891 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Reporter: Scott Marlow > Assignee: Gail Badner > Priority: Minor > Attachments: bytebuddy.log, javassist.log > > > Pick a few unit tests and add the following settings to enable [entity bytecode enhancement|http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single...]: > {code} > <property name="hibernate.enhancer.enableDirtyTracking" value="true"/> > <property name="hibernate.enhancer.enableLazyInitialization" value="true"/> > <property name="hibernate.enhancer.enableAssociationManagement" value="true"/> > {code} > Steps to reproduce: > * Build WildFly > * cd testsuite/integration/basic > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.transaction.TransactionTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.hibernate.management.ManagementTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase > Note that the org.jboss.as.test.integration.jpa.transaction.TransactionTestCase test should pass since javassist is specified in the persistence.xml but that seems to be ignored (we still get the ByteBuddy failure). > To workaround failures, prestart wildfly via: ./standalone.sh -Dhibernate.bytecode.provider=javassist and then run tests. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11891) Add tests that enable JPA entity class bytecode enhancement

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11891?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-11891: ------------------------------------- [~tomekadamski] Thanks for volunteering to look at this, at this point, I think its best of the Hibernate team try to solve first ([~gbadner] has been working on it). > Add tests that enable JPA entity class bytecode enhancement > ----------------------------------------------------------- > > Key: WFLY-11891 > URL: https://issues.jboss.org/browse/WFLY-11891 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Reporter: Scott Marlow > Assignee: Gail Badner > Priority: Minor > Attachments: bytebuddy.log, javassist.log > > > Pick a few unit tests and add the following settings to enable [entity bytecode enhancement|http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single...]: > {code} > <property name="hibernate.enhancer.enableDirtyTracking" value="true"/> > <property name="hibernate.enhancer.enableLazyInitialization" value="true"/> > <property name="hibernate.enhancer.enableAssociationManagement" value="true"/> > {code} > Steps to reproduce: > * Build WildFly > * cd testsuite/integration/basic > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.transaction.TransactionTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.hibernate.management.ManagementTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase > Note that the org.jboss.as.test.integration.jpa.transaction.TransactionTestCase test should pass since javassist is specified in the persistence.xml but that seems to be ignored (we still get the ByteBuddy failure). > To workaround failures, prestart wildfly via: ./standalone.sh -Dhibernate.bytecode.provider=javassist and then run tests. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11891) Add tests that enable JPA entity class bytecode enhancement

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11891?page=com.atlassian.jira.plugin... ] Scott Marlow reassigned WFLY-11891: ----------------------------------- Assignee: Gail Badner (was: Tomasz Adamski) > Add tests that enable JPA entity class bytecode enhancement > ----------------------------------------------------------- > > Key: WFLY-11891 > URL: https://issues.jboss.org/browse/WFLY-11891 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Reporter: Scott Marlow > Assignee: Gail Badner > Priority: Minor > Attachments: bytebuddy.log, javassist.log > > > Pick a few unit tests and add the following settings to enable [entity bytecode enhancement|http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single...]: > {code} > <property name="hibernate.enhancer.enableDirtyTracking" value="true"/> > <property name="hibernate.enhancer.enableLazyInitialization" value="true"/> > <property name="hibernate.enhancer.enableAssociationManagement" value="true"/> > {code} > Steps to reproduce: > * Build WildFly > * cd testsuite/integration/basic > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.transaction.TransactionTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.hibernate.management.ManagementTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase > Note that the org.jboss.as.test.integration.jpa.transaction.TransactionTestCase test should pass since javassist is specified in the persistence.xml but that seems to be ignored (we still get the ByteBuddy failure). > To workaround failures, prestart wildfly via: ./standalone.sh -Dhibernate.bytecode.provider=javassist and then run tests. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-638) UI Tests - Make sure incognito window is opened

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-638?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan commented on SWSQE-638: -------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/153 > UI Tests - Make sure incognito window is opened > ----------------------------------------------- > > Key: SWSQE-638 > URL: https://issues.jboss.org/browse/SWSQE-638 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-672) UI Automation - KIALI-1200

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-672?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan commented on SWSQE-672: -------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/154 > UI Automation - KIALI-1200 > -------------------------- > > Key: SWSQE-672 > URL: https://issues.jboss.org/browse/SWSQE-672 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11818) wildfly-16.0.0.Final: "From address" is no more used as default from in email

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFLY-11818?page=com.atlassian.jira.plugin... ] Yeray Borges commented on WFLY-11818: ------------------------------------- [~mayerw01] You must use Message.setFrom(), without arguments. As per Java Mail specification, it retrieves the sender’s username from the local system and configure it for the message. I've just used it with the Mail QS example and it worked fine in Wildfly, master branch, Wildfly 16.0.0.Final and Widlfy-15.0.0.Final. I used Message.setFrom(), without arguments \[1\] after configuring the 'from' attribute \[2\], to avoid taking it from user.name environment variable. That means, your Test2 case 'message.setFrom(new InternetAddress());', from my point of view, is invalid. I'm not sure from where are you getting a NPE on your Test3 case, but, in my environment it worked fine with WF15 as well. Maybe the description of 'from' attribute of mail-session is a bit misleading, but as per Java Mail specification, you have to call Message.setFrom() to retrieve the address configured in the mail subsystem. I can only suggest to do a double check; could you verify your email server accepts the 'from' address you are using and verify you are calling Message.setFrom() in your code? \[1\] {code:java} public void send() throws Exception { Message message = new MimeMessage(mySession); message.setFrom(); //This should not throw NPE System.out.println(message.getFrom()[0].toString().equals("mytest(a)test.com")); Address toAddress = new InternetAddress(to); message.addRecipient(Message.RecipientType.TO, toAddress); message.setSubject(subject); message.setContent(body, "text/plain"); Transport.send(message); } {code} \[2\] {code} /subsystem=mail/mail-session=MyOtherMail:write-attribute(name=from, value=mytest(a)test.com) {code} > wildfly-16.0.0.Final: "From address" is no more used as default from in email > ----------------------------------------------------------------------------- > > Key: WFLY-11818 > URL: https://issues.jboss.org/browse/WFLY-11818 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 16.0.0.Final > Environment: mvn -v > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00) > Maven home: /apps/apache-maven-3.6.0 > Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix" > Reporter: Wolfgang Mayer > Assignee: Yeray Borges > Priority: Major > > As mentioned in the Help (description) of 'Mail Session' configuration: > From: *From address that is used as default from, if not set when sending* > Apparently this is not the case anymore in wildfly-16.0.0.Final. > For example I made a test with quickstart-16.0/mail/. > When omitting the line > *message.setFrom(new InternetAddress(from));* > Sending mail fails with: > com.sun.mail.smtp.SMTPSendFailedException: 554-Transaction failed > 554 Unauthorized sender address. > I have the same issue when replacing the line above with > message.setFrom(new InternetAddress()); > I am pretty sure that this is working in wildfly-15 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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 March 2019