July 15, 2011 
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
July 15, 2011 [00:01:30] *** bobmcw has quit IRC [00:08:23] *** johnament has joined #jbosstesting [00:15:02] *** jose_freitas has joined #jbosstesting [00:48:58] *** jganoff has joined #jbosstesting [01:22:57] *** aaronwalker has joined #jbosstesting [01:51:37] *** rruss has quit IRC [02:06:36] *** OndraZizka has quit IRC [02:17:39] *** ianbrandt has quit IRC [02:25:16] *** ldimaggi has joined #jbosstesting [02:26:27] *** gastaldi has joined #jbosstesting [02:26:43] *** gastaldi has left #jbosstesting [02:54:53] *** k4ffee has quit IRC [02:55:01] *** kaffee has joined #jbosstesting [02:55:29] *** rruss has joined #jbosstesting [02:55:31] *** rruss has joined #jbosstesting [02:55:31] *** kaffee is now known as Guest64126 [03:01:52] *** rruss has quit IRC [03:22:48] *** Guest64126 has quit IRC [03:25:06] *** jose_freitas has quit IRC [03:26:52] *** k4ffee has joined #jbosstesting [03:40:40] *** gastaldi has joined #jbosstesting [03:43:53] *** gastaldi has left #jbosstesting [03:45:35] *** jganoff has quit IRC [03:47:16] *** rruss has joined #jbosstesting [04:21:22] *** bobmcw has joined #jbosstesting [04:26:13] *** rruss has quit IRC [04:32:13] *** gastaldi has joined #jbosstesting [04:32:18] *** gastaldi has left #jbosstesting [04:56:06] *** johnament has quit IRC [05:18:57] *** ldimaggi has quit IRC [05:26:49] *** stuartdouglas has quit IRC [05:29:58] *** stuartdouglas has joined #jbosstesting [05:30:38] *** OndraZizka has joined #jbosstesting [07:11:19] *** aslak has joined #jbosstesting [07:19:51] *** aslak has quit IRC [07:20:22] *** aslak has joined #jbosstesting [07:33:17] *** gastaldi has joined #jbosstesting [07:33:31] *** gastaldi has left #jbosstesting [07:51:12] *** ge0ffrey has joined #jbosstesting [07:52:35] *** stuartdouglas has left #jbosstesting [07:59:43] *** jharting has joined #jbosstesting [08:17:16] *** jhuska has joined #jbosstesting [08:27:47] *** OndraZizka has quit IRC [08:28:05] *** OndraZizka has joined #jbosstesting [08:29:02] *** NF117 has joined #jbosstesting [08:32:41] <NF117> Hello [08:34:36] <NF117> I try to test my application with Arquillian and Jboss Embeeded container. The entity manager in the programm are injected with persistence context anotation [08:35:34] <aslak> yea? [08:35:51] <NF117> I read in the documetation that there is no support for persistence context for Jboss Server in Alpha 5 [08:36:39] <aslak> NF117, yes and no.. it's not directly supported by Arquillian Enrichers them selves, but.. [08:37:19] <aslak> NF117, if your deployment is a CDI Bean Archive, the CDI Enricher will enrich with what ever CDI supports, and CDI can handle @PersistenceContext [08:38:32] <aslak> NF117, you can activate CDI by simply placing a empty beans.xml in your archive, depending on your type of deployment, either jar.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") or war.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml") [08:39:57] <NF117> ok I will try that [08:40:02] <NF117> thanks [08:43:07] *** mgoldmann has joined #jbosstesting [08:51:00] *** NF117 has quit IRC [09:24:02] *** maschmid has joined #jbosstesting [09:31:30] *** galderz has joined #jbosstesting [09:34:26] *** pil-sleep is now known as pilhuhn [09:35:24] *** kpiwko has joined #jbosstesting [09:37:58] *** Jaikiran has joined #jbosstesting [09:44:46] *** NF117 has joined #jbosstesting [09:45:19] <NF117> i have one more question [09:45:41] <NF117> how can I load the database driver in the embeeded container ? [09:46:51] <NF117> I use Postgres database [09:52:06] *** oskutka has joined #jbosstesting [09:52:58] *** lfryc has joined #jbosstesting [09:56:56] *** mumilove has joined #jbosstesting [09:57:17] <mumilove> Anybody who can help me out with some ssl problems? [10:21:56] *** NF117 has quit IRC [10:28:14] *** rruss has joined #jbosstesting [10:29:48] <mumilove> anyvody here have knowledge about jboss and ssl connections? [10:31:21] <aslak> mumilove, i would try #jboss [10:31:35] <mumilove> every time i try, i get an error [10:32:08] <mumilove> This is the only channel i can write to [10:35:48] <ALR> aslak: Yo [10:35:56] <ALR> aslak: I'm noticing that ARQ/AS7 is kinda...slow. [10:36:03] <ALR> Haven't yet dug in yet [10:36:07] *** rruss has left #jbosstesting [10:36:19] <ALR> https://github.com/ALRubinger/jboss-as-test-example [10:36:28] <ALR> On my machine, that's like 16s to run [10:36:37] <ALR> Of which server start is 3.5s [10:36:51] <ALR> Will start digging into that tomorrow [10:36:58] <ALR> G'niiiiigh, y'all. [10:37:19] <aslak> mumilove, you need to register with freenode [10:37:41] <aslak> mumilove, http://freenode.net/faq.shtml#userregistration [10:38:00] <mumilove> you are a god... totally newbi to irc.. [10:38:10] <mumilove> i hope it works [10:38:26] <aslak> ALR, i'll have a look, could be the one time package / deploy of the service [10:38:36] <ALR> aslak: I think it's more than that [10:38:48] <ALR> Looks like there's a few seconds before AS is even launched [10:39:02] <ALR> But yeah, the ARQ Service is taking some time [10:39:07] <ALR> It starts up OSGi. [10:39:10] <aslak> yea [10:39:19] <ALR> Which of course we could get around using another protocol. [10:40:09] <ALR> Just HYI [10:40:11] <ALR> *FYI [10:40:27] <aslak> ALR, if only it worked.. hehe [10:42:40] <mumilove> aslak.... THX DUDE:.. it works [10:42:58] <aslak> mumilove, :) [10:43:15] <ALR> mumilove: Welcome to the best way to waste time ever. [10:43:55] <aslak> ALR, how can you say that? this is where you get other ppl to do your work.. :) [10:43:58] *** lightguard_jp has quit IRC [10:44:16] <ALR> aslak: I didn't say I wasted *my* time. [10:44:24] <aslak> hehe [10:44:32] <ALR> But it's likely I'll now start to waste his! [10:44:46] <aslak> good point.. :) [10:45:05] <ALR> All I wanna do now, BTW, is work on SD [10:45:09] <ALR> That project is coooooooool. [10:45:26] <ALR> I feel like it's been awhile since I just did straight coding. [10:45:42] <aslak> mm hmm [10:46:18] <aslak> ALR, when do you think you can lock sd desc apis ? [10:46:59] <ALR> aslak: Tell me when you *need* 'em locked. [10:47:07] <mumilove> I'm used to helping people over forum... irc is new to me [10:47:26] <ALR> Locking without sufficient time to let things settle scares me. [10:47:27] <aslak> ALR, asap? [10:47:42] <ALR> aslak: How many cases are we using SD in ARQ? [10:47:57] <aslak> ALR, it's basically what we discussed earlier. either I hvae to rewrite/pull in the old ones into arq for the internal use, or we can lock sd [10:48:19] <ALR> aslak: But what about ARQ deployment of SD? [10:48:26] <ALR> That leaks out the user view. [10:48:46] <ALR> Which is why I ask how extensive the SD use in ARQ is. [10:49:18] <ALR> The less it's being used, the more attractive a temporary fork of SD stuff into ARQ/core-impl becomes, IMO [10:49:52] <aslak> ALR, arqs config module is a descriptor. and servlet protocol use it for descriptor manipulation [10:50:23] <aslak> the only userview leak is the Descriptor interface [10:50:32] <ALR> Descriptor interface is lockable. [10:51:10] <aslak> Descriptor interface is locked.. :) [10:51:14] <ALR> Yes. [10:51:25] <aslak> it's more the internals i'm worried about [10:51:32] <ALR> SD/impl you mean. [10:51:42] <aslak> specially arq-config, since that is actually a Descriptor imp [10:51:47] <ALR> Yes, those are alllllllll changing :) [10:51:58] <ALR> arq-config? [10:52:08] * ALR updates ARQ [10:52:10] <ALR> Curious [10:52:14] <aslak> reading parsing of arq.xml [10:53:01] <aslak> pulling in the needed parts from Node etc there is not to much of hassle [10:54:56] <ALR> aslak: This is in arquillian-core? [10:55:07] <aslak> yes [10:55:16] <ALR> I see it. [10:55:17] <ALR> Building. [10:59:37] <aslak> ALR, are you using nexus as well? [10:59:45] <ALR> aslak: ...for? [10:59:51] <aslak> downloading deps [11:00:23] <aslak> ALR, was just wondering if me both were.. could explain why it's so insanly slow [11:00:50] <ALR> aslak: Oh, I used it, but it finished quickly enough [11:00:57] <ALR> Though Nexus is having problems [11:01:06] <ALR> They even turned off browsing to try to help it [11:01:13] <aslak> yea, when is it not [11:01:19] <ALR> No kidding. [11:01:56] <ALR> Haha [11:02:02] <ALR> arquillian-config-impl-base [11:02:06] <ALR> Dep on SD-impl [11:02:16] *** maeste has joined #jbosstesting [11:02:20] <aslak> ALR, yea, as i said, it's a Descriptor impl [11:02:28] <ALR> Yep [11:02:33] <ALR> I'm seeing what I can do in there. [11:02:36] <ALR> One sec [11:02:55] <ALR> Ah I see. We're extending it, NodeProviderImplBase [11:02:57] <ALR> Etc [11:03:14] <ALR> Not just using it, but making new Descriptor types [11:03:24] <aslak> mm [11:03:36] <aslak> it's the Descriptor for arquillian.xml [11:03:56] <ALR> I gotcha. [11:04:04] <ALR> aslak: And where else? Servlet protocol? [11:04:08] <aslak> yea [11:06:37] <aslak> ALR, i guess i could use implement NodeProvider instead of extending NodeProvicderImplBase, and potensially move XMLExporter to SPI.. we could locl spi as well and we're good [11:07:00] <aslak> atleast for the arq-config part of it [11:07:39] <aslak> the protocols on the other hand use the WebAppDescirptor and ApplicationDescriptor APIs [11:08:07] <ALR> aslak: That;s exactly what I'm doing now. [11:08:15] <ALR> Trying to SPI-ize it. [11:09:26] <ALR> aslak: arquillian-protocol-servlet...I don't see any dep on SD-impl [11:09:36] <aslak> not impl, api [11:10:37] <aslak> it uses WebAppDescriptor and ApplicationDescriptor api classes from the unlocked sd-impl lib [11:12:16] <ALR> aslak: Also, might wanna remove the "build" module [11:12:21] <ALR> And unify that w/ arq-parent [11:12:31] <ALR> I did that for SW some time back. Made stuff easier. [11:12:50] <aslak> ALR, can't [11:13:05] <aslak> ALR, build has some internal depmgm and arq-parent as parent [11:13:14] <ALR> aslak: I don't see where it's doing that. Using API classes from the impl lib in servlet protocol. [11:13:17] <aslak> arq-bom has external depmgm and arq-parent as parent [11:13:32] <aslak> if build depmgm is moved to arq-parent, they are exposed via arq-bom [11:13:38] <ALR> Ah I see. ARQ BOM conflicts. Sure. [11:13:47] <ALR> SW has no BOM, as you know [11:13:55] <aslak> yea [11:14:20] <ALR> aslak: So again w/ protocol-servlet, where is the SD-impl usage? [11:15:06] <aslak> ALR, WebAppDescriptor and ApplicationDescriptor is in sd-impl [11:15:11] <aslak> not the package, but the lib [11:15:29] <aslak> sd-api only holds the Descriptor interface ++.. all descriptors are in impl [11:15:46] <ALR> I know. [11:15:57] <aslak> ServletProtocolDeploymentPackager [11:16:01] <ALR> I just don't see the usage of anything in SD-impl in protocol-servlet [11:16:35] <ALR> Ah, one sec [11:16:54] <ALR> I see where that's leaking in [11:17:03] *** mumilove has left #jbosstesting [11:17:13] <ALR> SD-impl coming into servlet-protocol via config-impl-base [11:17:20] <aslak> yea, just noticed [11:17:49] <aslak> should be declared in the servlet-protocol pom [11:18:37] <ALR> aslak: Any other SD-impl usage besides config and protocol-servlet? [11:19:07] *** alesj has joined #jbosstesting [11:20:14] <aslak> ALR, some examples and some testcases only (besides the Descriptor interface) [11:20:32] <ALR> OK. I don't think we care much about those [11:20:53] <ALR> So basically, to keep ARQ able to get SD upgrades, I think I should do: [11:21:13] <ALR> 1) SPI-ize as best we can stuff for arq-config [11:21:27] <ALR> 2) Copy SD-impl stuff into ARQ proper temporarily. [11:21:59] <ALR> And then when we can lock SD APIs, fix ARQ to use them [11:22:09] <ALR> That should isolate everything from user view [11:22:15] <ALR> And keep it all back-compat [11:22:17] <aslak> well, if we do 2, 1 is obsolete [11:22:42] <ALR> My guess is users are gonna wanna stay on 1.x as long as possible [11:23:05] <ALR> Unless you have other compelling reasons to force a major version upgrade and API breakage in ARQ? [11:23:44] <aslak> api won't change, but spi might .) [11:26:55] <ALR> aslak: OK, I think I have everything colored red. [11:27:06] <aslak> 1.5/1.6 [11:27:21] <ALR> aslak: Meaning no compile deps on SD-impl for the arq-config and protocol-servlet [11:27:37] <ALR> So in theory if I resolve the red by copying stuff temporarily, you're happy? [11:28:00] <ALR> And then we can let SD-API mature at its own pace properly? [11:28:27] <aslak> ALR, depends a bit on how you copy stuff but sure.. arq don't use desc internally which is fine.. [11:28:36] <ALR> (I think I'm going to rename SD-API to 2.0.0-alpha-1-SNAPSHOT) [11:28:44] <ALR> So that we can let the API mature. [11:29:01] <ALR> But the existing stuff that we locked in 1.0.x-beta we'll keep [11:29:10] <ALR> Just to let the new stuff change over time [11:29:13] <ALR> In alpha releases. [11:29:18] <ALR> Good plan? [11:29:41] <aslak> hmm.. well, the current beta-3 api should still not change tho [11:29:53] <ALR> aslak: The stuff in API now will stay. [11:29:57] <ALR> And not break. [11:30:06] <ALR> But new stuff we put in: WebAppDescriptor for example [11:30:08] <ALR> ....may. [11:30:16] <ALR> Hence going back into an Alpha state [11:30:31] <ALR> 2.0.0-alpha will be back-compat w/ 1.0.0-beta [11:30:50] <aslak> i mean, the user is the one that wants to control descriptors. arq has only one dep, the Descriptor interface. if the user start using 2.0-Alpha something and Descirptor if e.g. move or change, we're scrwed [11:30:51] <ALR> But 2.0.0-alpha-2 may not necessarily be back-compat w/ 2.0.0-alpha-1 [11:31:03] <ALR> ^^ See above example [11:31:27] <aslak> yea, as long as sd-api in it's current form stays, no prob [11:31:41] <ALR> 2.0.0-alpha-2 will be back-compat w/ 1.0.0-beta, but not necessarily w/ 2.0.0-alpha-1 [11:31:56] <aslak> right.. good [11:32:02] <ALR> Right, the locking I did at JBW was to preserve the minimal bit we'd rely upon. [11:32:07] <ALR> So we'll keep it. [11:32:11] <ALR> Cool. [11:32:14] <ALR> Then I'm to bed. [11:32:23] <aslak> oki.. sweet dreams [11:32:32] <ALR> Peace buddy. [11:37:51] *** ALR has quit IRC [11:43:20] *** ALR has joined #jbosstesting [11:43:38] <ALR> aslak: ARQ-514 [11:43:39] <jbossbot> jira [ARQ-514] Remove all compile-time dependencies upon ShrinkWrap Descriptors Impl Module [Open (Unresolved) Task, Blocker, Andrew Rubinger] https://issues.jboss.org/browse/ARQ-514 [11:43:43] <ALR> Make any notes you want there :) [11:43:47] <ALR> And I'm out! [11:43:51] * ALR waves bye. [11:44:00] *** ALR has quit IRC [11:49:28] *** mgoldmann is now known as mgoldmann|away [11:56:26] *** maeste has quit IRC [11:56:54] *** NF117 has joined #jbosstesting [12:15:00] *** jose_freitas has joined #jbosstesting [12:30:18] *** jose_freitas has quit IRC [12:34:18] *** NF117 has quit IRC [12:35:56] *** galderz has quit IRC [12:46:54] *** Jaikiran has quit IRC [12:48:54] *** maeste has joined #jbosstesting [12:50:39] *** Jaikiran has joined #jbosstesting [13:02:00] *** rruss has joined #jbosstesting [13:06:25] *** rruss has quit IRC [13:25:33] *** jose_freitas has joined #jbosstesting [13:28:02] <jose_freitas> morning [13:29:55] <aslak> jose_freitas, good morning! [13:34:29] <jose_freitas> super fast week huh? [13:36:30] <aslak> jose_freitas, yea, where did it all go [13:42:07] <jose_freitas> I wanted to get jsfunit update finished on wednesday hehehe. I'll try to finish it today [13:42:24] <jose_freitas> jsfunit-arquillian [13:42:47] <aslak> :) [13:44:59] *** galderz has joined #jbosstesting [14:29:17] *** aaronwalker has quit IRC [14:35:00] <aslak> kpiwko, seen this thread: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003126.html ? [14:35:54] <kpiwko> aslak: nope, as7-dev mailing list is to verbose for me to track it every day [14:39:24] <aslak> kpiwko, not tracking it either, but it was addressed to me as well.. :) [14:39:29] <kpiwko> :) [14:46:10] *** jhuska has quit IRC [14:51:19] *** jharting has quit IRC [15:00:49] *** aslak has quit IRC [15:01:20] *** aslak has joined #jbosstesting [15:32:07] *** mgoldmann|away is now known as mgoldmann [15:32:08] *** k4ffee has quit IRC [15:32:16] *** kaffee has joined #jbosstesting [15:32:41] *** kaffee is now known as Guest75802 [15:33:33] *** Guest75802 is now known as k4ffee [15:48:04] *** maeste has quit IRC [15:52:16] *** lfryc has quit IRC [15:57:12] *** lfryc has joined #jbosstesting [16:22:00] *** mbg has joined #jbosstesting [16:22:33] *** maeste has joined #jbosstesting [16:37:16] <kpiwko> hi aslak! [16:37:49] <aslak> kpiwko, heya [16:37:53] <kpiwko> aslak: can you please create openshift-1.0.0.Alpha1 version in ARQ project? :) [16:38:07] <aslak> kpiwko, yes of course [16:38:43] *** oskutka has quit IRC [16:39:31] <aslak> kpiwko, express only? [16:39:53] <kpiwko> aslak: at the moment, I'm working on Express only [16:40:23] <aslak> kpiwko, v. created [16:40:47] <kpiwko> aslak: thanks [16:40:55] <aslak> kpiwko, how is it going? [16:41:29] <kpiwko> aslak: I was occupied by many other task, but I have a container which can deploy/undeploy any archive at the moment [16:41:57] <kpiwko> aslak: protocol stuff is missing though, so client mode only at the moment [16:41:58] <aslak> cool [16:42:18] <aslak> kpiwko, yea.. that's the tricky part.. [16:42:47] <kpiwko> aslak: yep, jgit is pretty usable although doc is very sparse [16:42:59] <aslak> kpiwko, user configure ip in conf, and we assume some names based on deployment name? or is deployment archive name ? [16:43:29] <aslak> let me try that again [16:43:48] <aslak> kpiwko, user configure ip in conf, and we assume context name based on deployment name? [16:44:08] <kpiwko> aslak: yes, something like that should work [16:44:21] <kpiwko> aslak: but no ip configuration should be necessary [16:44:58] <kpiwko> aslak: hostname can be reconstructed using bits which correlate to rhc-* commands [16:45:00] <aslak> aa, no, we have account name and know the domain right [16:45:47] <aslak> you can have multiple deployment pr domain right ? [16:45:48] <kpiwko> aslak: yes, http://pastebin.com/PGy53wHQ [16:46:10] <kpiwko> aslak: yes, you can [16:46:28] <aslak> cool, looks good :) [16:46:51] <aslak> kpiwko, only using jgit for the container ? [16:47:00] <kpiwko> aslak: yes [16:50:34] <kpiwko> aslak: I'm currently supporting AS7 cartridge only, but (un)deployment is written in so generic way that it should support ruby, php etc. out of the box as well [16:53:58] *** lfryc has quit IRC [16:58:56] *** lfryc has joined #jbosstesting [17:10:52] *** mgoldmann has quit IRC [17:11:53] *** Jaikiran is now known as Jaikiran|AFK [17:13:59] *** galderz has quit IRC [17:14:40] *** galderz has joined #jbosstesting [17:25:00] *** maschmid has quit IRC [17:27:38] *** kpiwko has quit IRC [17:31:50] *** Jaikiran|AFK is now known as Jaikiran [18:12:38] *** aslak has quit IRC [18:17:54] *** pilhuhn is now known as pil-afk [18:21:05] *** lfryc has quit IRC [18:24:20] *** lfryc has joined #jbosstesting [18:28:27] *** galderz has quit IRC [18:36:11] *** oskutka has joined #jbosstesting [18:44:58] *** lfryc has quit IRC [18:46:19] *** ALR has joined #jbosstesting [18:52:33] *** aslak has joined #jbosstesting [18:55:27] *** ianbrandt has joined #jbosstesting [19:01:15] *** alesj has quit IRC [19:09:50] *** rbattenfeld has joined #jbosstesting [19:15:50] <rbattenfeld> ALR: Sorry for asking again some git stuff. I thought I have understood what I have to do:-( but I don't [19:16:02] <ALR> Sure, go ahead [19:16:06] <ALR> It's tricky at first [19:16:27] <ALR> rbattenfeld: ^ [19:17:59] <rbattenfeld> ALR: How can I create a local branch of the SHRINKDESC-54 as discussed yesterday. git checkout -b SHRINKDESC-54 remotes/upstream/SHRINKDESC-54 does not work... [19:18:00] <jbossbot> jira [SHRINKDESC-54] Develop/split EE Spec and JBoss-specific descriptors in API / Impl Split [Open (Unresolved) Task, Major, Ralf Battenfeld] https://issues.jboss.org/browse/SHRINKDESC-54 [19:18:15] <ALR> rbattenfeld: Why doesn't it work [19:18:16] <ALR> ? [19:18:25] <ALR> What's: [19:18:31] <ALR> "git remote -v" say? [19:19:32] <rbattenfeld> upstream git at github dot com:shrinkwrap/descriptors.git (fetch) and ... [19:19:46] <rbattenfeld> upstream git at github dot com:shrinkwrap/descriptors.git (push) [19:19:53] <ALR> OK, that looks right [19:20:09] <ALR> So when you say "it doesn't work", what is happening? [19:20:47] <rbattenfeld> The error is: fatal: git checkout: updating paths is incompatible with switching branches. [19:21:47] <ALR> Oh [19:21:49] <rbattenfeld> and second line is: Did you intend to checkout 'remotes/upstream/SHRINKDESC-54' which can not be resolved as commit? [19:21:50] <jbossbot> jira [SHRINKDESC-54] Develop/split EE Spec and JBoss-specific descriptors in API / Impl Split [Open (Unresolved) Task, Major, Ralf Battenfeld] https://issues.jboss.org/browse/SHRINKDESC-54 [19:21:51] <ALR> I know what's up [19:22:03] <ALR> rbattenfeld: "git checkout" is a local-only operation [19:22:27] <ALR> rbattenfeld: Your local repo doesn't yet know that stuff's changed in the remote repo for upstream [19:22:46] <ALR> The way you bring in new changes from a remote is: [19:22:49] <ALR> "git fetch" [19:23:05] <ALR> But that doesn't affect your local workspace. Just puts the metadata in your git index. [19:23:08] <ALR> So you need to do: [19:23:13] <ALR> "git fetch upstream" [19:23:23] <ALR> Then you can do the checkout as described. [19:24:30] <rbattenfeld> ALR: Thanks a lot. You are a hero:-) [19:24:43] <ALR> Sweeeeet [19:24:54] <rbattenfeld> I mean : a hero :-) [19:25:44] <rbattenfeld> Super. Anything else I can do besides as we have discussed? [19:25:56] <ALR> rbattenfeld: Don't think so. [19:26:30] <rbattenfeld> ALR: Good, I will try to have something on Monday [19:43:11] <aslak> ALR, aaa, this is getting awesome!! [19:43:25] <ALR> aslak: What's up? [19:43:25] <aslak> JBIDE-8548 [19:43:26] <jbossbot> jira [JBIDE-8548] Support auto discovery of remote processes for debugging [Open (Unresolved) Feature Request, Major, Snjezana Peco] https://issues.jboss.org/browse/JBIDE-8548 [19:43:33] <ALR> Hehe [19:43:58] <aslak> have any process running in debug mode, have any resource open in eclipse, or the project selected or what not [19:44:27] <aslak> Shift + Alt + D + D <-- BOM, instant debug mode connected with source and the whole shebang setup as it should be [19:46:35] <ALR> Wow [19:46:38] <ALR> That's cool [19:47:02] *** ge0ffrey has quit IRC [19:48:45] <aslak> sorry, Shift + Ctrl + D + D :) [19:59:31] *** rbattenfeld has left #jbosstesting [20:05:48] *** Jaikiran has quit IRC [20:15:21] <aslak> ALR, btw.. the slowness in the jboss as example does not happen when ran in eclipse [20:15:34] <aslak> ALR, so i assume it's related to sw usage and classloader scanning [20:16:06] <ALR> aslak: When ran in Eclipse? That's when I see it. [20:16:18] <aslak> ALR, oh.. hmm [20:16:20] <ALR> And you shouldn't assume :) [20:16:35] <ALR> What CL scanning? [20:16:44] <aslak> ALR, assume is the start of coming to a conclusion [20:17:07] <aslak> ALR, addPackage [20:17:52] <ALR> I'm not explicitly going through addPackage. Maybe something else would trigger it. [20:18:09] <ALR> I may add some timings before the new process is launched [20:18:41] <ianbrandt> aslak, I notice annotations such as @org.jboss.arquillian.core.api.annotation.Inject in Arquillian code. Why not Weld and @javax.inject.Inject, or put differently could you point me to a doc or give the 50,000' view of CDI use in Arquillian? I tried to use @org.jboss.arquillian.core.api.annotation.Inject for constructor injection of a blank final field, but it's not supported. [20:19:18] <ALR> aslak: Hehe, I just did a release for something in AS6. 6, I tell you! [20:21:08] <aslak> ALR, arq internally use sw a lot, and has addPackage multiple locations [20:21:26] <aslak> ianbrandt, it's not using CDI at all.. that's the 50.000 overview.. :) [20:21:36] <ALR> aslak: Before container launch? [20:22:17] <aslak> ALR, before launch? [20:22:25] <ALR> Start. [20:22:36] *** pgmjsd has joined #jbosstesting [20:22:54] <aslak> ohh, hmm.. maybe i missunderstood the hang, thought it was after container start and to first deploy [20:23:48] <aslak> ianbrandt, where are you trying to inject ? [20:24:02] <aslak> ianbrandt, basically only Field injection is supported on Observers and Services [20:24:17] <aslak> ianbrandt, via Instance<Type> [20:25:00] <aslak> ianbrandt, to 'Produce', use @Application|Container|Suite|Test|ClassScope InstanceProducer<Type>.set(Type) [20:25:41] <aslak> ianbrandt, @Inject Event<Type>.fire() to fire events, InstanceProducer.set also trigger events of that type [20:26:38] <aslak> on thigs registered as Observers, any method with the first arg with a @Observes Type, will get call backs on event.fire(Type) [20:26:48] <ianbrandt> aslak, I was just looking to start generalizing and decoupling some code in TomcatContainer. I saw "@Inject @DeploymentScoped private InstanceProducer<StandardContext> standardContextProducer;" and thought I was looking at a stripped down CDI implementation. [20:27:17] <aslak> ianbrandt, parameters coming after @Observers work as a 'filter', if those types exist in the active context you will get the callback, [20:27:50] <aslak> so if, Instance<MyType>.get != null, method(@Observes SomeEvent, MyType my) will be called [20:28:42] <aslak> it's cdi like, but not competable.. :) [20:29:46] <aslak> the arq core api / spis are missing proper doc, it's on my list [20:30:13] <aslak> got a arq internals talk coming up so.. i'll find some time for that.. hehe [20:34:40] <ianbrandt> aslak, Excellent. Thanks for the overview. I pushed an ugly but working Tomcat 7 container to my branch btw. I tried switching to Servlet 3.0 protocol, but it was failing on some can't get something or other from ProtocolMetaData. ;) I didn't dig into it, but instead reverted to 2.5 and started reworking to the new Tomcat 7 embedded API instead. I hope to have a push for that soon, after which I'll revisit 3.0. [20:35:33] <aslak> ianbrandt, does tomcat 7 support web-fragments ? [20:35:56] <ianbrandt> aslak, According to the box it does. [20:36:08] <aslak> ianbrandt, hmm, that's the difference [20:36:18] <aslak> between servlet protocol 2.5 and 3.0 [20:36:30] <aslak> 2.5 will alter web.xml, 3.0 will add a lib wiht web-fragments [20:37:28] <aslak> ianbrandt, shouldn't change how they are registered in tomcat tho, the the same 'protocol' creation code should work.. i mean, it's still just a Servlet [20:37:39] <aslak> ianbrandt, possible it's not being deployed properly [20:38:47] <ianbrandt> aslak, I captured the archive and noticed it was missing the ServletRunner classes and such (had the enrichment libs though). I had just as much to do on the API upgrade, so I just switched to that. [20:40:03] <aslak> ianbrandt, no arquillian-protocol.jar in WEB-INF/lib ? [20:42:52] <jose_freitas> aslak: have you worked with jsfunit? [20:43:06] <aslak> jose_freitas, not as a user.. :) [20:43:34] <aslak> jose_freitas, but i have fixed some issues and implemented the arq bits etc [20:44:02] <jose_freitas> hm [20:44:10] <jose_freitas> I'm stucked with a test [20:44:33] <jose_freitas> it seems that the arquillian extension is providing everything it should provide [20:44:44] <jose_freitas> but something bad happens when generating a response [20:44:49] <jose_freitas> for a submit click for example [20:45:08] <aslak> jose_freitas, exception? [20:45:16] <jose_freitas> npe [20:45:24] <aslak> where [20:45:32] <jose_freitas> but it's not helping to much, it happens when parsing the response [20:45:38] <jose_freitas> but the response is not null [20:46:00] <ianbrandt> aslak, Hmm, WAR is gone. I'll get back to it after the Tomcat API change and let you know if I'm still having the issue. [20:54:29] <jose_freitas> aslak: http://pastebin.com/fsrNkpq3 [20:55:52] <jose_freitas> when debugging the cause variable itself is null [20:57:32] <aslak> jose_freitas, hmmm.. do you see the response in output? [20:58:11] <aslak> jose_freitas, jsfunit does create a PageCreator or similar for htmlunit if i remember correctly.. could be something there [20:58:26] <jose_freitas> yes [20:59:13] <jose_freitas> yes for creating pageCreator [20:59:59] <aslak> cookies.. hm.. there was something with cookie when i was upgrading it last time. hmm, what was it.. [21:00:14] <jose_freitas> I removed [21:00:32] <jose_freitas> there's just a submit in this test [21:00:41] <jose_freitas> I thought it could be something cookie related [21:02:01] <aslak> jose_freitas, do you always get it ? [21:02:16] <jose_freitas> yes [21:03:18] <aslak> jose_freitas, i remember now, partly.. i think we have a similar issue on and off with one of the containers, where the wrapped catalina request is not being updated, so it has the old cookies etc [21:03:49] <aslak> hmm, but that was in the beginning of the request, the jsfunit cookie was never found and jsfunit facescontext facade was never created.. [21:04:02] <jose_freitas> not the case I believe [21:04:06] <aslak> no [21:04:37] <aslak> jose_freitas, i would post on the jsfunit form [21:04:53] <aslak> http://community.jboss.org/en/jsfunit?view=discussions [21:05:17] <jose_freitas> ok I'll do it [21:06:01] <jose_freitas> thanks [21:08:08] *** lightguard_jp has joined #jbosstesting [21:25:00] *** pgmjsd has quit IRC [21:28:45] <jose_freitas> aslak: http://community.jboss.org/thread/169507 [21:29:35] *** pgmjsd has joined #jbosstesting [21:30:47] <aslak> :) [21:31:11] <jose_freitas> I hope that I provided enough info to help stan helping me [21:31:13] <aslak> see if Stan wakes up [21:37:14] <aslak> ALR, one reason for a bit of a lag there is it uses the modelclient to check if the server is up before it tries to start it. [21:37:31] <ALR> Iiinteresting. [21:37:36] <aslak> that's about 5 sec or so [21:37:46] <ALR> Now that would explain a lot. [21:37:50] <ALR> In the managed container, eh? [21:38:02] <aslak> yea [21:38:09] <ALR> aslak: How do you feel about killing that? [21:38:11] <aslak> isServerStarted [21:38:43] <aslak> it should check somehow, but a simple URL connect should do, not sure what the ModelCLient is doing [21:39:21] <aslak> currently the managed container connects to a running instance if one exists, which it shouldn't [21:39:28] <ALR> Yeah [21:39:33] *** dblevins has quit IRC [21:39:45] <aslak> it seems to fail to start it's own process, not catch it, get a AddressBind issue, but keeps going against the other server just as fine [21:40:20] <ALR> aslak: You mean this guy: ? [21:40:21] <ALR> https://github.com/ALRubinger/jboss-as/blob/master/arquillian/common/src/main/java/org/jboss/as/arquillian/container/CommonDeployableContainer.java#L65 [21:40:36] *** mhuniewicz has joined #jbosstesting [21:40:41] <mhuniewicz> hi aslak [21:40:53] <aslak> ALR, java.net.ConnectException: Could not connect to remote://localhost.localdomain:9999 in 5000ms. Make sure the server is running and/or consider setting a longer timeout by setting -Dorg.jboss.as.client.connect.timeout=<timeout in ms>. [21:40:59] <mhuniewicz> aslak, did you see the feedback on the issue I created (Shrinkwrap, hibernate). [21:41:00] <mhuniewicz> ? [21:41:10] <aslak> mhuniewicz, yea, ALR is on it [21:41:25] <ALR> mhuniewicz: I put some comments in place there. [21:41:36] <ALR> I think Hibernate should be fixing it [21:41:39] <ALR> I opened an issue [21:41:44] <mhuniewicz> aslak, someone suggested it may not be a legit issue. [21:41:47] *** jose_freitas has quit IRC [21:41:51] <mhuniewicz> ALR by the sound of it? [21:41:56] <ALR> Right. [21:42:00] <ALR> Ha, "Someone". :) [21:42:09] <ALR> http://t.co/FEIGQqe [21:42:11] <mhuniewicz> ALR, is that really a Hibernate problem? [21:42:21] <ALR> mhuniewicz: Link above. [21:42:24] <aslak> ALR, that guy, but in this call: https://github.com/ALRubinger/jboss-as/blob/master/arquillian/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L212 [21:42:49] <ALR> aslak: OK, great. Thanks. [21:43:32] <aslak> mhuniewicz, yes, it is a hibernate issue [21:43:41] <ALR> HHH-6442 [21:43:42] <jbossbot> jira [HHH-6442] JarVisitorFactory is reconstructing URLs without the URLStreamHandler association [Open (Unresolved) Bug, Major, Unassigned] https://hibernate.onjira.com/browse/HHH-6442 [21:43:53] <mhuniewicz> aslak, what about other JPA providers? [21:44:21] <aslak> if you need a Stream and you get fed a URL, 4fs just call url.openStream. stop mumbling around with recreating shit to your best effort [21:44:22] <ALR> mhuniewicz: Depends on what they're doing. [21:44:37] <ALR> mhuniewicz: Assuming they just use the URL we give them, it's fine [21:44:47] *** dblevins has joined #jbosstesting [21:44:58] <mhuniewicz> ALR, so we don't know? I thought maybe someone has tried that. [21:45:22] <ALR> mhuniewicz: I'm not sure. It's tough to track what people are doing in downstream projects. [21:45:29] <ALR> But it's definitely not an ARQ issue. [21:45:46] <ALR> You could make the case that ShrinkWrap could do things to help avoid the issue in the first place [21:45:56] <ALR> But really the bug is in Hibernate in this case, IMO [21:46:18] <ALR> For not using the URL we give them, and instead trying to reconstruct it and dropping the URLStreamHandler association [21:47:09] <mhuniewicz> ALR, I see. [21:48:00] <aslak> ALR, lol.. so if you want to speed up as7 managed container, start another instance first.. ;) [21:48:11] <ALR> aslak: Baaahaha. [21:48:56] *** jose_freitas has joined #jbosstesting [21:49:30] <mhuniewicz> aslak, how are we looking in terms of incorporating this @PersistenceContext in Arquillian? [21:49:45] <mhuniewicz> ALR, I'll upvote this issue. [21:50:28] <ALR> mhuniewicz: Basically I'll ask Emanuel to explain if he had any reason for doing it that way [21:51:03] <mhuniewicz> ALR, cheers. [21:51:21] <ALR> mhuniewicz: Do you ever build HIbernate, BTW? [21:51:30] <ALR> I get some failures, but I'm not familiar w/ Gradle [21:51:39] <ALR> So figuring out what they mean is a bit of an issue. [21:51:43] <mhuniewicz> ALR, I never did, nuh uh. [21:51:48] <ALR> k [21:51:53] <mhuniewicz> What's it saying? [21:53:18] <ALR> A problem occurred evaluating root project 'buildSrc'. [21:53:19] <ALR> Cause: Could not find method mavenLocal() for arguments [] on root project 'buildSrc'. [21:53:27] <ALR> Just asked sebersole in #hibernate-dev [21:53:34] <ALR> So we'll see if he comes back and has some ideas. [21:54:16] <mhuniewicz> Gradle's on my list of things to look into. [21:54:18] <mhuniewicz> :) [21:56:14] *** maeste has quit IRC [22:11:01] <aslak> mhuniewicz, gotta have a chat with Alesj, the Weld lead.. just to see his thoughts on it [22:12:28] <mhuniewicz> aslak, cool. What about other containers? [22:13:08] <aslak> mhuniewicz, which ? [22:13:44] <mhuniewicz> aslak, I can't remember exactly; I asked you about it the other day, I think you said there are some more apart from Weld. [22:14:45] <aslak> of the pure cdi types, there is weld and openwebbeans [22:15:00] <mhuniewicz> So I guess openwebbeans? [22:17:05] <aslak> mhuniewicz, you'll need to investigate.. openwebbeans has a lot of plugins/extension etc, they might support it already with the correct dep added [22:17:44] <mhuniewicz> aslak, I see. From my egoistic point of view it's Weld that's important. :) [22:17:53] <mhuniewicz> When do you expect you'll know something from Alesj? [22:19:07] <aslak> mhuniewicz, we can just ask him when he drops by.. he's normally here.. :) [22:19:53] <mhuniewicz> Let's see if I can summon him with my thoughts. [22:20:03] <mhuniewicz> Alesj, appear now. [22:20:39] <aslak> :) [22:20:52] <mhuniewicz> Now. [22:21:02] <mhuniewicz> Oh well. :) [22:26:03] <jose_freitas> aslak: just saw the output content of the response [22:26:05] <jose_freitas> and it seems fine [22:27:19] <aslak> jose_freitas, you see the headers as well= [22:27:20] <aslak> ? [22:27:49] <jose_freitas> now, I saw just the html content [22:28:08] <jose_freitas> http://community.jboss.org/message/615564 [22:28:16] <jose_freitas> webResponse.getContentAsStream() [22:33:29] <aslak> hmm [22:48:30] *** bleathem has quit IRC [22:49:56] <aslak> ALR, you know anything about UserTransaction lookup in as7 ? [22:50:07] <ALR> Nope [22:50:14] <ALR> Likely JNDI somewhere [22:50:26] <aslak> yea, the old style doesn't seem to work: java:comp/env/org.jboss.as.test.example.TransactionTestCase/trans [22:50:47] <ALR> Def not [22:51:06] <ALR> aslak: I have a patch for Hibernate [22:51:42] <ALR> Instructions to reproduce ARQ-510 ? [22:51:44] <jbossbot> jira [ARQ-510] Can't load persistence.xml from ShrinkWrap Classloader using Hibernate [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/ARQ-510 [22:51:53] <aslak> mhuniewicz, [22:51:56] <aslak> ^ [22:52:49] <mhuniewicz> Yep [22:53:13] <mhuniewicz> ALR, just check out both projects from my github. [22:53:24] <mhuniewicz> https://github.com/m1key [22:54:12] <ALR> mhuniewicz: Huh? [22:54:21] <ALR> your fork of arquillian-container-weld ? [22:54:49] <mhuniewicz> ALR, yeah. The fork has my changes and the other one has a sample project that uses it. [22:54:55] <ALR> If we had a test case in ARQ proper we could validate the upstream release I'll put into Hibernate [22:55:50] <ALR> mhuniewicz: Instead of doing forks on forks, maybe you should bring in my version of HIbernate [22:55:55] <ALR> And see if it fixes stuff for you. [22:56:21] <ALR> That way we can validate my changes in your fork. [22:56:42] <ALR> And better coordinate upstream pushes [22:56:58] <mhuniewicz> ALR, I was told to fork. [22:57:08] <ALR> Yep, and you should. [22:57:18] <ALR> But if I fork off your fork, that confuses things a bit. [22:58:01] <mhuniewicz> That could be. What do you suggest? [22:59:30] <ALR> mhuniewicz: Fork this into yours: https://github.com/ALRubinger/hibernate-core/tree/HHH-6442 [22:59:30] <jbossbot> jira [HHH-6442] JarVisitorFactory is reconstructing URLs without the URLStreamHandler association [Open (Unresolved) Bug, Major, Unassigned] https://hibernate.onjira.com/browse/HHH-6442 [22:59:44] <ALR> mhuniewicz: Then update the versions of Hibernate you use, to take in this SNAPSHOT [22:59:49] <ALR> And see if it fixes your stuff. [23:00:04] <ALR> If it does, I'll issue a pull request to Hibernate upstream. [23:00:58] <mhuniewicz> ALR, okay. [23:01:43] <mhuniewicz> ALR, do you mean fork your fork? [23:02:19] <ALR> mhuniewicz: Take my fork/tree into your repo. [23:02:40] <ALR> s/repo/GitHub account [23:02:56] <mhuniewicz> Clone it? [23:02:59] <ALR> Yes. [23:03:05] <mhuniewicz> Ah okay. [23:03:35] <ALR> GitHub calls it "fork". The op under the hood is git clone. [23:04:00] <mhuniewicz> I'm supposed to git clone it locally, yeah? [23:04:42] <ALR> Yeah [23:06:27] <mhuniewicz> ALR, I understand you've been through the trouble already - how do I build it? : [23:06:29] <mhuniewicz> :) [23:06:49] <ALR> mhuniewicz: ./gradlew build [23:07:00] <aslak> ALR, really? [23:07:02] <ALR> Yes. [23:07:14] <aslak> ALR, thought you said it didn't work ? [23:07:24] <ALR> aslak: I was using my own (too old) version of gradle [23:07:42] <aslak> so you used ./gradle ? [23:07:59] <ALR> Also I had pulled at an unfortunate time and caught upstream at a point it didn't build. So re-pulled and all worked. [23:08:06] <ALR> aslak: ./gradlew [23:08:21] <aslak> hmm.. thought that was suppose to pull down the required v. [23:08:31] <ALR> No, before. [23:08:43] <ALR> Like I used /opt/gradle from my local [23:08:50] <ALR> And because it's on my PATH it picked that up [23:08:57] <aslak> mm [23:26:34] *** jose_freitas has quit IRC [23:39:06] <ALR> mhuniewicz: How's it looking? [23:39:25] <mhuniewicz> ALR, Gradle is taking its time. It's building and building. [23:43:12] <mhuniewicz> OK done. [23:43:19] <ALR> mhuniewicz: Verdict? [23:43:26] <mhuniewicz> ALR, so should I change my Hibernate deps to 4.0.0-SNAPSHOT? [23:45:20] <ALR> Ummm... [23:45:22] <ALR> One sec [23:45:50] <ALR> Yeah [23:45:58] <ALR> 4.0.0-SNAPSHOT [23:46:19] <ALR> mhuniewicz: After running ./gradlew install [23:46:23] <ALR> Not ./gradlew build [23:46:29] *** mbg has quit IRC [23:46:34] <ALR> "install" is needed to put it in your local M2 repo [23:47:17] <mhuniewicz> I did for hibernate-entitymanager and hibernate-core. However, hibernate-jpa-2.0-api (1.0.1.Final) and hibernate-validator (4.2.0.Final) will stay. Correct? [23:47:28] <mhuniewicz> I mean they will keep their current version/ [23:47:40] <ALR> I suppose. [23:47:41] *** aslak has quit IRC [23:47:50] <ALR> It's really only hibernate-entitymanager you wanna upgrade [23:48:13] <ALR> But I don't know if that mandates the need for cascading updates elsewhee [23:48:23] <ALR> So I'd upgrade the whole thing atomically. [23:49:21] <mhuniewicz> Hang on, I didn't install. [23:49:25] <ALR> Yup [23:52:44] <pgmjsd> when did you guys switch to Gradle? [23:53:20] <ALR> pgmjsd: This is Hibernate [23:54:07] <pgmjsd> ALR: i see. I'll have to ask Steve about that. :) [23:54:28] <pgmjsd> BTW, congrats on AS7 final. [23:54:32] <ALR> Thanks :) [23:55:13] <pgmjsd> It's hard to keep up with you guys these days. [23:55:22] <ALR> Yeah, Steve has a habit of bucking the trends to go for solutions he feels are superior. [23:55:28] <ALR> So Gradle. SLF4J, etc. [23:55:43] <ALR> Based on merit, not trends. [23:55:58] <ALR> Very commendable until I wanna build his stupid project. :P [23:56:20] <ALR> (Hehe, I poked fun @ him earlier. Ended up being an easy setup process) [23:56:36] <pgmjsd> Well, it's better than the old ANT madness. [23:57:06] <pgmjsd> neway... gotta go [23:57:12] <mhuniewicz> ALR, update. it does NOT throw that exception, BUT one of my three tests fails. [23:57:21] <ALR> mhuniewicz: Show test failures? [23:57:21] <mhuniewicz> "This function is not supported" [23:57:28] <ALR> Need full trace [23:58:22] <mhuniewicz> javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: This function is not supported [23:58:23] *** pgmjsd has quit IRC [23:58:24] <mhuniewicz> at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1344) [23:58:26] <mhuniewicz> at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277) [23:58:28] <mhuniewicz> at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:261) [23:58:28] <ALR> Pastebin [23:58:29] <mhuniewicz> at me.m1key.arquillian.repositories.JpaDogRepository.getDogByName(JpaDogRepository.java:20) [23:58:31] <mhuniewicz> at me.m1key.arquillian.repositories.JpaDogRepositoryInjectPcTest.shouldSaveAndReturnDogsName(JpaDogRepositoryInjectPcTest.java:77) [23:58:33] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [23:58:34] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [23:58:34] <ALR> Oh boy. [23:58:36] <mhuniewicz> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [23:58:37] <mhuniewicz> at java.lang.reflect.Method.invoke(Method.java:597) [23:58:39] <mhuniewicz> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [23:58:41] <mhuniewicz> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [23:58:42] <mhuniewicz> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [23:58:43] <mhuniewicz> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:246) [23:58:46] <mhuniewicz> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [23:58:48] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [23:58:49] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [23:58:51] <mhuniewicz> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [23:58:53] <mhuniewicz> at java.lang.reflect.Method.invoke(Method.java:597) [23:58:54] <mhuniewicz> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [23:58:56] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [23:58:57] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [23:58:59] <mhuniewicz> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [23:59:01] <mhuniewicz> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) [23:59:02] <mhuniewicz> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [23:59:04] <mhuniewicz> at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50) [23:59:06] <mhuniewicz> at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120) [23:59:08] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [23:59:09] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [23:59:10] <mhuniewicz> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [23:59:12] <mhuniewicz> at java.lang.reflect.Method.invoke(Method.java:597) [23:59:14] <mhuniewicz> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [23:59:16] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [23:59:18] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [23:59:19] <mhuniewicz> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [23:59:22] <mhuniewicz> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) [23:59:23] <mhuniewicz> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [23:59:25] <mhuniewicz> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:68) [23:59:26] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [23:59:28] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [23:59:29] <mhuniewicz> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [23:59:31] <mhuniewicz> at java.lang.reflect.Method.invoke(Method.java:597) [23:59:32] <mhuniewicz> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [23:59:34] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [23:59:36] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [23:59:37] <mhuniewicz> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:130) [23:59:39] <mhuniewicz> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:117) [23:59:40] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [23:59:42] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [23:59:43] <mhuniewicz> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [23:59:45] <mhuniewicz> at java.lang.reflect.Method.invoke(Method.java:597) [23:59:46] <mhuniewicz> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [23:59:47] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [23:59:49] <mhuniewicz> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:82) [23:59:51] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [23:59:52] <mhuniewicz> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [23:59:54] <mhuniewicz> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [23:59:55] <mhuniewicz> at java.lang.reflect.Method.invoke(Method.java:597) [23:59:57] <mhuniewicz> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [23:59:58] <mhuniewicz> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)