+1 On Oct 16, 2011 11:34 PM, "Romain Manni-Bucau" <[email protected]> wrote:
> about our arquillian adapters, > > do we drop arquillian-tomee-embedded-with-war ? (+1 for me ;)) > > - Romain > > 2011/10/5 Jonathan Gallimore <[email protected]> > > > Will do (will be tomorrow now, its getting late for me!), thanks for the > > link! > > > > Jon > > On Oct 5, 2011 12:02 AM, "Mark Struberg" <[email protected]> wrote: > > > You could take a look at what Dan and I did for native owb: > > > > > > https://github.com/struberg/arquillian-container-openwebbeans > > > LieGrue, > > > strub > > > > > > > > > ----- Original Message ----- > > >> From: Jonathan Gallimore <[email protected]> > > >> To: [email protected] > > >> Cc: > > >> Sent: Wednesday, October 5, 2011 12:57 AM > > >> Subject: Re: Arquillian adapters > > >> > > >> On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore < > > >> [email protected]> wrote: > > >> > > >>> > > >>> > > >>> On Thu, Sep 29, 2011 at 12:01 AM, David Blevins > > >> <[email protected]>wrote: > > >>> > > >>>> > > >>>> On Sep 28, 2011, at 3:36 PM, Jonathan Gallimore wrote: > > >>>> > > >>>> > When I hacked up the Remote with zip adapter I intended to > > >>>> > merge it into the remote adapter - along the lines of: check to > > >> see if > > >>>> TomEE > > >>>> > is running on the port specified in arquillian.xml. If it is, just > > >>>> deploy > > >>>> > straight to it. If not, go grab the zip and use that. Does that > > >> sound > > >>>> like a > > >>>> > reasonable idea? > > >>>> > > >>>> Very reasonable. That's what the itests have done for years, the > > >> CDI TCK > > >>>> does and the Java EE TCK setup does. > > >>>> > > >>>> It's pretty easy to have the rule of "if you don't want us > > >> to start a > > >>>> server, make sure a server is started" > > >>>> > > >>> > > >>> Cool, I'll get that done. > > >>> > > >> > > >> I've extended the remote adapter to allow this. If you specify > something > > >> like (note the 1.0.0-beta-1 OpenEJB version and no Tomcat version): > > >> > > >> <arquillian > > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > >> xsi:schemaLocation="http://jboss.org/schema/arquillian > > >> http://jboss.org/schema/arquillian/arquillian_1_0.xsd";> > > >> <container qualifier="tomee" default="true"> > > >> <configuration> > > >> <property > > >> name="dir">/tmp/arquillian-apache-tomee</property> > > >> <property name="httpPort">9080</property> > > >> <property name="stopPort">9005</property> > > >> <property name="tomcatVersion"></property> > > >> <property > > >> name="openejbVersion">1.0.0-beta-1</property> > > >> </configuration> > > >> </container> > > >> </arquillian> > > >> > > >> if nothing is running on port 9080 we'll download TomEE, unzip it, > start > > it > > >> and use that for the test. > > >> > > >> If you changed the OpenEJB and Tomcat versions to, say: > > >> > > >> <property > > >> name="tomcatVersion">7.0.21</property> > > >> <property > > >> name="openejbVersion">4.0.0-beta-1</property> > > >> > > >> We'd download Tomcat and the OpenEJB.war, set that up, and use that > > instead. > > >> So we should be able to use this to test against Tomcat 5.5/6 with > > OpenEJB. > > >> > > >> I quite like this, but it would be great to get any feedback. > > >> > > >> > > >>> > > >>> > > >>>> > > >>>> > That leaves the embedded-with-war adapter as something that might > > >> seem a > > >>>> bit > > >>>> > odd. Currently I can't get it to run correctly, but that might > > >> be > > >>>> something > > >>>> > wrong with my machine. What's people's opinion of this > > >> method? Should we > > >>>> > drop this, or is it a useful adapter to hang on to? > > >>>> > > >>>> My impression is I would never ever advise a user to use it. That > > >> said, > > >>>> it's an absolutely fabulous way for us to test the drop-in-war > > >>>> functionality. Well, almost fabulous... the real world scenario is > an > > >>>> existing Tomcat install, not an embedded one. > > >>>> > > >>>> Either way, if we say to people "you can do this and it > > >> works!" having an > > >>>> adapter for it us a must. Especially if we get things to the point > > >> where we > > >>>> can easily reuse the full set of tests on each adapter. At that > point > > >> we > > >>>> just need to hook up each adapter with a buildbot builder and > suddenly > > >> we > > >>>> have a dreamlike level of testing for the various features we offer. > > >>>> > > >>> > > >>> We shouldn't have any issues getting the tests to run on all the > > >> adapters. > > >>> Worst case we can use Maven profiles and run the tests against the > > embedded > > >>> adapter by default, and you just switch profile to use the other > modes. > > The > > >>> buildbot builders can then presumably be setup with the necessary > > profile > > >>> switch in their build. > > >>> > > >>> I was thinking it would be cool to try and extend either the test > suite > > or > > >>> the Arquillian test runner somehow so the test then runs against all > > the > > >>> adapters in one go. > > >>> > > >>> I was going to do the Maven profile bit first, as that should be > > reasonably > > >>> straightforward, and then take it from there. > > >>> > > >>> > > >> > > >> I've done some refactoring around the Arquillian test suite, so the > > tests > > >> now run against both adapters. Currently we have ~6 failures and 2 > > errors > > >> for both adapters, and it should be the same tests in both cases. We > > >> currently run 82 tests. > > >> > > >> This was a pretty bug refactor - it seemed like things worked well in > > the > > >> embedded case, because everything is right there on the classpath. > > Running > > >> remotely a lot of tests failed as they relied on the test or junit > being > > >> available from the app being tested. I've separated the inner classes > > out, > > >> divided things up into packages and tried to move a couple of methods > to > > >> trim what would need to be added to the Shrinkwrap archives. We still > > need > > >> junit in a couple of cases, so in a couple of places we add that in as > a > > >> lib. Hope that's all ok. There's probably some duplicate classes we > > >> could > > >> chop out. > > >> > > >> Running the tests can be done by running the test Maven goal in the > > >> arquillian-tomee-tests module. Choosing which adapter to use is done > by > > >> enabling a Maven profile. By default we run against the embedded > adapter > > >> (arquillian-tomee-embedded). Doing a 'mvn -Parquillian-tomee-remote > > clean > > >> install' will build and test against the remote adapter. If you're > using > > >> an > > >> IDE plugin such as m2e, you should be able to specify the desired > Maven > > >> profile in your IDE settings and the tests should run straight from > the > > IDE > > >> (works for me in Eclipse) - please shout if you have trouble, I'll be > > more > > >> than happy to help! > > >> > > >> Jon > > >> > > >
