The JMX protocol for Wildfly / AS is horrible and for any sort of application or framework the servlet adaptor should be used. Yes, it's a little slower, but it will give you the full environment you're used to using when you develop.
On Fri, Jan 31, 2014 at 1:59 PM, Ron Smeral <[email protected]> wrote: > Hi Christian, > > I see you recently removed defaultProtocol from arquillian.xml. Is there > any reason not to have it there? The now default JMX protocol seems to be > causing test stability issues, I can't succesfully run for example the Data > module tests. I'm not sure why this happens. Have you maybe encountered > this too? > > Also, just FYI, we now have a job 'DeltaSpike-wildfly-daily' at > hudson.jboss.org which tests the wildfly-build-managed profile. It will > be sending mails to commits@deltaspike. > > Ron > > > On 25.1.2014 08:36, Christian Kaltepoth wrote: > >> Hey Gerhard, >> >> yeah, I wasn't aware that the Glassfish jobs have already been added. But >> Wildfly is still missing. >> >> Christian >> >> >> >> 2014/1/24 Gerhard Petracek <[email protected]> >> >> hi christian, >>> >>> the jenkins-jobs should be in place already. >>> >>> regards, >>> gerhard >>> >>> >>> >>> 2014/1/24 Christian Kaltepoth <[email protected]> >>> >>> Hey all, >>>> >>>> I pushed out all the changes of the "build-managed" integration test >>>> >>> Maven >>> >>>> profiles which I suggested. >>>> >>>> You can now run the integration test suite against the different >>>> >>> containers >>> >>>> like this: >>>> >>>> $ mvn clean install -Ptomee-build-managed >>>> $ mvn clean install -Pjbossas-build-managed-7 >>>> $ mvn clean install -Pwildfly-build-managed >>>> $ mvn clean install -Pglassfish-build-managed-3 >>>> $ mvn clean install -Pglassfish-build-managed-4 >>>> >>>> Each profiles will automatically download, unpack and configure the >>>> corresponding container. All TCP ports are changed so that they differ >>>> >>> from >>> >>>> this default ones. This way we should be able to run them on the CI >>>> >>> server >>> >>>> without any problems. >>>> >>>> Could anyone with the required permissions add corresponding jobs in >>>> Jenkins? >>>> >>>> Christian >>>> >>>> >>>> >>>> >>>> 2014/1/11 Christian Kaltepoth <[email protected]> >>>> >>>> Hey Ron, >>>>> >>>>> yeah, I also thought about using "user.dir", but this could point to >>>>> >>>> some >>> >>>> weird locations depending on from where you start the build. So let's >>>>> >>>> go >>> >>>> with "java.io.tmpdir" for now. >>>>> >>>>> Christian >>>>> >>>>> >>>>> 2014/1/8 Ron Smeral <[email protected]> >>>>> >>>>> Hey Christian, >>>>>> >>>>>> you're right, I haven't realized that. Also, if some module needed a >>>>>> custom arquillian conf, Arquillian reads a system property named >>>>>> "arquillian.xml" which defines the name of the configuration file. >>>>>> >>>>>> The last thing I can think of for the testsuite root is the Maven >>>>>> property "user.dir" - the working directory from which mvn was >>>>>> >>>>> executed. >>> >>>> Ron >>>>>> >>>>>> >>>>>> On 7.1.2014 17:20, Christian Kaltepoth wrote: >>>>>> >>>>>> Hey Ron, >>>>>>> >>>>>>> I don't think unpacking is necessary. If arquillian.xml is located in >>>>>>> deltaspike/test-utils/src/main/resources, it will be on the >>>>>>> classpath >>>>>>> for >>>>>>> all integration tests. That's basically the setup we are using for >>>>>>> Rewrite >>>>>>> since quite some time and it is working fine. See [1]. >>>>>>> >>>>>>> I guess you are right regarding the merging of poms and that >>>>>>> >>>>>> ${basedir} >>> >>>> won't work because of this. Too bad. So perhaps we should use >>>>>>> java.io.tmpdir for now until we find a better way (if there is any). >>>>>>> >>>>>>> Christian >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/ocpsoft/rewrite/blob/master/test- >>>>>>> harness/src/main/resources/arquillian.xml >>>>>>> >>>>>>> >>>>>>> 2014/1/7 Ron Smeral <[email protected]> >>>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>>> the test-utils is in the parent/code/pom.xml as a dependency, but >>>>>>>> >>>>>>> then >>> >>>> still, to get to the arquillian.xml file in the test-utils.jar, it >>>>>>>> >>>>>>> would >>>> >>>>> need to be unpacked using e.g. dependency:unpack plugin goal. >>>>>>>> >>>>>>>> Regarding basedir, because POMs are merged in Maven to form the >>>>>>>> Effective >>>>>>>> POM, the basedir property always points to the current project, >>>>>>>> regardless >>>>>>>> of the POM in which you reference it. >>>>>>>> For example, if -- as you suggest -- there's project P and C, where >>>>>>>> >>>>>>> P >>> >>>> is >>>> >>>>> parent of C, and P contains <root>${basedir}</root>, then for C, the >>>>>>>> ${root} will contain the base dir of C anyway, not that of P. >>>>>>>> The least hacky (but still ugly) way that comes to mind is to pass >>>>>>>> >>>>>>> the >>> >>>> property an absolute path from the shell, as in "mvn clean test >>>>>>>> -Droot=$(pwd)". The root property could have a default value of >>>>>>>> ${java.io.tmpdir}. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> On 7.1.2014 07:51, Christian Kaltepoth wrote: >>>>>>>> >>>>>>>> Hey Ron, >>>>>>>> >>>>>>>>> I don't think we will have to copy arquillian.xml using the >>>>>>>>> resources-plugin. If we add it to src/main/resources of the >>>>>>>>> >>>>>>>> test-utils >>>> >>>>> module, it will be on the test classpath for all other modules. I >>>>>>>>> >>>>>>>> think >>>> >>>>> this should work fine. >>>>>>>>> >>>>>>>>> Regarding the testsuite root directory. I think we could use >>>>>>>>> >>>>>>>> Maven's >>> >>>> ${basedir} in the parent pom and store it in a system property. >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Christian >>>>>>>>> >>>>>>>>> >>>>>>>>> 2014/1/3 Ron Smeral <[email protected]> >>>>>>>>> >>>>>>>>> Hi Christian, >>>>>>>>> >>>>>>>>> looking at the arquillian.xml files, they are 99% the same, the >>>>>>>>>> >>>>>>>>> only >>> >>>> one >>>>>>>>>> that actually differs (other than whitespace, comments and missing >>>>>>>>>> cdicontainer.version property) is the one in the data module, >>>>>>>>>> containing >>>>>>>>>> a >>>>>>>>>> testDatabase configuration for tomee. So, we could have just one >>>>>>>>>> arquillian.xml file somewhere in the testsuite root, copy it over >>>>>>>>>> using >>>>>>>>>> resources-plugin, and override it only when necessary. >>>>>>>>>> One minor problem is -- and this is for the container unpacking >>>>>>>>>> >>>>>>>>> too >>> >>>> -- >>>> >>>>> that to point to the testsuite root, every pom would need to keep >>>>>>>>>> >>>>>>>>> a >>> >>>> relative reference to it (e.g. <testsuite.root>../../..</ >>>>>>>>>> testsuite.root>), >>>>>>>>>> which is ugly, but doable. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3.1.2014 06:26, Christian Kaltepoth wrote: >>>>>>>>>> >>>>>>>>>> Hey Ron, >>>>>>>>>> >>>>>>>>>> yeah, there are differences between arquillian.xml files. But >>>>>>>>>>> >>>>>>>>>> why? >>> >>>> I >>>> >>>>> don't >>>>>>>>>>> see any reason for having different arquillian.xml files between >>>>>>>>>>> modules. >>>>>>>>>>> Actually the integration test Maven profiles are also located in >>>>>>>>>>> >>>>>>>>>> a >>> >>>> single >>>>>>>>>>> parent pom and not in each individual module pom. IMHO we should >>>>>>>>>>> treat >>>>>>>>>>> arquillian.xml the same way. Unless there is a good reason for >>>>>>>>>>> >>>>>>>>>> having >>>> >>>>> multiple ones. >>>>>>>>>>> >>>>>>>>>>> I agree that we should unpack the container only once. I'm not >>>>>>>>>>> >>>>>>>>>> sure I >>>> >>>>> like >>>>>>>>>>> to use java.io.tmpdir though. It would be nice to have it in the >>>>>>>>>>> top-level >>>>>>>>>>> "target" directory or something like that. That would ensure that >>>>>>>>>>> running >>>>>>>>>>> "mvn clean" would also remove the unpacked container. >>>>>>>>>>> >>>>>>>>>>> Christian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2014/1/2 Ron Smeral <[email protected]> >>>>>>>>>>> >>>>>>>>>>> On 2.1.2014 17:55, Christian Kaltepoth wrote: >>>>>>>>>>> >>>>>>>>>>> Hey all, >>>>>>>>>>> >>>>>>>>>>>> there are two things I would like to address regarding our >>>>>>>>>>>> >>>>>>>>>>>>> integration >>>>>>>>>>>>> test >>>>>>>>>>>>> suite. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Currently each module has its own arquillian.xml file. IMHO >>>>>>>>>>>>> >>>>>>>>>>>> this >>>> >>>>> doesn't >>>>>>>>>>>>> make sense. What about using a single arquillian.xml and >>>>>>>>>>>>> >>>>>>>>>>>> placing >>> >>>> it in >>>>>>>>>>>>> the >>>>>>>>>>>>> test-utils module? >>>>>>>>>>>>> >>>>>>>>>>>>> +0, there are minor differences among them currently >>>>>>>>>>>>> (though >>>>>>>>>>>>> >>>>>>>>>>>> not >>>> >>>>> sure >>>>>>>>>>>>> >>>>>>>>>>>>> if >>>>>>>>>>>>> >>>>>>>>>>>> necessary), and it would make it more difficult to make an >>>>>>>>>>>> individual >>>>>>>>>>>> modification if there was single arquillian.xml. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2. We have both "managed" and "remote" profiles for some >>>>>>>>>>>> containers. >>>>>>>>>>>> But >>>>>>>>>>>> >>>>>>>>>>>> the "managed" profiles (especially Wildfly + Glassfish) >>>>>>>>>>>> require >>>>>>>>>>>> >>>>>>>>>>>>> you to >>>>>>>>>>>>> manually download and setup the corresponding container which I >>>>>>>>>>>>> would >>>>>>>>>>>>> like >>>>>>>>>>>>> to avoid. I think it would be nicer if the "managed" profiles >>>>>>>>>>>>> could do >>>>>>>>>>>>> this >>>>>>>>>>>>> automatically. This would simplify the process of running the >>>>>>>>>>>>> >>>>>>>>>>>> tests >>>> >>>>> locally >>>>>>>>>>>>> before committing and it would also be easier to create CI jobs >>>>>>>>>>>>> >>>>>>>>>>>> for >>>> >>>>> them. >>>>>>>>>>>>> See [1] for an example of a profile which sets up the container >>>>>>>>>>>>> automatically and therefore runs out of the box even in >>>>>>>>>>>>> >>>>>>>>>>>> transient >>> >>>> CI >>>>>>>>>>>>> environments like Travis [2]. >>>>>>>>>>>>> >>>>>>>>>>>>> There already is such profile at least for JBoss AS7 >>>>>>>>>>>>> >>>>>>>>>>>>> (jbossas-build-managed-7) and at this very moment I'm adding >>>>>>>>>>>>> >>>>>>>>>>>> such >>>> >>>>> profile >>>>>>>>>>>> for WildFly. However, currently there is a minor drawback to the >>>>>>>>>>>> current >>>>>>>>>>>> approach -- the container is unpacked for every module and so >>>>>>>>>>>> almost 5 >>>>>>>>>>>> GB >>>>>>>>>>>> of diskspace is required to run the whole testsuite, which is >>>>>>>>>>>> >>>>>>>>>>> quite >>>> >>>>> impractical. It would be nice to have the container unpacked to >>>>>>>>>>>> >>>>>>>>>>> a >>> >>>> shared >>>>>>>>>>>> location, e.g. ${java.io.tmpdir}, just as in the ocpsoft rewrite >>>>>>>>>>>> >>>>>>>>>>> pom >>>> >>>>> you >>>>>>>>>>>> linked. I'll try that in the AS7 and WF8 profiles. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> >>>>>>>>>>> https://github.com/ocpsoft/rewrite/blob/master/pom.xml#L706 >>> >>>> [2] https://travis-ci.org/ocpsoft/rewrite/builds/16192940 >>>>>>>>>>>>> >>>>>>>>>>>>> Christian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> Ron Smeral >>>>>>>>>>>>> >>>>>>>>>>>>> JBoss Quality Engineer >>>>>>>>>>>> Brno >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Ron Smeral >>>>>>>>>>> >>>>>>>>>> JBoss Quality Engineer >>>>>>>>>> Brno >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>> Ron Smeral >>>>>>>> JBoss Quality Engineer >>>>>>>> Brno >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>> Ron Smeral >>>>>> JBoss Quality Engineer >>>>>> Brno >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Christian Kaltepoth >>>>> Blog: http://blog.kaltepoth.de/ >>>>> Twitter: http://twitter.com/chkal >>>>> GitHub: https://github.com/chkal >>>>> >>>>> >>>>> >>>> -- >>>> Christian Kaltepoth >>>> Blog: http://blog.kaltepoth.de/ >>>> Twitter: http://twitter.com/chkal >>>> GitHub: https://github.com/chkal >>>> >>>> >> >> > -- > Ron Smeral > JBoss Quality Engineer > Brno > > -- Jason Porter http://en.gravatar.com/lightguardjp
