May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2785) The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2785?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2785: --------------------------------------- That's a good point. I've modified the description to inform that it's a good reference point. > The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient > --------------------------------------------------------------------------------------- > > Key: WFCORE-2785 > URL: https://issues.jboss.org/browse/WFCORE-2785 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: James Perkins > Assignee: Tomaz Cerar > > The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. > It also doesn't look like the test cleans up the deployed content which it should. -Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions.- See the {{HttpGenericOperationUnitTestCase}} for an example of using the {{HttpClient}} for a similar test. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2785) The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2785?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-2785: ---------------------------------- Description: The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. It also doesn't look like the test cleans up the deployed content which it should. -Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions.- See the {{HttpGenericOperationUnitTestCase}} for an example of using the {{HttpClient}} for a similar test. was: The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. It also doesn't look like the test cleans up the deployed content which it should. Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions. > The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient > --------------------------------------------------------------------------------------- > > Key: WFCORE-2785 > URL: https://issues.jboss.org/browse/WFCORE-2785 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: James Perkins > Assignee: Tomaz Cerar > > The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. > It also doesn't look like the test cleans up the deployed content which it should. -Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions.- See the {{HttpGenericOperationUnitTestCase}} for an example of using the {{HttpClient}} for a similar test. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2785) The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2785?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2785: ------------------------------------------ HttpGenericOperationUnitTestCase shouldn't be combined with the other test. They are testing different contexts (/management-upload vs /management) and tossing the test methods together is likely to lead to people missing that subtle distinction and dropping coverage. > The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient > --------------------------------------------------------------------------------------- > > Key: WFCORE-2785 > URL: https://issues.jboss.org/browse/WFCORE-2785 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: James Perkins > Assignee: Tomaz Cerar > > The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. > It also doesn't look like the test cleans up the deployed content which it should. Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2784) Host controller should allow passing jvm parameters to servers

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2784?page=com.atlassian.jira.plugi... ] Tomaz Cerar edited comment on WFCORE-2784 at 5/9/17 3:15 PM: ------------------------------------------------------------- Thinking bit more about this, maybe better solution would be to implement override for option processing in JvmOptionsBuilderFactory So that we could set jdk9 specific options in our test host*.xml under jvm settings like {code:xml} <jvm-options> <option value="--add-exports=java.base/sun.nio.ch=ALL-UNNAMED"/> <option value="--permit-illegal-access"/> </jvm-options> {code} and JvmOptionsBuilderFactory would filter out JDK9 specific flags when not running on oracle jdk9. Similar processing we had in place for permgen vs metaspace handling on jdk7/8 was (Author: ctomc): Thinking bit more about this, maybe better solution would be to implement override for option processing in JvmOptionsBuilderFactory So that we could set jdk9 specific options in our test host*.xml under jvm settings like {{ <jvm-options> <option value="--add-exports=java.base/sun.nio.ch=ALL-UNNAMED"/> <option value="--permit-illegal-access"/> </jvm-options> }} and JvmOptionsBuilderFactory would filter out JDK9 specific flags when not running on oracle jdk9. Similar processing we had in place for permgen vs metaspace handling on jdk7/8 > Host controller should allow passing jvm parameters to servers > -------------------------------------------------------------- > > Key: WFCORE-2784 > URL: https://issues.jboss.org/browse/WFCORE-2784 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Brian Stansberry > > It should be possible passing jvm options from host controller to servers runing in it. > One such example is passing -ea to servers if passed to host controller > other example is passing JDK9 specific parameters trough > idea of implementation https://github.com/wildfly/wildfly-core/pull/2394/commits/d824be5c6d973e4... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2785) The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2785?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-2785: ---------------------------------- Description: The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. It also doesn't look like the test cleans up the deployed content which it should. Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions. was:The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. > The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient > --------------------------------------------------------------------------------------- > > Key: WFCORE-2785 > URL: https://issues.jboss.org/browse/WFCORE-2785 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: James Perkins > Assignee: Tomaz Cerar > > The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. > It also doesn't look like the test cleans up the deployed content which it should. Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2784) Host controller should allow passing jvm parameters to servers

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2784?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on WFCORE-2784: ------------------------------------- Thinking bit more about this, maybe better solution would be to implement override for option processing in JvmOptionsBuilderFactory So that we could set jdk9 specific options in our test host*.xml under jvm settings like {{ <jvm-options> <option value="--add-exports=java.base/sun.nio.ch=ALL-UNNAMED"/> <option value="--permit-illegal-access"/> </jvm-options> }} and JvmOptionsBuilderFactory would filter out JDK9 specific flags when not running on oracle jdk9. Similar processing we had in place for permgen vs metaspace handling on jdk7/8 > Host controller should allow passing jvm parameters to servers > -------------------------------------------------------------- > > Key: WFCORE-2784 > URL: https://issues.jboss.org/browse/WFCORE-2784 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Brian Stansberry > > It should be possible passing jvm options from host controller to servers runing in it. > One such example is passing -ea to servers if passed to host controller > other example is passing JDK9 specific parameters trough > idea of implementation https://github.com/wildfly/wildfly-core/pull/2394/commits/d824be5c6d973e4... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2785) The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient

