[01:07:30] *** alesj has quit IRC
[01:24:45] *** aaronwalker has joined #jbosstesting
[02:46:36] *** jganoff has quit IRC
[02:57:32] *** johnament has joined #jbosstesting
[02:59:21] *** ldimaggi has joined #jbosstesting
[03:20:44] *** bgeorges has joined #jbosstesting
[04:00:38] *** OndraZizka has quit IRC
[04:30:03] *** OndraZizka has joined #jbosstesting
[04:34:12] *** OndraZizka has quit IRC
[04:34:28] *** OndraZizka has joined #jbosstesting
[05:03:25] *** gastaldi has joined #jbosstesting
[05:04:25] *** gastaldi has left #jbosstesting
[05:30:36] *** ldimaggi has quit IRC
[05:59:20] *** johnament has quit IRC
[07:54:02] *** ianbrandt has quit IRC
[08:04:43] *** OndraZizka has quit IRC
[08:16:27] *** oskutka has joined #jbosstesting
[08:18:46] *** jharting has joined #jbosstesting
[08:43:13] *** kpiwko has joined #jbosstesting
[08:51:06] *** maschmid has joined #jbosstesting
[08:59:42] *** lfryc has joined #jbosstesting
[09:04:30] *** k4ffee has joined #jbosstesting
[09:09:57] *** mgoldmann has joined #jbosstesting
[09:21:17] *** Jaikiran has joined #jbosstesting
[09:31:07] *** bgeorges has quit IRC
[09:31:39] *** alesj has joined #jbosstesting
[09:36:05] *** pil-afk is now known as pilhuhn
[09:51:16] *** jeand has joined #jbosstesting
[09:52:38] *** jhuska has joined #jbosstesting
[10:04:33] *** stuartdouglas has quit IRC
[10:06:23] *** stuartdouglas has joined #jbosstesting
[10:14:42] *** maeste has joined #jbosstesting
[10:35:23] *** aaronwalker has quit IRC
[10:41:46] *** galderz has joined #jbosstesting
[10:59:30] *** aslak has joined #jbosstesting
[11:28:55] *** alesj has quit IRC
[11:35:30] *** Jaikiran has quit IRC
[11:36:31] *** kmalhi has quit IRC
[11:43:37] *** kmalhi has joined #jbosstesting
[11:45:58] *** Jaikiran has joined #jbosstesting
[11:47:37] *** alesj has joined #jbosstesting
[12:08:09] *** jeand has quit IRC
[12:09:22] *** pilhuhn is now known as pil-afk
[12:10:22] *** jeand has joined #jbosstesting
[12:31:12] *** lfryc is now known as lfryc_afk
[12:37:33] *** galderz has quit IRC
[12:44:57] *** pmuir has joined #jbosstesting
[12:45:02] <pmuir> aslak: ping
[12:47:31] *** pmuir has quit IRC
[13:12:20] *** lfryc_afk has quit IRC
[13:12:39] *** lfryc has joined #jbosstesting
[13:52:38] *** jose_freitas_aw has joined #jbosstesting
[13:53:03] *** jose_freitas_aw is now known as jose_freitas
[13:53:15] <jose_freitas> hey aslak! how was the fishing weekend?
[13:57:37] *** bgeorges has joined #jbosstesting
[13:59:09] *** jhuska has quit IRC
[13:59:49] *** galderz has joined #jbosstesting
[14:14:24] *** jhuska has joined #jbosstesting
[14:22:33] *** jhuska has quit IRC
[14:29:47] *** Jaikiran is now known as Jaikiran|AFK
[14:34:45] *** jhuska has joined #jbosstesting
[14:41:45] *** OndraZizka has joined #jbosstesting
[14:57:26] *** ldimaggi has joined #jbosstesting
[14:59:33] *** pil-afk is now known as pilhuhn
[15:19:25] *** aaronwalker has joined #jbosstesting
[15:31:42] *** jharting has quit IRC
[16:05:04] *** ALR has joined #jbosstesting
[16:32:08] <aslak> jose_freitas, heya, good times. :)
[16:32:14] <aslak> jose_freitas, how was the talk?
[16:33:27] *** rruss has joined #jbosstesting
[16:34:00] <jose_freitas> well
[16:34:04] <jose_freitas> not so good actually
[16:34:19] <jose_freitas> my linux didn't recognize the projector
[16:34:33] <jose_freitas> I had to boot it in linux
[16:34:48] <jose_freitas> and I don't have a workstation well setted there
[16:35:05] <jose_freitas> didnt have forge for example
[16:35:12] <jose_freitas> so I preferred not coding everything
[16:35:19] <aslak> mm, pitty
[16:35:23] <jose_freitas> and I showed a project that I used to practice
[16:35:42] <jose_freitas> but it was ok
[16:35:56] <jose_freitas> I was impressed that a lot of people don't use maven
[16:36:04] <jose_freitas> or other build tool
[16:36:42] <jose_freitas> a lot of questions around alternatives
[16:36:47] <jose_freitas> but people was interested
[16:36:59] <aslak> cdi alternatives ?
[16:37:03] <jose_freitas> no
[16:37:10] <jose_freitas> another alternatives to setup arquillian
[16:37:13] <jose_freitas> without maven
[16:37:25] <aslak> aa, right
[16:37:34] <aslak> we have some docs for ant+ivy and gradle
[16:37:36] <jose_freitas> I had to boot up in windows (said it was in linux)
[16:37:56] <jose_freitas> yes, but people have projects without any of those too
[16:38:16] <aslak> yea, ppl are strange in that way
[16:38:21] <aslak> :)
[16:38:41] <jose_freitas> but I could reach some people
[16:39:11] <jose_freitas> and the build worked on windows too
[16:39:19] <jose_freitas> so at least they saw arquillian in action
[16:39:21] <jose_freitas> and they liked
[16:40:33] <aslak> good
[16:43:21] <jose_freitas> I personally was a little disappointed
[16:43:40] <jose_freitas> cause I wanted to show live code so they could see that it's easy to write
[16:55:35] *** kpiwko has quit IRC
[16:55:40] *** kpiwko has joined #jbosstesting
[17:00:12] *** alesj has left #jbosstesting
[17:32:43] *** jbossbot has quit IRC
[17:32:55] *** jbossbot has joined #jbosstesting
[17:37:04] *** jbossbot has quit IRC
[17:37:16] *** jbossbot has joined #jbosstesting
[17:39:25] *** bleathem has joined #jbosstesting
[17:53:39] *** ianbrandt has joined #jbosstesting
[17:59:01] *** mumilove has joined #jbosstesting
[17:59:11] <mumilove> Hallo
[17:59:40] <mumilove> does anybody know about this warning: [WSDLDefinitions] Multiple WSDL bindings referrence the same interface:
[17:59:59] <mumilove> I have googled the shit out of it... but no luck
[18:00:18] <mumilove> anybody willing to give it a try?
[18:04:27] <aslak> ?
[18:10:36] <mumilove> jboss 5.1
[18:10:52] <mumilove> a webservice client
[18:11:11] <mumilove> using wsimport of a .net wsdl
[18:11:51] *** ALR has quit IRC
[18:11:55] <mumilove> when ever i try to connect, i get this warning... the response takes like 40 sec to return,...
[18:18:57] *** oskutka has quit IRC
[18:22:25] *** maschmid has quit IRC
[18:22:56] <bleathem> Any idea what this error means? :
[18:22:59] <bleathem> org.jboss.arquillian.spi.ArquillianProxyException: java.lang.AssertionError :  [Proxied because : Could not find suitable constructor]
[18:23:40] <mumilove> What scope does your constructor have?
[18:25:07] *** pilhuhn is now known as pil-dinner
[18:25:21] <bleathem> which constructor? This is a simple JSFUnit test, it clicks a button on a page, and checks that the next page is rendered
[18:28:03] <jose_freitas> hi bleathem
[18:28:15] <bleathem> hey jose_freitas
[18:28:32] <bleathem> have a good weekend jose_freitas? how did your presentation go?
[18:28:40] <bleathem> did the live demo work out?
[18:29:45] *** galderz has quit IRC
[18:32:32] *** Jaikiran|AFK is now known as Jaikiran
[18:32:52] *** kpiwko has quit IRC
[18:34:11] *** ALR has joined #jbosstesting
[18:36:30] <jose_freitas> nope
[18:36:38] <jose_freitas> my linux didn't recognize the projector
[18:36:54] <jose_freitas> and I had to boot on windows which didn't have enviroment setup
[18:36:59] *** jhuska has quit IRC
[18:37:00] <jose_freitas> but I made a build
[18:37:07] <jose_freitas> and they saw arquillian in action
[18:37:10] <jose_freitas> but not live code
[18:37:33] <bleathem> jose_freitas: bummer
[18:37:46] <jose_freitas> hehehe
[18:37:52] <bleathem> jose_freitas: sounds like a nice recovery though
[18:38:08] <jose_freitas> yes, I was impressive how I could handle it
[18:38:22] <jose_freitas> didn't get nervous at all
[18:38:47] <jose_freitas> bleathem: are you having problems with that test project?
[18:39:23] <bleathem> jose_freitas: good to hear
[18:39:37] <bleathem> jose_freitas: yeah, I didn't manage to get back to it over the weekend
[18:39:45] <bleathem> picking up now where I left off on friday
[18:40:05] *** mumilove has quit IRC
[18:40:11] <bleathem> I created a simple test, to verify that the arquillian/jsfunit setup is working
[18:40:16] <bleathem> and it appears its' not
[18:40:45] <jose_freitas> hm
[18:41:22] <jose_freitas> so you're ignoring the uiInputContainerTest and added another one as simple as possible and didn't run?
[18:42:27] <bleathem> yep
[18:42:42] <bleathem> cloning your repo right now, to try running the unmerged tests
[18:42:43] <jose_freitas> HM
[18:52:36] <aslak> bleathem, what's the next line on the stacktrace?
[18:56:25] *** bgeorges has quit IRC
[18:58:31] *** rbattenfeld has joined #jbosstesting
[19:00:00] <bleathem> aslak: 1 sec
[19:00:33] <rbattenfeld> ALR: Hi Andrew, how are you?
[19:01:19] <ALR> rbattenfeld: Hiya
[19:01:24] <ALR> Good, working on SW-193
[19:02:03] <ALR> I see you're in the pull queue for SD
[19:02:49] <rbattenfeld> Yes, I generated some additional descriptors, e.g. jboss5.1 and more
[19:03:32] <rbattenfeld> Are there additional descriptors required?
[19:05:06] <ALR> rbattenfeld: Do we yet have a chart on Wiki somewhere of what's covered vs/ TODO?
[19:05:14] <ALR> Just a simple table?
[19:05:34] <ALR> jbossbot: Helloo?  I just pushed something.
[19:05:52] <aslak> ALR, yea, he's been a bit moody lately
[19:07:19] <rbattenfeld> ALR: No, I don't think that we have such a table. DO you mean a table listing all the descriptors?
[19:07:27] <bleathem> aslak: https://gist.github.com/1076299
[19:07:32] <ALR> rbattenfeld: Yep.
[19:08:33] <jose_freitas> bleathem: did you clone my repo or chose-pick the commits?
[19:09:46] <rbattenfeld> ALR: I can create a new topic in the dev forum listing all the descriptors. Then we can discuss what make sense to generated additionally
[19:09:57] <bleathem> jose_freitas: initially cherry-picked the commits
[19:10:01] <ALR> rbattenfeld: Or even a Wiki page in the user's section
[19:10:02] <bleathem> just tried a clone now thow
[19:10:32] <ALR> Done: SHRINKWRAP-193
[19:10:34] <jbossbot> jira [SHRINKWRAP-193] Should be able to 'mount' a added jar [Resolved (Done) Feature Request, Major, Davide D'Alto] https://issues.jboss.org/browse/SHRINKWRAP-193
[19:10:58] <jose_freitas> and you got the same error?
[19:11:08] <bleathem> jose_freitas: different error on the clone
[19:11:11] <bleathem> jose_freitas: 1 sec
[19:15:13] <rbattenfeld> ALR: Good, a wiki page in the user's forum. Can I create such a wiki?
[19:15:29] <ALR> rbattenfeld: Absolutely!  It's for and by the community. :P
[19:15:50] <bleathem> jose_freitas: your fork gives me: org.jboss.arquillian.spi.ArquillianProxyException: java.lang.AssertionError : expected:<jose_freitas> but was:<null> [Proxied because : Could not find suitable constructor]
[19:16:17] <bleathem> jose_freitas: which looks to be the same exception actually
[19:16:26] <jose_freitas> yes
[19:16:36] <ALR> rbattenfeld: We gotta start merging your stuff to master
[19:16:43] <jose_freitas> well, what might be different is our jsfunit.jar
[19:16:43] <ALR> rbattenfeld: Things are diverging into forks.
[19:16:49] <jose_freitas> that's the only thing
[19:17:09] <bleathem> I build aslak's github jsfunit
[19:17:17] <bleathem> it hasn't changed since april
[19:17:20] <rbattenfeld> ALR: That wood be cool.
[19:17:20] <bleathem> jose_freitas: ^
[19:17:28] <jose_freitas> right
[19:17:33] <ALR> rbattenfeld: You feel OK that it's stable enough?
[19:17:38] <ALR> rbattenfeld: Criteria are this:
[19:17:47] <ALR> 1) The API isn't broken in terms of back-compat
[19:17:55] <ALR> 2) All tests that now pass in master will continue to pass
[19:17:57] <aslak> bleathem, the Original text of the Error is null. So only the Arq Exception Proxy message is displayed. This stuff is fixed in Master. but Stacketrace line 1 says it all. You have a failing Assertion, it's the the 'recreation of the AssertError' on the client side the is failing with the "suitable constructor" part
[19:19:15] <bleathem> aslak: ah, ok.  I'll try and narrow down why the assertion is failing then - thx
[19:20:08] <ALR> Hehe, SD in master now depends on a JRE6 runtime
[19:20:11] <ALR> String.isEmpty
[19:20:19] <rbattenfeld> ALR: The descriptors which are generated are not backwards compatible with the existing descriptors. This would be new for me.
[19:20:55] <ALR> rbattenfeld: Only the existing descriptors in the API module are the ones intended to be locked down
[19:21:03] <ALR> Though I think aslak has some nastiness in ARQ. :)
[19:21:11] <ALR> aslak: How do you wanna proceed here?
[19:21:37] <rbattenfeld> ALR: The string.isEmpty should be corrected
[19:21:54] <ALR> rbattenfeld: We've an open issue for it.  I think I have a pull request already
[19:22:01] <ALR> Indeed I do.
[19:22:11] <ALR> It's already upstream bfc890f2363cb7534a642612d3e7bc3f99cec0fd
[19:22:54] <rbattenfeld> ALR: sorry, the string.IsEmpty is corrected...
[19:24:19] *** oskutka has joined #jbosstesting
[19:25:55] <aslak> ALR, nasty use of Descriptors ?
[19:26:03] <ALR> aslak: Use of SD-imp
[19:26:04] <ALR> impl
[19:26:13] <ALR> ie. Relying on, say, WebAppDescriptor
[19:26:27] <rbattenfeld> ALR: Yes, I think it is stable enough. The problem is, I can much better test the descriptors when there is in a official release and I can reuse it our company.
[19:26:41] <aslak> ALR, the api package of the impl module, sure.. :)
[19:26:47] <ALR> rbattenfeld: Yep, first step there is getting it in master
[19:27:03] <ALR> aslak: Haha, remember the deal in JBossWorld?
[19:27:04] <ALR> :)
[19:27:15] <ALR> We'd do a back-compat release for just the API, and moved only what we could support forward to it?
[19:27:39] <ALR> I don't think we can keep the api package of the impl module supported.
[19:27:45] <ALR> So what's that mean for ARQ?
[19:28:20] <aslak> ALR, WebAppDescriptor and ApplicationDescriptor is in use in the Protocols, and Nodes etc are in use in Arq Configuration (we use Descriptor impl for our own XML parsing)
[19:28:56] <aslak> ALR, hehe i remember.. :)
[19:30:06] <aslak> ALR, and chance for something you can support in the next release.. (this week) ?
[19:30:07] <aslak> :)
[19:30:53] <rbattenfeld> ALR and ASLAK: The old descriptors are still available. I didn't removed it. SO, there are for some descriptors two version available... Just if there is a problem in ARQ
[19:32:33] <ALR> aslak: What are you asking?  Not following. :)
[19:33:58] <aslak> ALR, is rbattenfeld's new stuff to unstable to support ?
[19:34:38] <aslak> ALR, as in i have two options: i can rewrite / move stuff from Descriptors over to arq to support what is there now, or i can update arq to what ever descriptor is going to be next
[19:34:41] <ALR> aslak: That's what I'll find real soon
[19:35:05] <ALR> aslak: I suspect his stuff is stable enough, though not compatible enough
[19:35:19] <ALR> (Because it was never really intended to be compatible)
[19:35:33] <aslak> back compat is not important for me, as long as it will be from the next going forward.. hehe
[19:35:47] <ALR> aslak: And for existing released versions of ARQ?
[19:35:53] <ALR> What if they upgrade Descriptors?
[19:36:33] <aslak> Beta-1 has issues, CR1 can in theory be compat with Final(not the standalone container tho)..
[19:36:50] <aslak> Arq Final stable with Desc going forward.
[19:37:07] <ALR> Only going forward.  Hmm.
[19:37:20] <ALR> Let's see how stable the API is in order to go into the SD-api module
[19:37:36] <ALR> First clearing the rest of the community SD queue
[19:37:41] <ALR> on SD-48 ATM from tommysdk
[19:37:43] <ALR> Making my way down
[19:39:32] *** lfryc has quit IRC
[19:39:56] <aslak> i would rather have Arq Final mark the line and say, hey, this is what will be stable. instead of Arq cloning descriptors internally..
[19:40:26] <aslak> but of course, any tiny change in api going forward breaks arq, so scary.. :)
[19:43:04] *** lfryc has joined #jbosstesting
[19:44:18] <rbattenfeld> ALR: I have to leave for now. I will create a wiki in the user's forum, right? Any further  things I can do? Aslak, do you have something?
[19:44:18] *** lightguard_jp has joined #jbosstesting
[19:45:29] <jbossbot> git [descriptors] push master 63b3677.. Tommy Tynja [SHRINKDESC-48] Security contraint now adding displayName correctly
[19:45:30] <jbossbot> jira [SHRINKDESC-48] WebAppDescriptor maps securityConstraint(displayName) to element "name", should be display-name [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SHRINKDESC-48
[19:45:30] <jbossbot> git [descriptors] push master b28557f.. Andrew Lee Rubinger [SHRINKDESC-48] Fix the test case to account for running in JRE5; use XPath assertions
[19:45:30] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/bfc890f...b28557f
[19:45:40] <ALR> rbattenfeld: That sounds about right
[19:45:50] <ALR> rbattenfeld: And I'll look at getting your stuff into master, if it can be done now
[19:45:55] <ALR> Without serious merging, etc
[19:48:22] <rbattenfeld> ALR: Good. By the way, the JDK5 is no integrated in the last commit, I hope it is correct.
[19:48:35] <ALR> rbattenfeld: Which last commit?
[19:48:36] <ALR> Yours?
[19:48:51] <ALR> rbattenfeld: Something you can try to do in your branch is rebase off master
[19:49:00] <rbattenfeld> ALR: yes, as you have asked for
[19:49:06] <ALR> Does it work? :)
[19:49:41] * ALR is trying
[19:49:48] <rbattenfeld> ALR: I think so... I have just changed the String.isEmtpy
[19:51:25] <ALR> rbattenfeld: Got some merge conflict, one sec
[19:51:31] <ALR> Will see if I can resolve that
[19:51:43] <ALR> (Unless you gotta go, in which case no problem)
[19:52:11] <rbattenfeld> ALR: I should:) but I will see...
[19:52:32] *** Jaikiran is now known as Jaikiran|Dinner
[19:52:39] <ALR> Hmm...
[19:52:41] <ALR> public interface DescriptionGroup<T> extends Child<T>
[19:52:42] <ALR> or:
[19:52:49] <ALR> public interface DescriptionGroup<T>
[19:52:50] <ALR> ?
[19:53:42] <ALR> rbattenfeld: ^
[19:53:51] <rbattenfeld> ALR: Can not just get the latest stuff I have checked-in? This works for sure
[19:55:22] <rbattenfeld> ALR: I will start eclipse:) just a moment
[19:55:49] <ALR> Sure, but that works in a bubble.
[19:55:59] <ALR> Remember it's all destined to be resolved w/ master
[19:56:03] <ALR> And you've changed the API :)
[20:01:53] <rbattenfeld> ALR: the descriptiongroup class is gone in the meantime. Did you merged two versions
[20:02:38] <ALR> rbattenfeld: Yeah, I don't see it anywhere.  It's in the interim that it's getting mangled.
[20:02:44] <ALR> 1/2way through rebase
[20:08:46] *** mumilove has joined #jbosstesting
[20:12:25] <rbattenfeld> ALR: I will come back tomorrow. Thanks for your help.
[20:12:40] <ALR> rbattenfeld: Great.  I'll have the pull request queue cleared by then
[20:12:48] <ALR> And we can just work on merging/rebasing your stuff
[20:13:14] <rbattenfeld> Super.
[20:13:27] *** mumilove has left #jbosstesting
[20:13:31] <rbattenfeld> Cheers to everyone
[20:13:39] *** rbattenfeld has left #jbosstesting
[20:14:18] *** galderz has joined #jbosstesting
[20:14:28] *** galderz has quit IRC
[20:23:59] <aslak> ALR, SHRINKWRAP-233 should verify that only the expected classes were added
[20:24:01] <jbossbot> jira [SHRINKWRAP-233] addClass with DefaultPackage opens addPackage to null arguments [Resolved (Done) Bug, Major, Ivan Pazmino] https://issues.jboss.org/browse/SHRINKWRAP-233
[20:24:46] <aslak> ALR, if i'm reading the commit change corectly, it currently checks if the default package is added which was never the problem, the issue is that it adds EVERYTHING else as well
[20:25:32] <aslak> ;)
[20:25:34] <ALR> aslak: That doesn't seem reflected in the issue, though *is* a problem
[20:25:42] <ALR> aslak: Let's open a new one and send to Ivan
[20:25:53] <ALR> And he can just add a new test case for it.
[20:26:08] <aslak> ALR, "The downside is, if someone happens to add, e.g.
[20:26:08] <aslak> addPakcage(true, Package.get("some-missing-package")), addPackage will be called with null, and null means /, which means all found packages are added."
[20:26:11] <ALR> And what do you mean by "everything"?  ie. Recursively all packages under the default?
[20:27:37] <ALR> aslak: So how do you feel about a simple: Assert.assertEquals(2, archive.getContent().size());
[20:27:49] <aslak> that works
[20:29:39] <jose_freitas> aslak: do you need to make some updates on jsfunit to make it work with arquillian final api?
[20:30:40] *** Jaikiran|Dinner has quit IRC
[20:30:42] <aslak> jose_freitas, yea
[20:30:47] <aslak> from Beta-1 >
[20:31:00] <aslak> jose_freitas, wanna have a look? :)
[20:31:37] <aslak> jose_freitas, the change is basically 'merge' the individual SPI impls as they are now into a LoadableExtension
[20:31:47] <jose_freitas> Yeah, sure thing
[20:31:58] <aslak> merge/move
[20:32:03] <jose_freitas> uhum
[20:32:28] <aslak> jose_freitas, yea, you know how it looks from Jacoco right
[20:32:43] <aslak> jose_freitas, and there are probably a few package name updates
[20:32:43] <jose_freitas> I think I can handle it
[20:33:21] *** Jaikiran has joined #jbosstesting
[20:33:51] <aslak> jose_freitas, next on the list is to remove the direct CDI support, as it's not really needed any more since with the Arquillian support. It was lef ti nthere due to the CDI enricher failing if you didn't use CDI when having CDI enabled. that is fixed up stream
[20:34:15] <aslak> @Inject vs @JSFUnitResource
[20:34:38] <aslak> since it has the Arquillian support that is
[20:34:48] <jose_freitas> hm
[20:35:40] <aslak> ALR, any use case for a TAR based WebArchive ?
[20:36:00] <jose_freitas> aslak: do you think your fork is update?
[20:36:04] <ALR> aslak: In theory maybe
[20:36:07] <ALR> In practice no
[20:36:10] <aslak> hehe
[20:36:10] <jose_freitas> https://github.com/aslakknutsen
[20:36:25] <jose_freitas> ops
[20:36:25] <jose_freitas> https://github.com/aslakknutsen/jsfunit
[20:36:25] <ALR> I always consider there to be a separation between archive type and format type
[20:37:46] <aslak> ALR, i do tend to agree, and Archive is really just a view over the content structure, not the format
[20:37:49] <aslak> but....
[20:37:59] <aslak> it's the whole 0.01% usecase vs the rest
[20:38:49] <ALR> aslak: Well, we default it
[20:38:58] <ALR> Archive type that is
[20:39:02] <ALR> Format type
[20:39:16] <ALR> What's the use-case/problem?
[20:39:37] <aslak> jose_freitas, according to git svn rebase it's up to date.. let me check fisheye
[20:40:03] <aslak> ALR, we default extension name you mean ?
[20:40:12] <aslak> file extension name
[20:41:52] <ALR> I guess?
[20:42:00] <ALR> aslak: What's the problem you're finding?
[20:42:32] <aslak> ALR, no i mean, when you say "Well, we default it"
[20:42:42] <aslak> what are you refeing to ?
[20:43:01] <ALR> I thought we set default importers/exporters.  We don't
[20:43:12] <aslak> right
[20:43:26] <ALR> Just the extension.
[20:43:28] <aslak> we default the auto generated extension name
[20:43:34] <ALR> Right
[20:44:13] <aslak> i think, getAsType(WebArchive.class) should be enough. Exporter/Importer can be picked up from WebArchive.class's SPI property file
[20:44:35] <ALR> We now have a ArchvieFormat thing.
[20:44:40] <aslak> no problem having it open for specyfing the ArchiveFormat as well, to cover the 0.0.1% case
[20:44:41] <ALR> Which lists our known formats
[20:44:45] <ALR> Yeah
[20:45:04] <aslak> but for a simplified v. where it's not required
[20:45:06] <ALR> importer/exporter shouldn't be picked up
[20:45:10] <ALR> ArchiveFormat should
[20:45:24] <aslak> ALR, well, sure
[20:45:24] <ALR> Which later in turn gets linked to importer/exporter later
[20:45:28] <aslak> true
[20:45:46] <aslak> ArchiveFormat could include extension as well ?
[20:45:57] <ALR> I'll send this to DavideD
[20:46:31] <aslak> no, keep them separate
[20:46:48] <ALR> Yep, separate
[20:46:50] <aslak> else we'll need ArchiveFormat.JAR etc
[20:49:42] <aslak> jose_freitas, now it's up to date. was missing 4 commits from trunk: https://github.com/aslakknutsen/jsfunit/commits/master
[20:51:33] *** nilian has joined #jbosstesting
[20:52:11] <ALR> aslak: SHRINKWRAP-303
[20:52:13] <jbossbot> jira [SHRINKWRAP-303] Add getAsType(Class<Archive<?>> archiveType) [Open (Unresolved) Task, Major, Davide D'Alto] https://issues.jboss.org/browse/SHRINKWRAP-303
[20:53:25] <ianbrandt> aslak: Because of https://issues.jboss.org/browse/WELD-879 I have to .addAsServiceProvider(Container.class, Tomcat7Container.class) in createTestArchive().  When I do WEB-INF/META-INF/org.jboss.arquillian.core.spi.LoadableExtension and WEB-INF/classes/org/jboss/arquillian/protocol/servlet/runner/* are no longer being automagically added to the archive. (WEB-INF/META-INF is a curious location.  Shouldn't it be
[20:53:26] <ianbrandt> WEB-INF/classes/META-INF/services?).  If I both add the Container service provider and .addAsServiceProvider(LoadableExtension.class, TomcatExtension.class), along with the servlet runner classes I then get LoadableExtension in WEB-INF/META-INF and WEB-INF/classes/META-INF/services.  Any thoughts on how this should work?
[20:53:27] <jbossbot> jira [WELD-879] Tomcat 7 container is identified as Tomcat 6 [Open (Unresolved) Bug, Major, Ales Justin] https://issues.jboss.org/browse/WELD-879
[20:56:15] <aslak> ianbrandt, que? :)
[20:56:55] <aslak> ianbrandt, TomcatExtension is your DeployableContainer client side extension right?
[20:57:13] <aslak> so that should be in META-INF/services of the Tomcat 7 Deployable Container
[20:57:17] <ianbrandt> aslak: Sorry, some background.  I'm working on the Tomcat 7 embedded container.
[20:57:54] <aslak> ianbrandt, where does the WebArchive come in? in your Test Class?
[20:58:49] <ianbrandt> aslak: org.jboss.arquillian.container.tomcat.embedded_7.TomcatEmbeddedInContainerTestCase, which is a copy of the Tomcat 6 equivalent at the moment.
[20:59:16] <aslak> ianbrandt, there is a bug or a feature or what ever.. in ShrinkWrap that binds addAsServiceProvider to /META-INF/, for a WebArchive it should be WEB-INF/classes/META-INF/
[21:00:45] <ianbrandt> aslak: right, I found SHRINKWRAP-266
[21:00:47] 
[21:00:56] <aslak> ianbrandt, so you can use somrthing like. war.addAsResource(new StringAsset(ServiceImplClass.class.getName()), "META-INF/services/" + ServiceInterface.class.getName())
[21:01:56] <ianbrandt> aslak, well see, that's the thing.  That bug appears to be fixed.  When I call addAsServiceProvider with anything it goes to WEB-INF/classes/META-INF/services
[21:02:52] <aslak> aa your right.. missed the fix.. :)
[21:03:09] <aslak> ianbrandt, so what was the problem ?
[21:03:29] <ianbrandt> but when I run the Tomcat 6 test, which doesn't explicitly addAsServiceProvider, I get WEB-INF/META-INF/org.jboss.arquillian.core.spi.LoadableExtension
[21:05:05] <aslak> but where does LoadableExtension come into play in the Test ?
[21:05:16] <ianbrandt> Well my real issue is with Tomcat 7 TomcatEmbeddedInContainerTestCase.shouldBeAbleToInjectMembersIntoTestClass is failing on null testBean, i.e. @Inject isn't working.  In troubleshooting I ran into the services issues.
[21:06:22] <ianbrandt> not sure honestly.  I was just trying to make sure my tomcat 7 test archive was identical to the tomcat 6 one, with the TomcatContainer changed from tomcat_6 to tomcat_7 of course.
[21:06:42] <ianbrandt> Tomcat 6 the same test passes.
[21:06:46] <aslak> ianbrandt, which Arq Core v. are you depending on ?
[21:06:58] <ianbrandt> head
[21:07:06] <aslak> ianbrandt, have you rebased it offa arquillian-container-tomcat master recently ?
[21:07:27] <ianbrandt> I just fetched and merged.
[21:07:56] <ianbrandt> Both core and arquillian-container-tomcat.
[21:08:29] <aslak> all the extension in the deployment should be registered as RemoteLoadableExtension
[21:09:02] <ianbrandt> Ahh, okay.  Hmm.
[21:09:43] <aslak> ianbrandt, you have it pushed somewhere?
[21:09:58] <ianbrandt> I can, one sec...
[21:12:49] *** k4ffee has quit IRC
[21:12:59] *** k4ffee has joined #jbosstesting
[21:15:37] *** mhuniewicz has joined #jbosstesting
[21:15:52] <ianbrandt> https://github.com/ianbrandt/arquillian-container-tomcat
[21:16:46] <ianbrandt> oops, aslak: https://github.com/ianbrandt/arquillian-container-tomcat
[21:17:27] <aslak> do you see the content of the LoadableExtension file in the odd location ?
[21:20:26] *** Jaikiran has quit IRC
[21:21:44] <mhuniewicz> Hi aslak, I got a question regarding PersistenceContext since I got somewhere.
[21:21:46] <ianbrandt> aslak: org.jboss.arquillian.protocol.servlet.runner.ServletRemoteExtension for both tomcat 6 & 7
[21:24:30] <ianbrandt> aslak: FYI as I'm still all thumbs with Git... my upstream is git://github.com/arquillian/arquillian-container-tomcat.git, and I just did a "git fetch upstream" and "git merge upstream/master" and it says "Already up-to-date."
[21:27:45] *** alesj has joined #jbosstesting
[21:30:27] <aslak> ianbrandt, yea, that one was a bug in Core CR1. It's just the ServletProtocols Remote side that is using the wrong extension type and location for that matter. It only effects the CommandService tho, for client / server communication, not the test execution (e.g. @ArquillianResource Deployer)
[21:30:44] <aslak> ianbrandt, update to Arq Core 1.0.0.Final-SNAPSHOT and it should be fixed
[21:30:53] <aslak> ianbrandt, https://github.com/arquillian/arquillian-container-tomcat/blob/master/pom.xml#L34
[21:31:03] <aslak> mhuniewicz, hey, shoot?
[21:31:36] <mhuniewicz> I managed to have PersistenceContext automatically injected which is good.
[21:31:38] <mhuniewicz> However,
[21:32:30] <mhuniewicz> it creates a new instance of entity manager for each injection point which I believe is wrong - there should be one per test per for all injection points.
[21:32:37] <mhuniewicz> How can I achieve that?
[21:32:56] <aslak> mhuniewicz, well.. what have you done ? :)
[21:33:37] <mhuniewicz> https://github.com/m1key/arquillian-container-weld/tree/InjectPC
[21:33:50] <mhuniewicz> This is better: https://github.com/m1key/arquillian-container-weld/commit/6c50eda427df1b3d5ed483bb9911b59ac6626608
[21:33:51] <jbossbot> git [arquillian-container-weld] 6c50eda.. Michal Huniewicz Injects a new instance of EntityManager every time it's requested.
[21:35:20] <aslak> mhuniewicz, aa.. right. not sure, guess that's how the weld spi work. you'll need to store it 'somewhere'
[21:35:22] <aslak> alesj, ^
[21:37:48] <ianbrandt> aslak: DOH!  Thanks, I totally missed that parent-tomcat was pointing at the older snapshot version.
[21:38:44] <jose_freitas> aslak
[21:39:04] <jose_freitas> can I change the "parent" pom for jsfunit modules?
[21:39:26] <aslak> jose_freitas, why?
[21:39:33] <jose_freitas> I'd like to change build  jdk target to 1.6
[21:39:36] <jose_freitas> ops
[21:39:38] <jose_freitas> not target
[21:39:40] <jose_freitas> source
[21:39:51] <jose_freitas> cause there's @override for interfaces
[21:39:56] <aslak> jose_freitas, you can't.. eclipse won't allow the import
[21:40:10] <jose_freitas> no?
[21:40:42] <aslak> jose_freitas, you can change it locally to reimport but don't commit it, or you can change the target on the imported project
[21:41:02] <aslak> jose_freitas, you can't have source v 1.6. and target 1.5, javac refuse to compile
[21:41:06] <aslak> or run/start
[21:41:15] <jose_freitas> ok
[21:41:59] *** lfryc has quit IRC
[21:44:21] <mhuniewicz> I have no idea where to store it though.
[21:44:31] <aslak> mhuniewicz, static ?
[21:44:51] <mhuniewicz> It must be reset for each test though...
[21:54:17] <aslak> mhuniewicz, hmm.. yea .,not quite sure what we could do about that..
[21:54:33] <mhuniewicz> I was thinking, scopes?
[21:56:03] <aslak> mhuniewicz, well.. if you store it in a Instance variable in that Service Impl, you should get the same EntityMnagaer instance across all @Tests, but different ones between TestClasses
[21:56:29] <aslak> weld it self is created and shutdown between @Deployments
[22:01:56] *** mgoldmann has quit IRC
[22:02:05] <mhuniewicz> aslak, I'm struggling to get my Eclipse to work. I will try these things you mentioned and let you know.
[22:04:51] <ianbrandt> aslak: Having updated to core 1.0.0-Final-SNAPSHOT I now get WEB-INF/META-INF/services/org.jboss.arquillian.container.test.spi.RemoteLoadableExtension automagically when still specifying just .addAsServiceProvider(Container.class, Tomcat7Container.class) in the test case (to work around WELD-879), so that looks better.  I'm still wondering why it isn't WEB-INF/classes/META-INF/services, but the Tomcat 6 test case passe
[22:04:52] <ianbrandt> my Tomcat 7 test archive looks the same excluding the addition of WEB-INF/classes/META-INF/services/org.jboss.weld.environment.Container.  @Inject still isn't working with Tomcat 7 however, but maybe I have a Weld/Tomcat 7 issues or something.  Back to the debugger...
[22:04:53] <jbossbot> jira [WELD-879] Tomcat 7 container is identified as Tomcat 6 [Open (Unresolved) Bug, Major, Ales Justin] https://issues.jboss.org/browse/WELD-879
[22:06:41] <aslak> ianbrandt, hmm.. shouldn't that have been WEB-INF/classes/META-INF ?
[22:07:40] <aslak> ianbrandt, Tomcat 7 is not Servlet 3.0 ?
[22:07:44] <ianbrandt> aslak: For RemoteLoadableExtension?  I would think, or WEB-INF/classes/META-INF/services, but that's not what's happening.
[22:08:43] *** nilian has quit IRC
[22:09:00] <aslak> ianbrandt, yea, Servlet 2.5 use .addAsWebInfResource , that's wrong
[22:09:04] <ianbrandt> aslak: It is.  I'm just starting from the Tomcat 6 implementation.  I figure if I can get it working with the deprecated API and Servlet 2.5 protocol, I can migrate from there.  One step at a time. ;)
[22:09:36] <ianbrandt> aslak: ah, I see.
[22:09:58] <aslak> ianbrandt, yea, just so you know about the getDefaultProtocol on DeployableContainer, which should probably be "Servlet 3.0" for your case.. :)
[22:10:02] <aslak> both should work tho
[22:10:48] <aslak> ianbrandt, and the RemoteLoadableExtension in the wrong location should not effect CDI in your test cases.. :)
[22:11:13] <ianbrandt> aslak: Yep, 3.0 is my target.  While I have you anything I should know about in switching, or is it just the update to getDefaultProtocol?
[22:11:34] <ianbrandt> aslak: Good to know about CDI.
[22:14:28] <aslak> ianbrandt, ha, I even have a testcase that asserts the wrong location, nice job aslak.. :)
[22:15:07] <aslak> ianbrandt, just the getDefaultProtocol
[22:16:07] <ianbrandt> aslak: ha, who watches the watchers? ;)
[22:17:24] <aslak> ianbrandt, :)
[22:17:28] <aslak> ianbrandt, pushed upstream
[22:17:29] <mhuniewicz> aslak, whether I make it static or not, it doesn't matter.
[22:17:31] <aslak> arq cotre
[22:17:33] <aslak> arq core
[22:17:37] <mhuniewicz> It's just initialised once.
[22:18:04] <ianbrandt> aslak: Do you think EmbeddedWebappClassLoader is still needed to change up the delegation order now with the
[22:18:12] <ianbrandt> ... RemoteLoadableExtension changes.
[22:19:19] <aslak> ianbrandt, it was needed to get multiple Embedded Tomcats to run in a single vm, but the dependencies loading etc that was in core has been removed,
[22:20:07] <aslak> ianbrandt, i would say you can remove it for now, for both 6 and 7. we limit multi containers to be managed or remote containers only.. and revisit when we get some module classloading or simialr in core in some future v.
[22:20:39] <ianbrandt> aslak: sounds good.
[22:24:20] <ianbrandt> aslak: I'm off to get some lunch before going back at my CDI issue.  Thanks for the help!
[22:24:35] <mhuniewicz> aslak, so in Eclipse if I run one test case which 3 @Test's, I hest only one instance of MockJpaInjectionServices.
[22:27:02] <bleathem> Arquillian won't start my managaed AS6 profile - reporting a startup timeout
[22:27:09] <bleathem> any idea what might be causing this?
[22:27:18] <bleathem> I've killed all java jobs
[22:27:34] <bleathem> checked that I can start/stop it myself from the command line
[22:27:51] <bleathem> (AS 6 starts in 48 seconds when I do it manually)
[22:28:17] <bleathem> this was working fine earlier today, it just started failing on me
[22:29:59] <bleathem> nuking my jboss as 6 install, starting with a fresh unzip
[22:34:03] <bleathem> still fails - going to try a machine reboot, maybe something has grabbed the port
[22:34:56] *** bleathem has left #jbosstesting
[22:39:33] *** pgmjsd has quit IRC
[22:39:40] <jose_freitas> aslak: arquillian provides @Produces as well?
[22:45:32] *** bleathem has joined #jbosstesting
[22:47:20] <bleathem> ugh. Arq still can't start my AS 6 after a reboot
[22:48:37] <jose_freitas> any errors thrown?
[22:49:32] <bleathem> no
[22:49:36] <bleathem> nothing in the server log
[22:50:15] <jose_freitas> is the arquillian.xml pointing to the right ports?
[22:51:46] <bleathem> jose_freitas: I removed the ports stuff that you had put in arquillian.xml in trying to resolve this
[22:52:02] <bleathem> jose_freitas: this is for a vanilla unzipped AS6 install
[22:52:35] <jose_freitas> hm
[22:52:43] <bleathem> in the server log, for a minute and a half I see:
[22:52:47] <bleathem> (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Check status for engine [jboss.web]
[22:52:50] <bleathem> then the call for shutdown
[22:53:03] <bleathem> I guess arq is polling for the status
[22:53:13] <bleathem> and times out when it doesn't come up
[22:53:19] <bleathem> then calls for a shutdown
[22:53:25] <jose_freitas> hm
[22:53:39] <bleathem> what could keep the jboss.web engine from starting?
[22:53:50] <bleathem> or at least not reporting that it's started...
[22:54:04] <bleathem> can't wait till we can test this against AS 7
[22:57:24] <jose_freitas> bleathem: it might not be a problem of starting up, maybe it's a problem when arquillian bumps jboss to check status
[22:58:07] <jose_freitas> I'm not sure though
[22:58:27] <jose_freitas> do you have rmiPort configuration?
[22:58:32] <bleathem> huh, any idea on steps to tkae to resolve it?
[22:58:44] <bleathem> maybe I'll try the tomcat profile
[22:58:44] <jose_freitas> none, right?
[22:58:58] <bleathem> jose_freitas: no rmi port configured
[22:59:08] *** alesj has left #jbosstesting
[22:59:09] <bleathem> I can put it back
[22:59:12] <jose_freitas> tomcat profile was not finished
[22:59:21] <bleathem> but it wasn't working b4 (with the rmi port
[22:59:25] <bleathem> )
[22:59:39] <jose_freitas> try to put rmiPort=1099
[22:59:42] <bleathem> how about the jetty profile?
[22:59:46] <jose_freitas> it was 1199 if I'm not mistaken
[22:59:56] <jose_freitas> both profiles need some testing
[23:00:42] <jose_freitas> 1099 is the default port
[23:02:15] <bleathem> ugh. there was still an http port in my arquillian.xml
[23:02:21] <bleathem> removed that, and it works
[23:02:29] <bleathem> I freaking love this stuff :|
[23:03:06] <jose_freitas> hm
[23:03:14] <jose_freitas> what configuration did you have?
[23:03:19] <jose_freitas> for httpPort
[23:03:26] <jose_freitas> 8180?
[23:03:48] <bleathem> 8180
[23:04:07] <jose_freitas> hm
[23:04:12] <bleathem> default is 8080 right?
[23:04:16] <jose_freitas> yes
[23:04:17] <jose_freitas> and jvm args?
[23:04:20] <jose_freitas> did you have?
[23:04:32] <bleathem> yes, but only for memory settings
[23:04:37] <jose_freitas> ok
[23:05:20] <bleathem> finally trying my viewaction test :P
[23:05:42] <jose_freitas> hehehe
[23:09:48] <aslak> jose_freitas, no @Producers, but @Inject @Application|Container|Deployment|Test|Class|SuiteScope InstanceProducer<Type> inst; inst.set() is a 'producer'
[23:10:14] *** ldimaggi has quit IRC
[23:11:02] <bleathem> What would you (anyone who might know) expect JSFUnit to do with a viewAction?
[23:11:18] <bleathem> If I have: @InitialPage("/form.xhtml")
[23:11:39] <bleathem> and that page has a viewAction with an action that navigates to a new page
[23:12:01] <bleathem> where the new page is "result.xhtml"
[23:12:19] <bleathem> then "Assert.assertEquals("/result.xhtml", server.getCurrentViewID());" as the first line of the test method should work right?
[23:12:50] <bleathem> JSFUnit should invoke the page, and immediately process the action to navigate to the result page
[23:13:44] <aslak> bleathem, not sure.. :)
[23:15:17] *** jose_freitas has quit IRC
[23:16:19] <mhuniewicz> aslak, createRequest is called once per @Test, exactly what I want.
[23:16:47] <mhuniewicz> But MockJpaInjectionServices is created once per test case in BeanDeploymentArchiveImpl using 'new'.
[23:20:34] <aslak> mhuniewicz, you could register a Observer alla LifeCycle handler that 'clears' out MockJPAInjectionServices In After
[23:21:49] <mhuniewicz> aslak, in WeldExtension?
[23:24:50] <aslak> mhuniewicz, you register your Observer there, but crate a class with a public void somemethod(@Observes After event)
[23:25:20] <aslak> After being org.jboss.arquillian.test.spi.event.suite
[23:26:30] <mhuniewicz> Aslak, how do I access my MockJpaInjectionServices from there though?
[23:28:26] <aslak> if you do method(@Observes After event, WeldManager manager), you can do manager.getServices().get(JpaInjectionServices.class)
[23:28:42] <mhuniewicz> I see.
[23:28:50] <mhuniewicz> That makes sense. Isn't it a bit hackish though?
[23:31:09] <aslak> mhuniewicz, it is
[23:31:45] <aslak> stuartdouglas, ping
[23:31:58] <stuartdouglas> hi aslak
[23:32:07] <aslak> stuartdouglas, heya.. since your the only weld core head around.. :)
[23:32:17] <aslak> and probably know the inside out of this stuff
[23:32:47] <stuartdouglas> I must warn you, I am only of my first coffee of the day :-)
[23:33:13] <aslak> stuartdouglas, mhuniewicz is trying to get some PersistenceContext support in Weld EE Mock Arq Container
[23:33:18] <stuartdouglas> It usuallly takes at least two for my brain to start working
[23:33:36] <stuartdouglas> so you can use @PersistenceContext injection?
[23:33:40] <aslak> stuartdouglas, currently trying to implement it via the JpaInjectionService
[23:33:46] <aslak> yea
[23:34:30] <stuartdouglas> what is the problem?
[23:34:56] <mhuniewicz> stuartdouglas, I need the same instance to be injected into every @PersistenceContext field, but a new one per every @Test.
[23:35:30] <stuartdouglas> mhuniewicz: actually what you need is a transaction scoped entity manager proxy to be injected every time
[23:35:48] <stuartdouglas> assuming you want to replicate the behaviour of EE
[23:36:07] <stuartdouglas> In an EE environment a proxy get injected
[23:36:16] <stuartdouglas> and the underlying EM changes with each transaction
[23:36:37] <mhuniewicz> Well, this is enough for me:
[23:36:50] <mhuniewicz> EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("testPu");
[23:36:51] <mhuniewicz> entityManager = entityManagerFactory.createEntityManager();
[23:36:58] <stuartdouglas> Does the Weld EE container have any transaction support?
[23:37:17] <mhuniewicz> And that works, I saw Adam Bien doing the same thing so I assume it's not completely wrong.
[23:37:48] <mhuniewicz> Using that entityManager I can manually begin and commit transactions.
[23:37:53] <stuartdouglas> mhuniewicz: Application managed entity managers behave differently to container managed entity managers
[23:38:28] *** maeste has quit IRC
[23:38:31] <stuartdouglas> if you are trying to replicate the behaviour of @PersistenceContext you probably want to try and replicate the container managed behaviour
[23:38:34] <mhuniewicz> Uh huh.
[23:39:00] <aslak> stuartdouglas, no transactions in weld ee mock
[23:40:02] <mhuniewicz> stuartdouglas, I want it to create that entityManager the way I showed above, that's it really.
[23:40:10] <mhuniewicz> For purpose of tests that connect to a DB.
[23:40:29] <stuartdouglas> ok, in that case can you just stick it in a ThreadLocal for the life of the test?
[23:41:16] *** dblevins has quit IRC
[23:41:18] <stuartdouglas> it would need some way of knowing when the test is over
[23:41:32] <mhuniewicz> I suppose so? Would that give me a new instance for each @Test but the same one for every @PersistenceContext in that @Test?
[23:41:56] <stuartdouglas> The thread local would need to be cleared after each test
[23:42:08] <stuartdouglas> aslak: does are provide some way of doing this?
[23:42:20] <mhuniewicz> What Aslak suggested is using events.
[23:42:24] <aslak> stuartdouglas, mhuniewicz yea, and the only way to know pr test is using the Arq Observers we spoke of earlier
[23:42:32] <mhuniewicz> Coz we have AfterLifecycleEventExecuter.
[23:42:56] <aslak> Weld is running on a pr TestClass level, to make it pr @Test, something need to clear it
[23:42:58] <mhuniewicz> So yeah there I could clear it.
[23:43:15] <mhuniewicz> public void on(@Observes(precedence = 100) After event)?
[23:43:43] <aslak> mhuniewicz, yea, but don't reuse those.. they have a different purpose. :)
[23:44:15] <mhuniewicz> Well I can have my own class like that, no problem. But still, how do I gain access to MockJpaInjectionServices?
[23:44:34] <mhuniewicz> I guess someone needs more coffee... ;)
[23:44:53] <aslak> mhuniewicz, you get away with no class casting etc, just manager.getServices().get(JpaInjectionSrevice.class).cleanUp()
[23:45:23] <aslak> implement the cleanUp in your MockJPAInjectionService
[23:45:34] <aslak> to clear a instance variable that holds the EntityManager
[23:45:43] <mhuniewicz> So should I change the JpaInjectionService interface?
[23:45:49] <mhuniewicz> Oh no wait.
[23:45:58] <mhuniewicz> It already has that, doesn't it.
[23:46:05] <mhuniewicz> Oh it's less hackish than I thought. :)
[23:46:07] <stuartdouglas> you just have a static ThreadLocal
[23:46:12] <aslak> the resolvePersistenceContext then only creates a new if the instance EnityManager is null
[23:46:24] <stuartdouglas> and then a static method on MockJpaInjectionService to clear it
[23:46:57] <aslak> stuartdouglas, there are Weld SPIs to get to these things, so no need to hack around with statics
[23:47:05] <aslak> :)
[23:47:13] <mhuniewicz> eheh, yeah, it's evil.
[23:49:37] <mhuniewicz> cleanup() gets called once after test case, I see.
[23:50:18] <mhuniewicz> aslak, where would my executer belong then?
[23:54:34] *** maeste has joined #jbosstesting
[23:54:53] *** maeste has quit IRC
[23:57:54] *** dblevins has joined #jbosstesting
[23:58:39] <aslak> mhuniewicz, well, you call it once pr test case.. :)
[23:59:40] <aslak> mhuniewicz, just create a new class, InjectionServiceResetter or similar and register it in WeldExtension





top