You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jonathan Gallimore <jo...@gmail.com> on 2011/09/29 00:36:31 UTC
Arquillian adapters
Hi,
I'm currently working in the Arquillian adapters for TomEE in the sandbox
area, specifically I'm:
- Adding the ability for the remote adapter to download either the straight
TomEE webprofile zip, or the TomEE+ zip, extract it and test against that
- Refactoring the adapters to eliminate common code (most of the modules
started as straight copies of each other)
- Setting up the tests so they all sit in one place, and are run against all
the variants of the adapter (Embedded, Remote etc etc) during the build.
I was wondering whether I could get people's thoughts on the adapters we
have. Currently we have:
1) Embedded: This is the fully embedded adapter. We bootstrap both Tomcat
and OpenEJB in the test, and we have just enough code to nudge the Tomcat
loader to make everything start up correctly.
2) Embedded with war: This adapter bootstraps Tomcat in the test, and uses a
small extension to the Maven functionality in Arquillian to grab openejb.war
and deploy it to give a "semi-embedded" TomEE setup. The idea here is to get
an embedded setup, but only requiring your classpath have the minimal set of
jars (about 4 for Tomcat I think).
3) Remote: This is fully remote - it only has the deploy and undeploy code
implemented, you have to start TomEE manually before you run your Arquillian
test.
4) Remote with zip: This is an extension to the remote adapter which will
use Arquillian's Maven feature to download the TomEE zip, extract it, and
boot it before doing the deploy.
Most Arquillian adapters for other app servers seem to have options 1 and 3
(Embedded and Remote) if I remember correctly, so it makes sense to have
both of these. 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?
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?
Any thoughts you have would be much appreciated!
Cheers
Jon
Re: Arquillian adapters
Posted by David Blevins <da...@gmail.com>.
On Sep 28, 2011, at 4:13 PM, Jonathan Gallimore wrote:
> 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.
That's a crazy idea! I like it. Sort of an "around the world" adapter.
-David
Re: Arquillian adapters
Posted by Jonathan Gallimore <jo...@gmail.com>.
+1
On Oct 16, 2011 11:34 PM, "Romain Manni-Bucau" <rm...@gmail.com>
wrote:
> about our arquillian adapters,
>
> do we drop arquillian-tomee-embedded-with-war ? (+1 for me ;))
>
> - Romain
>
> 2011/10/5 Jonathan Gallimore <jo...@gmail.com>
>
> > 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" <st...@yahoo.de> 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 <jo...@gmail.com>
> > >> To: dev@openejb.apache.org
> > >> Cc:
> > >> Sent: Wednesday, October 5, 2011 12:57 AM
> > >> Subject: Re: Arquillian adapters
> > >>
> > >> On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore <
> > >> jonathan.gallimore@gmail.com> wrote:
> > >>
> > >>>
> > >>>
> > >>> On Thu, Sep 29, 2011 at 12:01 AM, David Blevins
> > >> <da...@gmail.com>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
> > >>
> >
>
Re: Arquillian adapters
Posted by Romain Manni-Bucau <rm...@gmail.com>.
about our arquillian adapters,
do we drop arquillian-tomee-embedded-with-war ? (+1 for me ;))
- Romain
2011/10/5 Jonathan Gallimore <jo...@gmail.com>
> 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" <st...@yahoo.de> 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 <jo...@gmail.com>
> >> To: dev@openejb.apache.org
> >> Cc:
> >> Sent: Wednesday, October 5, 2011 12:57 AM
> >> Subject: Re: Arquillian adapters
> >>
> >> On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore <
> >> jonathan.gallimore@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> On Thu, Sep 29, 2011 at 12:01 AM, David Blevins
> >> <da...@gmail.com>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
> >>
>
Re: Arquillian adapters
Posted by Jonathan Gallimore <jo...@gmail.com>.
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" <st...@yahoo.de> 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 <jo...@gmail.com>
>> To: dev@openejb.apache.org
>> Cc:
>> Sent: Wednesday, October 5, 2011 12:57 AM
>> Subject: Re: Arquillian adapters
>>
>> On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore <
>> jonathan.gallimore@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 29, 2011 at 12:01 AM, David Blevins
>> <da...@gmail.com>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
>>
Re: Arquillian adapters
Posted by Mark Struberg <st...@yahoo.de>.
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 <jo...@gmail.com>
> To: dev@openejb.apache.org
> Cc:
> Sent: Wednesday, October 5, 2011 12:57 AM
> Subject: Re: Arquillian adapters
>
> On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
>
>>
>>
>> On Thu, Sep 29, 2011 at 12:01 AM, David Blevins
> <da...@gmail.com>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
>
Re: Arquillian adapters
Posted by Jonathan Gallimore <jo...@gmail.com>.
On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore <
jonathan.gallimore@gmail.com> wrote:
>
>
> On Thu, Sep 29, 2011 at 12:01 AM, David Blevins <da...@gmail.com>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
Re: Arquillian adapters
Posted by Jonathan Gallimore <jo...@gmail.com>.
On Thu, Sep 29, 2011 at 12:01 AM, David Blevins <da...@gmail.com>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.
>
> > 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.
>
> This "Tomcat + war" approach is a great way to setup buildbot to test
> "Tomcat 5.5 + war" and "Tomcat 6 + war"
>
> It's hard to describe how important this stuff is. Once it's in place, we
> won't be able to imagine life before it. :)
>
Glad its useful, I've certainly had a lot of fun working on it :)
Jon
Re: Arquillian adapters
Posted by David Blevins <da...@gmail.com>.
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"
> 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.
This "Tomcat + war" approach is a great way to setup buildbot to test "Tomcat 5.5 + war" and "Tomcat 6 + war"
It's hard to describe how important this stuff is. Once it's in place, we won't be able to imagine life before it. :)
-David