by James Perkins (JIRA)

James Perkins created WFCORE-2785: ------------------------------------- Summary: The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient Key: WFCORE-2785 URL: https://issues.jboss.org/browse/WFCORE-2785 Project: WildFly Core Issue Type: Task Components: Test Suite Reporter: James Perkins Assignee: Tomaz Cerar The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2784) Host controller should allow passing jvm parameters to servers

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-2784: ----------------------------------- Summary: Host controller should allow passing jvm parameters to servers Key: WFCORE-2784 URL: https://issues.jboss.org/browse/WFCORE-2784 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Tomaz Cerar Assignee: Brian Stansberry It should be possible passing jvm options from host controller to servers runing in it. One such example is passing -ea to servers if passed to host controller other example is passing JDK9 specific parameters trough idea of implementation https://github.com/wildfly/wildfly-core/pull/2394/commits/d824be5c6d973e4... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8736) Add jms destination browse functionality provided by Artemis

by varsha Kamble (JIRA)

varsha Kamble created WFLY-8736: ----------------------------------- Summary: Add jms destination browse functionality provided by Artemis Key: WFLY-8736 URL: https://issues.jboss.org/browse/WFLY-8736 Project: WildFly Issue Type: Enhancement Components: CLI, JMX Affects Versions: 11.0.0.Alpha1, 10.1.0.CR1 Reporter: varsha Kamble Assignee: Kabir Khan Artemis 1.5.x provides browse functionality via jconsole. However Wildfly 11 and below versions which includes Artemis 1.5.x as default JMS broker does not provide/implement this functionality. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2392) Remoting EJB identity propagation does not work with Elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2392?page=com.atlassian.jira.plugi... ] Jan Kalina edited comment on WFCORE-2392 at 5/9/17 1:21 PM: ------------------------------------------------------------ Reopening by Kabirs request - Kabir had to re-comment out AuthenticationTestCase: https://github.com/jbossas/jboss-eap7/pull/1810/files Broken by https://github.com/jbossas/jboss-eap7/pull/1811 ? was (Author: honza889): Reopening - Kabir had to re-comment out AuthenticationTestCase: https://github.com/jbossas/jboss-eap7/pull/1810/files Broken by https://github.com/jbossas/jboss-eap7/pull/1811 ? > Remoting EJB identity propagation does not work with Elytron > ------------------------------------------------------------ > > Key: WFCORE-2392 > URL: https://issues.jboss.org/browse/WFCORE-2392 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: elytron-legacy-test-fails > Fix For: 3.0.0.Beta18 > > > Even througth succesful obtaining LoginContext, identity is not propagated in EJB call. > Identity is unauthorized on server side. > *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference. > Often error message: > {code:java} > SaslException: Authentication failed: all available authentication mechanisms failed: > JBOSS-LOCAL-USER: Server rejected authentication > DIGEST-MD5: Server rejected authentication] > at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017