[00:04:57] *** bleathem has quit IRC
[00:06:07] *** jeand has quit IRC
[00:10:39] *** lightguard_jp has quit IRC
[00:16:09] *** aslak has quit IRC
[00:27:09] *** michaelschuetz has quit IRC
[00:35:25] *** johnament has joined #jbosstesting
[00:37:09] *** aamonten has joined #jbosstesting
[00:57:19] *** aamonten has quit IRC
[01:15:19] *** Elisha has quit IRC
[01:15:42] *** rruss has joined #jbosstesting
[01:15:48] *** Elisha has joined #jbosstesting
[01:20:27] *** bleathem has joined #jbosstesting
[02:18:25] *** rruss has quit IRC
[02:32:25] *** rruss has joined #jbosstesting
[02:59:58] *** michaelschuetz has joined #jbosstesting
[03:54:36] *** Elisha has quit IRC
[03:54:38] *** rruss has quit IRC
[03:54:38] *** timte has quit IRC
[03:57:44] *** Elisha has joined #jbosstesting
[04:00:38] *** rruss has joined #jbosstesting
[04:00:38] *** timte has joined #jbosstesting
[04:04:00] *** adriancole has quit IRC
[04:08:25] *** rruss has quit IRC
[04:16:09] *** lincolnthree1 has left #jbosstesting
[04:19:02] *** ldimaggi has quit IRC
[04:19:04] *** rruss has joined #jbosstesting
[04:19:08] *** rruss has joined #jbosstesting
[04:23:16] *** bgeorges has joined #jbosstesting
[04:46:21] *** lightguard_jp has joined #jbosstesting
[04:54:10] *** jdlee has quit IRC
[05:03:54] *** jdlee has joined #jbosstesting
[05:03:54] *** jdlee has joined #jbosstesting
[05:13:30] *** bleathem has quit IRC
[05:15:49] *** johnament has quit IRC
[05:16:53] *** jdlee has quit IRC
[05:32:12] *** jdlee has joined #jbosstesting
[05:36:01] *** rruss has quit IRC
[05:42:12] *** jdlee_ has joined #jbosstesting
[05:42:37] *** jdlee has quit IRC
[05:42:37] *** jdlee_ is now known as jdlee
[05:51:58] *** adriancole_ has joined #jbosstesting
[05:52:47] *** rruss has joined #jbosstesting
[05:59:11] *** jdlee has quit IRC
[06:34:45] *** adriancole_ has quit IRC
[06:58:18] *** bgeorges has quit IRC
[07:07:27] *** rruss has quit IRC
[07:11:59] *** michaelschuetz has quit IRC
[07:35:57] *** jharting has joined #jbosstesting
[07:57:21] *** alesj has joined #jbosstesting
[08:01:11] *** lightgua1d_jp has joined #jbosstesting
[08:01:33] *** lightguard_jp has quit IRC
[08:01:52] *** lightgua1d_jp has quit IRC
[08:02:13] *** lightguard_jp has joined #jbosstesting
[08:03:19] <nickarls> clear
[08:03:23] <nickarls> oops
[08:32:00] *** mgoldmann has joined #jbosstesting
[08:32:16] *** mgoldmann has joined #jbosstesting
[08:45:24] *** ge0ffrey has joined #jbosstesting
[08:46:04] *** oskutka has joined #jbosstesting
[08:46:56] *** maschmid has joined #jbosstesting
[08:47:04] *** Jaikiran has joined #jbosstesting
[08:50:56] *** lightguard_jp has quit IRC
[09:16:40] *** kpiwko has joined #jbosstesting
[09:32:28] *** mgoldmann has quit IRC
[09:32:53] *** mgoldmann has joined #jbosstesting
[09:40:34] *** wolfc has joined #jbosstesting
[09:59:41] *** michaelschuetz has joined #jbosstesting
[10:06:39] *** jeand has joined #jbosstesting
[10:14:19] *** michaelschuetz1 has joined #jbosstesting
[10:16:53] *** michaelschuetz has quit IRC
[10:24:12] *** lfryc has joined #jbosstesting
[10:31:38] *** maeste has joined #jbosstesting
[10:48:33] *** michaelschuetz has joined #jbosstesting
[10:50:42] *** michaelschuetz1 has quit IRC
[11:02:00] *** michaelschuetz1 has joined #jbosstesting
[11:04:02] *** michaelschuetz has quit IRC
[11:07:18] *** jharting has quit IRC
[11:12:53] *** pmuir has joined #jbosstesting
[12:06:55] *** jharting has joined #jbosstesting
[12:07:08] *** Tashtego has joined #jbosstesting
[12:09:43] *** ldimaggi has joined #jbosstesting
[12:17:00] *** Tashtego has quit IRC
[12:35:32] *** rruss has joined #jbosstesting
[12:39:28] *** aslak has joined #jbosstesting
[12:39:29] *** aslak has quit IRC
[12:39:29] *** aslak has joined #jbosstesting
[12:47:47] *** maeste has quit IRC
[13:00:20] *** maeste has joined #jbosstesting
[13:06:51] *** alesj has quit IRC
[13:08:06] *** maeste has quit IRC
[13:13:41] *** alesj has joined #jbosstesting
[13:21:17] *** maeste has joined #jbosstesting
[13:27:56] *** bleathem has joined #jbosstesting
[13:29:07] *** jdlee has joined #jbosstesting
[13:32:15] *** Tashtego has joined #jbosstesting
[13:36:29] *** kpiwko has quit IRC
[13:36:29] *** kpiwko1 has joined #jbosstesting
[13:37:27] *** kpiwko1 is now known as kpiwko
[13:39:45] <Tashtego> hi
[13:40:01] <aslak> Tashtego, good morning
[13:40:05] <aslak> kpiwko, hey
[13:40:20] <kpiwko> aslak: hi
[13:40:28] <aslak> kpiwko, do you have much un merged/pushed work on Drone? planing to do the repo split this weekend
[13:40:46] <kpiwko> aslak: no changes there since a5 release :)
[13:41:03] <aslak> kpiwko, excellent
[13:41:04] <aslak> :)
[13:45:07] <aslak> kpiwko, no work else where either?
[13:46:10] <kpiwko> aslak: actually not, I'm burdened with snowdrop last few weeks
[13:46:56] <aslak> kpiwko, at this point, nothings better. :)
[13:47:18] <kpiwko> aslak: :)
[14:21:46] *** rruss has joined #jbosstesting
[14:22:54] *** oskutka has quit IRC
[14:28:24] *** bgeorges has joined #jbosstesting
[14:39:57] *** bleathem has quit IRC
[14:48:40] *** jharting has quit IRC
[14:59:56] *** kpiwko has quit IRC
[15:30:37] *** bleathem has joined #jbosstesting
[15:32:49] *** bleathem has quit IRC
[15:33:04] *** bleathem has joined #jbosstesting
[15:42:45] *** ALR has joined #jbosstesting
[15:45:14] *** pmuir has quit IRC
[15:47:04] <wolfc> How does Arq what to package for shipment to the server? I've added a custom EventHandler / ArchiveGenerator, but it complains about missing classes that I reference from the TestCase.
[15:51:07] <alesj> wolfc: complains how / where / who?
[15:52:07] <wolfc> alesj, CNFE of bits I reference
[15:52:17] <ALR> wolfc: For AS7?
[15:52:26] <wolfc> ALR, yes
[15:52:34] <wolfc> I'm just fiddling
[15:52:35] <ALR> wolfc: Modular ClassLoading and visibility issues.
[15:52:41] *** pmuir has joined #jbosstesting
[15:52:41] *** pmuir has quit IRC
[15:52:41] *** pmuir has joined #jbosstesting
[15:52:54] <alesj> i don't see what ArchGen has to do here
[15:52:58] <alesj> wolfc: ^
[15:53:02] <wolfc> ALR, no, the regular ArchGen works
[15:53:22] <ALR> wolfc: Because if you're referencing it from the Test, it'd be on appCL
[15:53:28] <alesj> ah, then say so ? it's your hacks again ...
[15:53:28] <ALR> And something is filtering that out/
[15:53:31] <ALR> ?
[15:53:42] <wolfc> ALR, no, Arq ships everything to the server
[15:53:54] <wolfc> So somehow it is packaging more than it advertises :-)
[15:54:18] <wolfc> alesj, yes, I'm hacking away :-)
[15:54:32] <ALR> Hehe.
[15:54:50] <alesj> not to mention friday+bacos ...
[15:54:53] <alesj> i rest my case
[15:54:54] <alesj> :-)
[15:55:26] <wolfc> Maybe I should not try to add new annotations to Arq :-)
[15:57:17] <ALR> aslak: Ping.
[16:04:31] <wolfc> hmm, there are too many hacks in Arq
[16:04:42] <wolfc> I wanted to see if I could deploy a rar and a jar
[16:06:44] <aslak> ALR, hey
[16:06:54] <ALR> aslak: Yo.
[16:07:15] <ALR> aslak: https://github.com/jbosgi/arquillian/commits/1.0.0.Alpha4.SP9
[16:07:28] <aslak> mm
[16:07:52] <ALR> aslak: What needs to happen here ... is a review of every single one of these commits, and getting something functionally equivalent into ARQ upstream
[16:08:05] <ALR> The problem is that I see a whole bunch of things that I would reject.
[16:08:08] <ALR> For instance
[16:08:19] <aslak> ALR, yea, that was the initial problem as well
[16:08:23] <ALR> Relying on ShrinkWrap impls: https://github.com/jbosgi/arquillian/commit/0722db39785a8d6396a1e3fb1a1cb44e71876c1a
[16:08:24] <jbossbot> git [arquillian] 0722db3.. Thomas Diesler Set the TCCL to the Shrinkwrap Impl instead of the API
[16:25:18] *** pmuir has quit IRC
[16:26:03] *** pmuir has joined #jbosstesting
[16:31:17] *** timte has quit IRC
[16:33:16] *** tcunning has joined #jbosstesting
[16:38:35] *** ge0ffrey has quit IRC
[16:38:51] <tcunning> just started trying out arquillian 100-alpha-5, seeing a nosuchmethoderror on JavaArchive addAsServiceProvider?
[16:38:52] <tcunning> http://pastebin.com/Wh2p2L4z
[16:39:28] <aslak> tcunning, have you defined deps on ShrinkWrap somewhere in your project?
[16:39:58] <aslak> tcunning, or are you mixing Alpha4/Alpha5 versions?
[16:52:35] *** ge0ffrey has joined #jbosstesting
[16:53:54] *** jharting has joined #jbosstesting
[17:06:09] *** maschmid has quit IRC
[17:10:09] *** maeste has quit IRC
[17:21:24] <tcunning> aslak : doesn't look like it
[17:21:42] <tcunning> aslak : tried dependency:tree and i'm only seeing alpha5 getting pulled in
[17:22:21] <tcunning> is this something that would only happen in a alpha4/alpha5 mixup?
[17:52:07] <aslak> tcunning, well, the error is the wrong shrinkwrap v. is getting pulled in. alpha5 should pull in srinkwrap alpha-12
[17:53:17] <tcunning> hmmm
[17:53:18] <tcunning> [INFO] +- commons-httpclient:commons-httpclient:jar:3.1:test
[17:53:18] <tcunning> [INFO] +- org.jboss.arquillian.container:arquillian-jbossas-embedded-6:jar:1.0.0.Alpha5:compile
[17:53:18] <tcunning> [INFO] |  +- org.jboss.arquillian:arquillian-spi:jar:1.0.0.Alpha5:compile
[17:53:18] <tcunning> [INFO] |  |  \- org.jboss.arquillian:arquillian-api:jar:1.0.0.Alpha5:compile
[17:53:18] <tcunning> [INFO] |  |     \- org.jboss.shrinkwrap.descriptors:shrinkwrap-descriptors-api:jar:0.1.4:compile
[17:53:19] <tcunning> [INFO] |  +- org.jboss.shrinkwrap:shrinkwrap-impl-base:jar:1.0.0-alpha-11:compile
[17:53:34] *** pmuir has quit IRC
[17:55:15] <aslak> tcunning, aha, jboss embedded pulls in Alpha11 probably. i think you need to exclude shrinkwrap from the jboss-embedded-depchain
[17:55:29] <aslak> ALR, have you tested as embedded with sw 12 ?
[17:55:33] <tcunning> yup - just verifying it in the pom
[17:56:10] <ALR> Nope
[17:58:38] <tcunning> may be my maven cache.      the pom on nexus look right.
[18:06:11] *** lfryc has quit IRC
[18:11:30] *** alesj has quit IRC
[18:15:31] *** rruss has quit IRC
[18:24:29] *** Jaikiran has quit IRC
[18:26:45] *** michaelschuetz1 has quit IRC
[18:49:38] *** rruss has joined #jbosstesting
[19:02:50] <tcunning> aslak : so i removed my ~/.m2/repository/org/jboss, but i'm still seeing it
[19:03:12] <tcunning> here is where I can see it in the poms in my ~/.m2/repository :
[19:03:13] <tcunning> jbossas/jboss-as-component-matrix/6.0.0.20101110-CR1/jboss-as-component-matrix-6
[19:03:13] <tcunning> .0.0.20101110-CR1.pom:    <version.org.jboss.shrinkwrap>1.0.0-alpha-11</version.
[19:03:13] <tcunning> org.jboss.shrinkwrap>
[19:03:13] <tcunning> jbossas/jboss-as-component-matrix/6.0.0.Final/jboss-as-component-matrix-6.0.0.Fi
[19:03:13] <tcunning> nal.pom:    <version.org.jboss.shrinkwrap>1.0.0-alpha-11</version.org.jboss.shri
[19:03:14] <tcunning> nkwrap>
[19:04:42] <aslak> tcunning, exactly. jboss as embedded itself is pulling them in
[19:05:37] <tcunning> aslak - yup - just wasn't sure because it wasn't obvious when i was looking at the .pom on nexus
[19:05:47] <tcunning> aslak : file a bug?
[19:05:53] *** ge0ffrey has quit IRC
[19:06:00] <aslak> tcunning, well, it's not really a bug
[19:06:48] <aslak> not sure why maven resolves 11 over 12 tho
[19:07:47] <tcunning> aslak : shouldn't whatever is using this scope out shrinkwrap from the dependency? seems like this mismatch could happen later in future versions.
[19:09:27] <aslak> tcunning, that would be you i think
[19:10:07] <aslak> tcunning, the dep chain dep in the jbossas-embedded-6 contianer is set to provided.
[19:10:37] <aslak> it does import it as well under DependencyManagemnet, but that should effect the consumer of that pom
[19:11:09] <aslak> tcunning, so i believe it's the dependency in your pom on as depchain that pulls it in
[19:17:03] <aslak> ALR, ping
[19:19:21] <tcunning> aslak : true, but that's straight from the arq doc, as-6-embedded configuration section.   if you don't want a jira that's cool, no big deal.
[19:20:25] <aslak> tcunning, hmm, good point.. it could be a doc jira
[19:20:48] <aslak> but i don't understand why maven would resolve the older v.
[19:21:03] <aslak> tcunning, what does your pom look like?
[19:22:12] <tcunning> post a link soon as i update with the exclusions
[19:35:12] *** Tashtego has quit IRC
[19:54:55] *** jdlee has quit IRC
[20:34:05] *** jdlee has joined #jbosstesting
[20:34:05] *** jdlee has joined #jbosstesting
[20:43:47] *** michaelschuetz has joined #jbosstesting
[20:44:02] *** mgoldmann has quit IRC
[20:58:50] <ALR> aslak: Hey
[20:59:00] <ALR> Took a few hours.  Doing most of my work tonight.
[21:12:14] <dblevins> ALR: i assume there is there a tomcat arquillian provider right?
[21:12:46] <ALR> dblevins: Tomcat Embedded 6, yes.
[21:12:52] <dblevins> or maybe it doesn't matter, what I'm actually after is making provider for TomEE which is Tomcat based
[21:13:05] <dblevins> cool, can you point me at it?
[21:13:42] <ALR> dblevins: Go shopping: https://github.com/arquillian/arquillian/tree/master/containers
[21:13:46] <dblevins> :)
[21:22:00] <aslak> ALR, forgot what i was gonna ask..
[21:22:32] <ALR> aslak: Hehe
[21:23:26] <dblevins> so it looks like the main interfaces to implement are Configuration and DeployableContainer?
[21:24:12] <aslak> dblevins, correct
[21:24:53] <dblevins> then it appears that if you have a standalone container, you need some sort of AuxiliaryArchiveAppender to make the archive
[21:25:03] <dblevins> am I following correctly?
[21:25:20] <dblevins> s/standalone/remote/
[21:25:25] <aslak> dblevins, yea, you need that in Alpha5 to add incontainer Enrichment, like @Resource injection
[21:25:39] <aslak> TomEE is full EE ?
[21:25:44] <dblevins> web profile
[21:26:09] <dblevins> well, web profile + JMS and WS
[21:26:16] <aslak> right, so basically you can look at what the JBoss Remote 6 contianer does there then.. it included the ejb, resource and cdi enrichment
[21:27:04] <dblevins> the enrichment is basically for test injection via the remote container?
[21:27:13] <aslak> dblevins, got a url for tomee?
[21:27:36] <aslak> dblevins, injection in test instance when running in the container ye
[21:27:37] <dblevins> part of the openejb project, we don't have separate doc base for it yet
[21:27:48] <dblevins> oh ok
[21:28:00] <dblevins> but we do plain to try and separate it more
[21:28:20] <dblevins> people hit a mental block when they hear "ejb"
[21:28:34] <aslak> dblevins, how does it compare to.. i forget the same.. the other tomcat ee thinggy.. hehe
[21:28:37] <aslak> S something
[21:28:49] <dblevins> that dude forked our code
[21:28:50] <aslak> same/name
[21:28:55] <aslak> aa ok
[21:29:08] <aslak> and released before you ? :)
[21:29:11] <dblevins> it's disappointing
[21:29:19] <dblevins> his release is quite bad
[21:30:50] <aslak> dblevins, hmm, OpenEJB seems to be missing from the Apache index ? http://projects.apache.org/indexes/alpha.html#O
[21:31:11] <dblevins> hmm, thought we had a doap file there
[21:31:49] <aslak> dblevins, tomcat 7 as base?
[21:31:54] <dblevins> right
[21:32:10] <aslak> dblevins, have you added any remote deploy apis?
[21:32:36] <dblevins> jsr88, that's what we use to run the Java EE 6 TCK
[21:33:00] <aslak> mm
[21:34:42] <dblevins> we have non-jsr88 remote tool as well
[21:35:10] <dblevins> basically the jsr88 tool wraps an ejb that does the remoting
[21:35:13] <aslak> dblevins, we did have jsr-88 support in Alpha4, https://github.com/arquillian/arquillian/tree/master/containers/jsr88-remote-1.2
[21:35:43] <aslak> but dropped it because it was lacking deployment information we needed.. atleast as far as i could find
[21:36:33] <dblevins> i dislike jsr88 as well, so that's no shame :) but it might be a good starting point
[21:36:48] <dblevins> what was the info it lacked?
[21:37:23] <aslak> dblevins, it can give you a model of the Descrptors, but seemed to be lacking info about what was deployed
[21:38:05] <aslak> arq needs to know which context roots the wars were deployed, ips, servlet names, remote ejb end points
[21:38:20] <aslak> ports
[21:38:43] <dblevins> cool, that should be no trouble
[21:39:01] <dblevins> the remote deploy ejb we have returns an instance of our AppInfo tree
[21:39:10] <aslak> dblevins, right.. cool
[21:39:13] <aslak> that should do
[21:40:37] <aslak> dblevins, in your openejb junit runner, how do you do the injections? i was looking around in openejb code at one point at it seemed to be possible to construct a Injector based on the appInfo, but stopped cuz it seemed to be based on the context of the bean etc..
[21:40:58] <aslak> of A bean i should say
[21:41:23] <dblevins> right, i have some good code you could use in the openejb provider, let me grab it...
[21:41:29] <aslak> thanks
[21:42:23] <dblevins> most of this the openejb provider already does (last I saw) ...
[21:42:24] <dblevins> http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/junit/ApplicationComposer.java
[21:42:55] <dblevins> the neat little trick is deploying the test case class as an @ManagedBean, then using it's injector
[21:44:09] <aslak> dblevins, right, we have been discussing that as well. but hard to descide on what do deploy it as since we support 'everything'
[21:44:40] <ALR> Ah, didn't realize we were still discussing here :)
[21:44:49] <dblevins> :)
[21:44:57] <aslak> you snooze you loose.. :)
[21:45:04] <dblevins> aslak: not sure I followed the "everything" part
[21:45:31] <aslak> dblevins, support for the standard injection points is just 'some' of what arq supports..
[21:45:41] <dblevins> sure
[21:46:01] <aslak> dblevins, if we converted the TestClass into a EJB during deploy, we could only support what the EJBContainer supports
[21:46:42] <dblevins> we don't actually use it as an ejb, we just do that to get the full injection data
[21:47:05] <aslak> aa, right
[21:47:13] <dblevins> could just as easily have picked any other random injectable component
[21:47:20] <aslak> basically just tricking the container to setup the contexts etc
[21:47:25] <dblevins> exactly
[21:48:20] <aslak> yea, was wondering about doing that for jboss as well. basically being able to mark the testclas so that the internal deployment chain would handle it as a bean and setup the contexts..
[21:48:37] <dblevins> works great so far
[21:48:40] <dblevins> i'd recommend it
[21:50:04] <aslak> where it is most needed is of course where we can't do it.. like weblogic. who does not setup any contexts at all unless you are a bean and you use @EJB to refere to another ejb.. so your completely blind and can only support Remote ejbs
[21:50:26] <dblevins> right
[21:51:09] <dblevins> we do it with our little jaxb/info tree, but I you could ShrinkWrap the test case in as a bean I bet
[21:53:26] <dblevins> probably wouldn't make the actual remoting part any easier though
[21:53:48] <dblevins> but would be nice for getting the full support the embedded environment provides
[21:54:48] <dblevins> i tried to get an inject(Object) method on the EJBContainer interface...
[21:55:00] <dblevins> but it got shot down at the higher level
[21:55:50] <aslak> really? i proposed to ALR to add that as a JBossEJBContainer extension. makes no sense not to have it
[21:56:05] <dblevins> i agree
[21:56:28] <aslak> even want that for a general thing in EE7, lookup("java://Injector").injecto(instance)
[21:56:39] <dblevins> right
[21:56:44] * ALR definitely wanted that
[21:56:51] <dblevins> the trick I ended up with adding is..
[21:57:07] <ALR> Also handles to the EJB for create/remove, but in an EJB3-lookin way, not like EJB2.x homes
[21:57:07] <dblevins> context.bind("inject", instance)
[21:57:49] <dblevins> not as nice as an API class, but works without openejb-specific classes
[21:58:09] <dblevins> but i would still like an actual inject method
[21:59:34] <dblevins> often i'm tempted to make some neutral package where we could share such extensions
[21:59:50] <dblevins> can never think of a good package name though
[22:00:30] <dblevins> something like jex.ejb.embedded.EJBContainer.inject(Object)
[22:01:52] <dblevins> it's silly for it not to be there
[22:02:10] <dblevins> and if we both supported it, it would definitely get used and might get added
[22:04:45] <dblevins> ALR: on the create thing, i was thinking maybe javax.inject.Provider could work
[22:04:59] <dblevins> not quite right, but temptingly close
[22:05:53] <dblevins> if we had an actual Remove interface that all clients could use, that might be good enough
[22:06:14] <dblevins> Removable rather
[22:06:35] <dblevins> or maybe we just usurp Closable
[22:10:39] <ALR> dblevins: Nice.
[22:10:52] * ALR sorry, involved in some AS7 / ARQ chats/issues now
[22:10:57] <ALR> So switching is slow :)
[22:10:58] <dblevins> no worries
[22:20:01] *** ldimaggi has quit IRC
[22:53:31] *** bgeorges has quit IRC
[22:56:14] *** jharting has quit IRC
[22:57:38] *** bgeorges has joined #jbosstesting
[23:03:20] *** jeand has quit IRC
[23:34:35] *** tcunning has quit IRC
[23:53:18] <ALR> aslak: java.lang.RuntimeException: Arquillian has previously been attempted initialized, but failed. See previous exceptions for cause.
[23:53:18] <ALR> 	at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:80)
[23:53:26] <ALR> But no previous exceptions :)
[23:53:28] <ALR> I'm digging
[23:53:46] <aslak> ALR, one of the surefire reports should have a exception in it
[23:53:48] <stuartdouglas> generally when I see that the exception is in the first test of the run
[23:54:06] <ALR> aslak: No surefire logging, so OK.
[23:54:06] <aslak> yea, it normally fails on the first
[23:54:10] <ALR> stuartdouglas: yeah, it's on all in the run.
[23:54:21] <aslak> ALR, all but the first
[23:54:25] * ALR trying to upgrade TorqueBox
[23:54:29] <ALR> Oh I see
[23:54:43] *** wolfc has quit IRC
[23:54:43] <aslak> it refuses to run the test because a previousl attempt of initializing it failed, so trying again is not point
[23:54:54] <aslak> but we can't abort the whole run without a system exit so
[23:56:36] <aslak> it being BeforeSuite, basically the container has failed to setup/start most likely
[23:59:50] <stuartdouglas> would it be possible to store the exception and spit it out each time? Or store the test that it failed on, so you know which result to look at?





top