From asoldano at redhat.com Mon Nov 17 06:04:41 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 17 Nov 2014 12:04:41 +0100 Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> Message-ID: <5469D649.1040205@redhat.com> Five months after I started this thread, I finally come back to it with the result of some additional Arquillian investigation I did at the end of last week and a plan for dealing with the reorganization: - we'll be using the wildfly-arquillian-container-managed integration - we'll have multiple standalone.xml server configurations for testing; I plan to provide a solution for avoiding maintaining many confs, basically deriving them from the current container one (either by running CLI commands or by applying XSL transformations). The multiple configurations are required for any test that needs e.g. a custom https connector - we'll be using the 'class' Arquillian container mode for any test requiring a custom server configuration (each test is going to have its own server configuration); all remaining tests will use the default (suite) container mode - all @Deployment will have 'managed=true', except for very few and special cases - all @Deployment will initially have 'testable=false' and all @Test methods will also be @RunAsClient annotated; later we will see if we can re-write some of the tests meant to run in-container which are currently using custom mechanisms (ejb3 / servlet client deployments). - we'll have a convention requiring deployment names to be unique (IOW, no more deployments used by multiple tests); there're are currently few deployments used in more then a test, but that causes more problems then benefits (also consider we could now avoid writing the actually jar/war to the filesystem by default) - we'll probably have a mechanism in the build to automatically retrieve the specified version of WildFly, clone it, generate the various standalone.xml, update the ws stack on it and finally have the testsuite run. No more need for 2 builds (ant + maven) for deploying the stack first and testing it afterwards - we won't need the RemoteDeployer stuff anymore ;-) Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From rsearls at redhat.com Mon Nov 17 07:22:22 2014 From: rsearls at redhat.com (Rebecca Searls) Date: Mon, 17 Nov 2014 07:22:22 -0500 (EST) Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <5469D649.1040205@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> <5469D649.1040205@redhat.com> Message-ID: <1613699878.12480152.1416226942820.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alessio Soldano" > To: jbossws-dev at lists.jboss.org > Sent: Monday, November 17, 2014 6:04:41 AM > Subject: Re: [jbossws-dev] JBossWS testsuite reorganization > > Five months after I started this thread, I finally come back to it with > the result of some additional Arquillian investigation I did at the end > of last week and a plan for dealing with the reorganization: > > - we'll be using the wildfly-arquillian-container-managed integration > - we'll have multiple standalone.xml server configurations for testing; > I plan to provide a solution for avoiding maintaining many confs, > basically deriving them from the current container one (either by > running CLI commands or by applying XSL transformations). The multiple > configurations are required for any test that needs e.g. a custom https > connector > - we'll be using the 'class' Arquillian container mode for any test > requiring a custom server configuration (each test is going to have its > own server configuration); all remaining tests will use the default > (suite) container mode > - all @Deployment will have 'managed=true', except for very few and > special cases > - all @Deployment will initially have 'testable=false' and all @Test > methods will also be @RunAsClient annotated; later we will see if we can > re-write some of the tests meant to run in-container which are currently > using custom mechanisms (ejb3 / servlet client deployments). > - we'll have a convention requiring deployment names to be unique (IOW, > no more deployments used by multiple tests); there're are currently few > deployments used in more then a test, but that causes more problems then > benefits (also consider we could now avoid writing the actually jar/war > to the filesystem by default) I find the filesystem archives helpful at times. Particularly when created new tests. Hopefully there is a simple switch that will allow us to turn this facility on and off. If not ,I would prefer this be left on. > - we'll probably have a mechanism in the build to automatically retrieve > the specified version of WildFly, clone it, generate the various > standalone.xml, update the ws stack on it and finally have the testsuite > run. No more need for 2 builds (ant + maven) for deploying the stack > first and testing it afterwards > - we won't need the RemoteDeployer stuff anymore ;-) > > Cheers > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > jbossws-dev mailing list > jbossws-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossws-dev > From asoldano at redhat.com Mon Nov 17 08:22:54 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 17 Nov 2014 14:22:54 +0100 Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <1613699878.12480152.1416226942820.JavaMail.zimbra@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> <5469D649.1040205@redhat.com> <1613699878.12480152.1416226942820.JavaMail.zimbra@redhat.com> Message-ID: <5469F6AE.1000501@redhat.com> On 17/11/14 13:22, Rebecca Searls wrote: > > ----- Original Message ----- >> From: "Alessio Soldano" >> To: jbossws-dev at lists.jboss.org >> Sent: Monday, November 17, 2014 6:04:41 AM >> Subject: Re: [jbossws-dev] JBossWS testsuite reorganization >> >> ... >> - we'll have a convention requiring deployment names to be unique (IOW, >> no more deployments used by multiple tests); there're are currently few >> deployments used in more then a test, but that causes more problems then >> benefits (also consider we could now avoid writing the actually jar/war >> to the filesystem by default) > I find the filesystem archives helpful at times. Particularly when created new tests. > Hopefully there is a simple switch that will allow us to turn this facility on and off. > If not ,I would prefer this be left on. Sure, there's going to be a simple switch :-) Alessio -- Alessio Soldano Web Service Lead, JBoss From rsvoboda at redhat.com Tue Nov 18 07:21:45 2014 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 18 Nov 2014 07:21:45 -0500 (EST) Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <5469F6AE.1000501@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> <5469D649.1040205@redhat.com> <1613699878.12480152.1416226942820.JavaMail.zimbra@redhat.com> <5469F6AE.1000501@redhat.com> Message-ID: <503101717.5270249.1416313305433.JavaMail.zimbra@redhat.com> > On 17/11/14 13:22, Rebecca Searls wrote: > > > > ----- Original Message ----- > >> From: "Alessio Soldano" > >> To: jbossws-dev at lists.jboss.org > >> Sent: Monday, November 17, 2014 6:04:41 AM > >> Subject: Re: [jbossws-dev] JBossWS testsuite reorganization > >> > >> ... > >> - we'll have a convention requiring deployment names to be unique (IOW, > >> no more deployments used by multiple tests); there're are currently few > >> deployments used in more then a test, but that causes more problems then > >> benefits (also consider we could now avoid writing the actually jar/war > >> to the filesystem by default) > > I find the filesystem archives helpful at times. Particularly when created > > new tests. > > Hopefully there is a simple switch that will allow us to turn this facility > > on and off. > > If not ,I would prefer this be left on. > Sure, there's going to be a simple switch :-) +1 for this > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > jbossws-dev mailing list > jbossws-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossws-dev > From rsvoboda at redhat.com Tue Nov 18 07:27:44 2014 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 18 Nov 2014 07:27:44 -0500 (EST) Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <5469D649.1040205@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> <5469D649.1040205@redhat.com> Message-ID: <87423236.5272832.1416313664101.JavaMail.zimbra@redhat.com> > Five months after I started this thread, I finally come back to it with > the result of some additional Arquillian investigation I did at the end > of last week and a plan for dealing with the reorganization: > > - we'll be using the wildfly-arquillian-container-managed integration > - we'll have multiple standalone.xml server configurations for testing; > I plan to provide a solution for avoiding maintaining many confs, > basically deriving them from the current container one (either by > running CLI commands or by applying XSL transformations). The multiple +1 for CLI -1 for XSL .. this is way to hell ... we burned ourselves with XSLT files for AS7 SmartFrog templates > configurations are required for any test that needs e.g. a custom https > connector > - we'll be using the 'class' Arquillian container mode for any test > requiring a custom server configuration (each test is going to have its > own server configuration); all remaining tests will use the default > (suite) container mode > - all @Deployment will have 'managed=true', except for very few and > special cases > - all @Deployment will initially have 'testable=false' and all @Test > methods will also be @RunAsClient annotated; later we will see if we can > re-write some of the tests meant to run in-container which are currently > using custom mechanisms (ejb3 / servlet client deployments). > - we'll have a convention requiring deployment names to be unique (IOW, > no more deployments used by multiple tests); there're are currently few > deployments used in more then a test, but that causes more problems then > benefits (also consider we could now avoid writing the actually jar/war > to the filesystem by default) > - we'll probably have a mechanism in the build to automatically retrieve > the specified version of WildFly, clone it, generate the various > standalone.xml, update the ws stack on it and finally have the testsuite > run. No more need for 2 builds (ant + maven) for deploying the stack > first and testing it afterwards > - we won't need the RemoteDeployer stuff anymore ;-) Will you create some document on https://docs.jboss.org/author/display/JBWS/ with description of rules and changes for JBossWS CXF TS ? Rostislav > Cheers > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > jbossws-dev mailing list > jbossws-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossws-dev > From asoldano at redhat.com Tue Nov 18 07:56:48 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Tue, 18 Nov 2014 13:56:48 +0100 Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <87423236.5272832.1416313664101.JavaMail.zimbra@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> <5469D649.1040205@redhat.com> <87423236.5272832.1416313664101.JavaMail.zimbra@redhat.com> Message-ID: <546B4210.70402@redhat.com> On 18/11/14 13:27, Rostislav Svoboda wrote: >> Five months after I started this thread, I finally come back to it with >> the result of some additional Arquillian investigation I did at the end >> of last week and a plan for dealing with the reorganization: >> >> - we'll be using the wildfly-arquillian-container-managed integration >> - we'll have multiple standalone.xml server configurations for testing; >> I plan to provide a solution for avoiding maintaining many confs, >> basically deriving them from the current container one (either by >> running CLI commands or by applying XSL transformations). The multiple > +1 for CLI > > -1 for XSL .. this is way to hell ... we burned ourselves with XSLT files for AS7 SmartFrog templates OK > >> configurations are required for any test that needs e.g. a custom https >> connector >> - we'll be using the 'class' Arquillian container mode for any test >> requiring a custom server configuration (each test is going to have its >> own server configuration); all remaining tests will use the default >> (suite) container mode >> - all @Deployment will have 'managed=true', except for very few and >> special cases >> - all @Deployment will initially have 'testable=false' and all @Test >> methods will also be @RunAsClient annotated; later we will see if we can >> re-write some of the tests meant to run in-container which are currently >> using custom mechanisms (ejb3 / servlet client deployments). >> - we'll have a convention requiring deployment names to be unique (IOW, >> no more deployments used by multiple tests); there're are currently few >> deployments used in more then a test, but that causes more problems then >> benefits (also consider we could now avoid writing the actually jar/war >> to the filesystem by default) >> - we'll probably have a mechanism in the build to automatically retrieve >> the specified version of WildFly, clone it, generate the various >> standalone.xml, update the ws stack on it and finally have the testsuite >> run. No more need for 2 builds (ant + maven) for deploying the stack >> first and testing it afterwards >> - we won't need the RemoteDeployer stuff anymore ;-) > Will you create some document on https://docs.jboss.org/author/display/JBWS/ with description of rules and changes for JBossWS CXF TS ? Sure, the build is likely going to be different, so we'll need new documentation on how to build and test JBossWS. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From ema at redhat.com Mon Nov 24 04:45:01 2014 From: ema at redhat.com (Jim Ma) Date: Mon, 24 Nov 2014 17:45:01 +0800 Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <5469D649.1040205@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> <5469D649.1040205@redhat.com> Message-ID: <5472FE1D.4030306@redhat.com> On 11/17/2014 07:04 PM, Alessio Soldano wrote: > Five months after I started this thread, I finally come back to it with > the result of some additional Arquillian investigation I did at the end > of last week and a plan for dealing with the reorganization: > > - we'll be using the wildfly-arquillian-container-managed integration > - we'll have multiple standalone.xml server configurations for testing; > I plan to provide a solution for avoiding maintaining many confs, > basically deriving them from the current container one (either by > running CLI commands or by applying XSL transformations). The multiple > configurations are required for any test that needs e.g. a custom https > connector Are we going to use @ServerSetup to apply change with CLI for arquillian testcase ? > - we'll be using the 'class' Arquillian container mode for any test > requiring a custom server configuration (each test is going to have its > own server configuration); all remaining tests will use the default > (suite) container mode > - all @Deployment will have 'managed=true', except for very few and > special cases > - all @Deployment will initially have 'testable=false' and all @Test > methods will also be @RunAsClient annotated; later we will see if we can > re-write some of the tests meant to run in-container which are currently > using custom mechanisms (ejb3 / servlet client deployments). > - we'll have a convention requiring deployment names to be unique (IOW, > no more deployments used by multiple tests); there're are currently few > deployments used in more then a test, but that causes more problems then > benefits (also consider we could now avoid writing the actually jar/war > to the filesystem by default) > - we'll probably have a mechanism in the build to automatically retrieve > the specified version of WildFly, clone it, generate the various > standalone.xml, update the ws stack on it and finally have the testsuite > run. No more need for 2 builds (ant + maven) for deploying the stack > first and testing it afterwards +1. This will be a big improvement in jbossws5. We can look at update ws stck with jboss module layer path setting or running jbossas instance with the maven GAV reference module.xml. > - we won't need the RemoteDeployer stuff anymore ;-) +1. > > Cheers > Alessio > From asoldano at redhat.com Mon Nov 24 06:19:17 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 24 Nov 2014 12:19:17 +0100 Subject: [jbossws-dev] JBossWS testsuite reorganization In-Reply-To: <5472FE1D.4030306@redhat.com> References: <539B1B2C.4020105@redhat.com> <539EC49E.40905@redhat.com> <539EE0D7.2020907@redhat.com> <177181653.30699830.1403767818007.JavaMail.zimbra@redhat.com> <5469D649.1040205@redhat.com> <5472FE1D.4030306@redhat.com> Message-ID: <54731435.2050605@redhat.com> On 24/11/14 10:45, Jim Ma wrote: > On 11/17/2014 07:04 PM, Alessio Soldano wrote: >> Five months after I started this thread, I finally come back to it with >> the result of some additional Arquillian investigation I did at the end >> of last week and a plan for dealing with the reorganization: >> >> - we'll be using the wildfly-arquillian-container-managed integration >> - we'll have multiple standalone.xml server configurations for testing; >> I plan to provide a solution for avoiding maintaining many confs, >> basically deriving them from the current container one (either by >> running CLI commands or by applying XSL transformations). The multiple >> configurations are required for any test that needs e.g. a custom https >> connector > Are we going to use @ServerSetup to apply change with CLI for > arquillian testcase ? @ServerSetup is a wildfly specific class and I'd really avoid having container specific compile time dependencies in our test sources. In any case, after having talked with Rostislav on IRC, I've decided to use a groovy script based approach; that allows direct and easy editing of the xml conf files (moreover it's more intuitive then CLI and maintainable from a QE point of view). Cheers Alessio >> - we'll be using the 'class' Arquillian container mode for any test >> requiring a custom server configuration (each test is going to have its >> own server configuration); all remaining tests will use the default >> (suite) container mode >> - all @Deployment will have 'managed=true', except for very few and >> special cases >> - all @Deployment will initially have 'testable=false' and all @Test >> methods will also be @RunAsClient annotated; later we will see if we can >> re-write some of the tests meant to run in-container which are currently >> using custom mechanisms (ejb3 / servlet client deployments). >> - we'll have a convention requiring deployment names to be unique (IOW, >> no more deployments used by multiple tests); there're are currently few >> deployments used in more then a test, but that causes more problems then >> benefits (also consider we could now avoid writing the actually jar/war >> to the filesystem by default) >> - we'll probably have a mechanism in the build to automatically retrieve >> the specified version of WildFly, clone it, generate the various >> standalone.xml, update the ws stack on it and finally have the testsuite >> run. No more need for 2 builds (ant + maven) for deploying the stack >> first and testing it afterwards > +1. This will be a big improvement in jbossws5. We can look at > update ws stck with jboss module layer path setting or running > jbossas instance with the maven GAV reference module.xml. >> - we won't need the RemoteDeployer stuff anymore ;-) > +1. >> >> Cheers >> Alessio >> > -- Alessio Soldano Web Service Lead, JBoss