[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- Set up a Hudson job: http://hudson.qa.jboss.com/hudson/job/JBoss-AS-6.0.x-testSuite-ipv6/ The plan is to: (i) first fix the AS to get it to boot under IPV6, then (ii) fix the testsuite/build.xml and server configs and jboss-test to be able to run some test cases which aren't broken (i.e. dont' reference URLs) then (iii) from the minimal set of tests, start adding more broken tests as I go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 3. Need to fix deploy/ejb3-connectors-jboss-beans.xml, but this is copied in from an EJB3 project jar, jboss-ejb3-core.jar. Need to replace: <value-factory bean="ServiceBindingManager" method="getStringBinding"> <parameter> jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3</parameter> <parameter><null /></parameter> <parameter>socket://${jboss.bind.address}:${port}?timeout=300000</parameter> <parameter><null /></parameter> <parameter>3873</parameter> </value-factory> with: <value-factory bean="ServiceBindingManager" method="getStringBinding"> <parameter> jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3</parameter> <parameter><null /></parameter> <parameter>socket://${hostforurl}:${port}?timeout=300000</parameter> <parameter><null /></parameter> <parameter>3873</parameter> </value-factory> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 4. Fixed Remoting multi-homed URL formation in server/src/etc/deploy/remoting-jboss-beans.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 6. Issues with the following files from WebServices: * deploy/juddi-service.sar/juddi.war/WEB-INF/juddi.properties - bad JUDDI URLs * data/wsdl/webservice.war/embedded.wsdl - possible bad soap URL I seem to remember these errors from EAP 4.3 CPs. Going to come back to them later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 8. Fixed server-manager to handle IPv6 addresses - checked out server-manager trunk - modified the class org.jboss.jbossas.servermanager.Server.java to generate correctly formed URLs for http and rmi access to the server when using IPv6 address literals - committed the changes to trunk and created a snapshot of server-manager called jboss-server-manager:1.0.4-SNAPSHOT - uploaded to the JBoss snapshots repository; hanged the reference in the component-matrix pom. When adding the -Dservers.shutdown.nocheck=true parameter to the Hudson job, the Hudson job now starts minimal and shuts it down using IPv6 addresses -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 10. Fix URL generation in a number of test cases. Many of these were dealt with previously in EAP 4.3 CP: 10.1 org.jboss.test.utils.web.HttpUtils This is a utilities class used in test cases to do the following: - create base URLs for non-authenticated access and authenticated access to servlets resident in Tomcat (getBaseURL(), getBaseURLNoAuth()) - execute those interactions with Tomcat (accessURL) - added in private methods to generate getServerHost() and getServerHostForURL() 10.2 ClassloaderLeakTests were failing with an incorrectly constructed URL to Tomcat. The following tests were affected (* indicated modified): ClassloaderLeakTestBase(*) ClassloaderLeakUnitTest Ejb3ClassloaderLeakUnitTest URL generation fixed. 10.3 JAXR tests were failing due to the system property jaxr.query.url and jaxr.publish.url being set incorreectly in testsuite/build.xml. These system properties are used to set the properties for obtaining the javax.xml.registries.ConnectionFactoiry. Fixed build.xml to use node0.url instrad of node0. 10.4 Fixed URL generation in the following test cases: org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase org.jboss.test.web.security.CustomHeaderAuthTestCase org.jboss.test.web.test.SingleSignOnUnitTestCase org.jboss.test.naming.test.NamingRestartUnitTestCase org.jboss.test.naming.test.PooledInvokerUnitTestCase org.jboss.test.naming.test.SecurityUnitTestCase org.jboss.test.naming.test.SimpleUnitTestCase org.jboss.test.jbossmq.test.HTTPConnectionUnitTestCase org.jboss.test.hellojrmpiiop.test.HelloTimingStressTestcase(*) mainly by changing getServerHost() to getServerHostForURL() when embedded in URLs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- The test should be fixed not to be dependent on localhost at a minimum. Also, the use of SBM should be attempted, but SBM will not have entries for test beans. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 13. A number of tests in org.jboss.test.web.test were failing and, after inspection, there were errors associated with HttpClient and access to cookies. These issues had also been seen and fixed in EAP 4.3 CP. I uploaded a patched version of HttpClient stored in the buildmagic repo, namely apache-httpclient 3.0.1.patch01.jar, and uploaded it as a maven snapshot commons-httpclient:commons-httpclient:3.0.1-SNAPSHOT. These tests seem to be failing from deployment errors: org.jboss.test.web.test.RootContextUnitTestCase org.jboss.test.web.test.NamingServletUnitTestCase org.jboss.test.web.test.EncAnnotationsUnitTestCase -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 16. Updated the build to use hsqldb:hsqldb:1.8.0.8.patch03-brew which contains HSQLDB patched to be able to start and shutdown with IPv6 addresses 17. Updated naming 5.0.5.Final to fix an autodiscovery parsing problem - uploaded org.jboss:naming:5.0.5-SNAPSHOT which is a patched version of 5.0.5.Final. Need to investigate further on this one because some autodiscovery failures are due to localhost being used. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 19. PersistentStore clustering test cases There is a hierarchy of classes which make use of a HSQLDB database: in org.jboss.test.cluster.test.testutil and org.jboss.test.cluster.test.web.persistent: TestSetup JBossTestClusteredSetup DBSetup PersistentStoreTestSetup which make use of delegates TestSeupDelegate {DBSetupDelegate, PersistentStoreSetupDelegate} as well as PersistentStoreTableSetup. These needed URLs fixing in the delegates. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 22. Fixed up org.jboss.test.web.test.ssl.SSLUnitTestCase which was generating incorrect request urls for HTTP servlet requests. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 24. Quite a number of session related tests were failing on the Hudson run: org.jboss.test.cluster.defaultcfg.simpleweb.test.AttributeBasedMaxUnreplicatedInterval (fails on IPv6) org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationToPassivatedSession (fails on IPv6 ) org.jboss.test.cluster.defaultcfg.simpleweb.test.BuddyReplicationFailover (fails on IPv6) org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionMemoryLeak (fails on IPv6 ) org.jboss.test.cluster.defaultcfg.simpleweb.test.ClusteredSessionNotificationPolicy (fails on IPv6 ) org.jboss.test.cluster.defaultcfg.simpleweb.test.MultipleWarSingleRedeploy (fails on IPv6) org.jboss.test.cluster.defaultcfg.simpleweb.test.ReplicationToPassivatedSession (fails on IPv6 ) org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicated (fails on IPv6) However, these tests would pass on my local machine. Here are some notes from an email exchange: ---------------------------------- notes -------------------------- I found the problem and it is a bug in the tests due to the change between JBC and ISPN. Here is what happens when we execute org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedInterval: (i) CacheConfigTestSetup, a wrapper for the test case, sets up two Infinispan caches by calling SessionTestUtil.createCacheContainer. Before these calls, Brian used JGroupsSystemPropertySupport to temporarily set jgroups.bind_addr, jgroups.udp.mcast_addr and jgroups.udp.mcast_port to values associated with the testsuite's jbosstest.cluster.node1 system property and jbosstest.udpGroup property. He restores the original values after the caches have been created. (ii) once the test starts, it calls SessionTestUtil.createManager() to create two instances of org.jboss.web.tomcat.service.session.JBossCacheManager, the session managers used in clustering. These are passed the cahces which were created earlier. The calls to createManager are not preceeded and followed by calls to JGroupsSystemPropertySupport. The tests then run. The bug is that the caches are not actually started when CacheConfigTestSetup is called, but they are started when SessionTestUtil.createManager is called. So the correct system properties are not getting picked up. I'm guessing that this is a change from JBC behaviour, right Manik? If I preceed the calls to createManager with JGroupsSystemPropertySupport calls, the caches get intilaised correctly and the tests pass on QA lab hosts which they did not previously. Looking at the logs, I can see the correct addresses. I can't explain why the test passed on my machine and not on the QA lab machines. ---------------------------------- notes -------------------------- Presently discussing this with the clustering guys. In the end, the simplest solution may be to include JGroupsSystemPropertySupport in the per test setup and teardown of all of these tests, to make sure the right p-roperties get picked up by the JBossCacheManagers. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- The only other copy of HttpUtils is in org.jboss.test.cluster.ejb3.clusteredservice.unit.HttpUtils and this is now fixed up to be the same as the main copy in org.jboss.test.util.web.HttpUtils. Both of these have static calls added for getServerHost() and getServerHostForURL() to pick up the host for the BaseURL for HTTP requests. The use of the class in ejb3.clusteredsession is a bit wierd as it is a non-clustered test utility being used in a clustering test. For the test case constructs the clustered URLs and the utility is used to execute them. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- Fixed them - in most cases by using the methods from JBossClusteredTestCase and renmoving individual calls to System.getProperty("jbosstest.cluster.nodex"); -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 28. org.jboss.test.cluster.multicfg.ejb2.test.StatefulPassivationExpirationUnitTestCase This test deploys two service archives, sfsb-passexp.sar and sfsb-passexp1.sar. These service archives in turn deploy a Remoting Connector PassExpConnection in partition-passexp-jboss-beans.xml. The Connector is initialised with an InvokerURL, as follows: <parameter><![CDATA[socket://${jboss.bind.address}:24446/?datatype=invocation&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller&enableTcpNoDelay=true]]></parameter> We either need to pass in a URL form for jboss.bind.address (which is no longer done on the server side) or use SBM to generate the correct URL. We do the latter, as follows: <parameter> <value-factory bean="ServiceBindingManager" method="getStringBinding"> <parameter>PassExpConnector</parameter> <parameter><null/></parameter> <parameter><![CDATA[socket://${hostforurl}:${port}/?datatype=invocation&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller&enableTcpNoDelay=true]]></parameter> <parameter>${jboss.bind.address}</parameter> <parameter>24446</parameter> </value-factory> </parameter> -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 30. Fixed up org.jboss.test.web.test.WebProgrammaticLoginTestCase and org.jboss.test.web.test.ssl.ClientCertJaspiWebUnitTestCase These just required having their baseURLs adjusted from using hetServerHost() to getServerHostForURL(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 33. Fixed up DRMTestCase which tests the DistributedReplicantManager using a number of mock components and a JGroups GossipRouter. This test cases was making use of hard coded 127.0.0.1 instances in a JGroups stack deployment as well as in the test case itself. I replaced all instances of 127.0.0.1 with localhost and the tests pass. This test really should be using the prescribed bind addresses, but its OK for now. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 35. Fixed up org.jboss.test.cluster.defaultcfg.web.test.ClusteringDefaultsTestCase to use getAdaptors()[0] instead of getServer() as it extends JBossClusteredTestcase and system properties for JBossTestCase are not always defined in the client side junit tasks. 36. Fixed up org.jboss.jmx.test.SecureJMXInvokerUnitTestCase to use getServerHost() instead of reading the system property jbosstest.server.host as it is extends JBossTestcase and the system property jbosstest.server.host can be mistakenly left out of the client side junit task, as it was in this case for the JACC+allstarrole target. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JBAS-8540: ------------------------------------------- 39. AOP Remiting tests fixed up by replacing missing stack preferences on the client-side aop test target. The result of using stack preferences in the server side and not on the client side when both sides are using invoker locator socket://localhost:5050 is that the server may be listening on [::1]:5050 and the client trying to connect on socket://127.0.0.1:5050 40. Fixed up some webservivces test cases mentioned in JBAS-8701, JBAS-8702. See those issues for details. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.... ] Shelly McGowan updated JBAS-8540: --------------------------------- Summary: Modify AS 6 and the AS 6 testsuite to work with IPv6 addresses (was: T) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz updated JBAS-8540: -------------------------------------- Attachment: diffA-109571to109712.txt diffB-109713to109834.txt diffC-109879to109953.txt apply-patches.txt Attaching patches and log from application. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8540?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz resolved JBAS-8540. --------------------------------------- Assignee: Shelly McGowan (was: Richard Achmatowicz) Resolution: Done The main work is done. There are some doc updates which will be similar to the last comment I made here which show thow to start up the AS using IPv6 addresses. In future, we may need to a doc which explains in more detail how to adjust all of the default compoonent bind bind and multicast addresses (most of which are biased toward IPv4) to use IPv6 counterparts. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira