[00:08:06] *** clerum has joined #jbosstesting
[01:21:26] *** stuartdouglas has left #jbosstesting
[01:37:13] <lightguard_jp> aslak: Is the new code for arquillian still only in your repo or is it in arquillian?
[01:37:25] *** clerum has left #jbosstesting
[01:40:34] <aslak> lightguard_jp, it's in arq now, under ARQ-370 branch
[01:40:35] <jbossbot> jira [ARQ-370] Merge remote aslakknutsen/the_bigger_picture back into upstream/master [Open (Unresolved) Task, Major, Andrew Rubinger] https://issues.jboss.org/browse/ARQ-370
[01:44:13] <lightguard_jp> aslak: Great
[01:58:13] *** johnament has joined #jbosstesting
[01:58:32] *** ldimaggi has joined #jbosstesting
[01:58:49] <johnament> stupid question, where's arquillian.xml supposed to go?
[01:59:03] <aslak> johnament, cp root
[01:59:27] <johnament> aslak: welcome back!
[01:59:47] <johnament> so if i'm using maven, and it's in src/test/resources that should work?
[02:00:49] <johnament> hmm and now i just noticed i'm getting "no container configuration found for URI: java:urn:org.jboss.arquillian.container.jbossas_managed_6
[02:04:13] <johnament> hahahaha i had a space at the end of the URI :-(
[02:05:08] *** lightguard_jp has quit IRC
[02:15:13] *** bleathem_ has joined #jbosstesting
[02:15:17] *** bleathem_ is now known as bleathem__
[02:15:23] *** bleathem__ is now known as bleathem_home
[03:02:29] *** johnament has quit IRC
[03:30:30] *** aslak has quit IRC
[05:20:52] *** ALR has joined #jbosstesting
[05:27:49] *** ldimaggi has quit IRC
[05:59:23] *** ALR1 has joined #jbosstesting
[05:59:33] *** ALR1 has quit IRC
[06:01:45] *** ALR has quit IRC
[06:08:38] *** bgeorges has joined #jbosstesting
[07:23:57] *** bgeorges has quit IRC
[07:25:06] *** oskutka has joined #jbosstesting
[07:34:33] *** mgoldmann has joined #jbosstesting
[08:08:02] *** rruss has quit IRC
[08:10:24] *** Jaikiran has joined #jbosstesting
[08:13:31] *** jharting has joined #jbosstesting
[08:17:17] *** bleathem_home has quit IRC
[08:17:27] *** lfryc has joined #jbosstesting
[08:46:50] *** bgeorges has joined #jbosstesting
[09:01:54] *** ge0ffrey has joined #jbosstesting
[09:36:08] *** jeand has joined #jbosstesting
[09:57:29] *** wolfc has joined #jbosstesting
[10:00:29] *** bgeorges has quit IRC
[10:05:03] *** bgeorges has joined #jbosstesting
[10:09:02] *** michaelschuetz has joined #jbosstesting
[10:22:10] *** bgeorges has quit IRC
[10:24:18] *** bgeorges has joined #jbosstesting
[10:24:44] *** kpiwko has joined #jbosstesting
[10:28:11] *** Elisha has quit IRC
[10:45:24] *** Elisha has joined #jbosstesting
[11:04:22] *** alesj has joined #jbosstesting
[11:32:36] *** vtunka has joined #jbosstesting
[12:03:34] *** jharting has quit IRC
[13:35:59] *** michaelschuetz has quit IRC
[13:36:21] *** jbossbot has quit IRC
[13:36:47] *** michaelschuetz has joined #jbosstesting
[13:37:02] *** dmlloyd has quit IRC
[13:47:21] *** dmlloyd has joined #jbosstesting
[13:58:29] *** bobmcw has quit IRC
[14:08:59] *** aslak has joined #jbosstesting
[14:08:59] *** aslak has quit IRC
[14:08:59] *** aslak has joined #jbosstesting
[14:10:36] *** bgeorges has quit IRC
[14:18:34] *** jbossbot has joined #jbosstesting
[14:58:15] *** ldimaggi has joined #jbosstesting
[15:05:40] *** rruss has joined #jbosstesting
[15:05:44] *** lightguard_jp has joined #jbosstesting
[15:31:39] *** oskutka has quit IRC
[15:51:36] *** ldimaggi has quit IRC
[16:02:28] *** kpiwko has quit IRC
[16:03:23] *** davidbos has joined #jbosstesting
[16:03:53] *** ldimaggi has joined #jbosstesting
[16:23:48] *** hatchetman82 has joined #jbosstesting
[16:24:19] <hatchetman82> is there any way to make arq. embedded mess with the classloader before booting jboss ? (as 6)
[16:26:03] <hatchetman82> because otherwise what should have been simple NoClassDefFound exceptions become bizzarre linkage errors because classes that arent in the @Deployment are found in the CL of the process running arq (either maven or an IDE)
[16:28:17] <aslak> hatchetman82, yea, looking into those issues
[16:28:33] <hatchetman82> really ?!
[16:28:36] <hatchetman82> awesome!
[16:29:14] <hatchetman82> i usually end up taking the arq. artifact and dumping it into a stand alone jboss just to see a proper exception
[16:29:32] <hatchetman82> do you have a bug # i can watch ?
[16:29:36] <aslak> hatchetman82, the current safest root seems to be to fork a new jvm for the embedded containers. so the container and arq + testclasses (and appcl) run in different jvms.. only way to really separate them
[16:29:55] <hatchetman82> but then how do you debug it ?
[16:30:14] <aslak> same as any other remote jvm
[16:30:28] <hatchetman82> the reason i opted for embedded vs managed is that its easier fir people on my team to just select the junit and hit the debug button in their IDE
[16:30:38] <hatchetman82> i dont trust them with a remote debugger ;-)
[16:30:48] <aslak> no overall jira issue, the same issue has come up with weld etc.. create a jira please.. :)
[16:30:55] <hatchetman82> besides, what would really be the diff between that and managed ?
[16:31:22] <hatchetman82> what if you just pass jboss a crippled class loader ?
[16:31:36] <aslak> i havn't gone down the road of separating the jvms, but we hvae tried some isolation for the weld containers, jboss 7 etc.. nothing works like it should 100%.. :)
[16:31:36] <hatchetman82> i know the approach isnt perfect, but at least its still in the same JVM
[16:32:27] <hatchetman82> yeah, i remember some failsafe-plugin-related page that explained that some apps dont work with a custom CL, so they fork
[16:32:49] <aslak> hatchetman82, well, that's kinda the 'revolation', embedded makes a mess, managed would be prefered. i think the in-container test approach to some extent eliminates the need for embedded
[16:33:47] <aslak> the only thing you gain by using embedded is a whole lot of messy shared state which you can't control
[16:34:12] <hatchetman82> and one click debug :-)
[16:34:58] <aslak> hatchetman82, well.. do you prefer 'one click debug' to eliminating 90% of the reason to debug ? hehe
[16:35:38] <hatchetman82> heh
[16:36:46] <aslak> i think most ppl use embedded for the ease of startup, managed has the same
[16:37:03] <aslak> or managed / forked jvm can do the same
[16:37:06] <hatchetman82> well, after having people completely fail the grasp the concept of @Deployment here we created a "system-test" module that deploys the app (a complete ear) into jboss (using maven, before tests are run), and then in @Deployment we build another ear that has all the interfaces to everything.
[16:37:23] <hatchetman82> this + a jboss tweak to share classloader among ears
[16:37:41] <hatchetman82> all this happend in an abstract test class, which everyone extends.
[16:38:19] <hatchetman82> the performance is horrible (its running managed, the time is ~100 seconds / test class), but it saves people from needing to know what @Deployment is
[16:38:24] 
[16:38:47] <hatchetman82> its in the same CL as the other ear, so it can access local interfaces and everything, but yes
[16:39:27] <aslak> hatchetman82, you have surefire set to fork always ?
[16:39:40] * hatchetman82 looks
[16:40:10] <aslak> unless it takes 100s to deploy your app of course
[16:40:34] <hatchetman82> pertest
[16:40:57] <aslak> right.. so arq will never be able to reuse the managed instance and will be restarting jboss pr test
[16:41:03] <hatchetman82> it takes ~30 seconds for jboss itself to boot, around 40 more for our app
[16:41:15] <hatchetman82> whats a better forkmode to use?
[16:41:21] <aslak> once
[16:41:38] <hatchetman82> at which point arq will maintain the single jboss instance up ?
[16:41:56] <aslak> then you should only be getting the single jboss instance, but still your app deploy time
[16:42:14] <aslak> yea
[16:42:55] <hatchetman82> will do. and youre also saying i should abandon embedded for managed ?
[16:44:22] <aslak> hatchetman82, i think it will give you less headaches yes
[16:44:51] <hatchetman82> how do i configure it to wait for a debugger attach when spawning the new jboss ?
[16:45:17] <aslak> it's to simple to mess up the @Deployment and embedded will find half your stuff anyway.. and you will have state leakage all over the place
[16:45:44] <aslak> http://docs.jboss.org/arquillian/reference/latest/en-US/html_single/#container.jbossas-managed-6.configuration
[16:45:47] <aslak> javaVmArguments
[16:46:11] <aslak> add the normal debug vm args there
[16:46:54] <hatchetman82> ok. thanks
[16:51:48] *** lightguard_jp has quit IRC
[16:59:02] *** alesj has left #jbosstesting
[17:24:50] *** lightguard_jp has joined #jbosstesting
[17:40:48] *** bobmcw has joined #jbosstesting
[17:46:53] *** lfryc has quit IRC
[18:00:14] *** ALR has joined #jbosstesting
[18:02:24] *** davidbos has quit IRC
[18:12:34] *** michaelschuetz has quit IRC
[18:28:43] *** maeste is now known as maeste_afk
[18:44:29] *** bobmcw has quit IRC
[18:48:00] *** vtunka has quit IRC
[18:54:00] *** alesj has joined #jbosstesting
[18:54:36] *** alesj has left #jbosstesting
[19:27:23] *** aslak has quit IRC
[19:28:17] *** aslak has joined #jbosstesting
[19:49:55] *** ge0ffrey has quit IRC
[20:07:22] *** bobmcw has joined #jbosstesting
[20:07:44] *** bobmcw has quit IRC
[20:32:32] *** mgoldmann has quit IRC
[20:52:51] <jdlee> lightguard_jp: dunno if you saw my tweet, but it looks like I have a working arquillian + glassfish 3.1 remote environment set up
[20:53:04] <lightguard_jp> jdlee: I just responded to it
[20:53:19] <jdlee> and my txn interceptor (just a dumb one to fill the gap waiting for Seam Persistence and GF 3.1 to get along) works great
[20:54:11] <jdlee> i had to build your 3.1 remote container, and I had to swap out the jboss java ee 6 spec artifact for the official (?) javax:javaee-api:6.0 artifact to get it to build, but it's all workin'
[20:58:44] <lightguard_jp> The official broken one :) ?
[21:00:02] *** Jaikiran has quit IRC
[21:00:18] <jdlee> fcvo "broken" sure ;)
[21:02:33] <lightguard_jp> Glad it's working for you.
[21:02:47] <lightguard_jp> We've seen most of the problems with Seam 3 have been fixed in glassfish 3.1
[21:03:13] <lightguard_jp> There may be a need to update weld in glassfish for a couple of the modules, but we believe most things are fixed
[21:04:51] <jdlee> yeah, I think i'm just waiting on a good weld release (that I can integrate into GF)
[21:05:16] <jdlee> at this point, though, I can probably just build trunk and install that, based on bleathem's blog...
[21:06:08] <bleathem> replacing the weld-impl in glassfish 3.1 was broken last time I tried
[21:06:37] <bleathem> I need to try again more carefully, and update my post if it is indeed broken
[21:06:48] <jdlee> gotcha
[21:07:17] <bleathem> if you feel like giving it a shot, let me know how it works out
[21:12:32] *** Tashtego has joined #jbosstesting
[21:13:02] <Tashtego> hi. aslak i didnt reach you yesterday. are you online ? i could need a bit help about arquillian. if you have some minutes
[21:23:42] <Tashtego> damn i need a support contract ^^...
[21:23:54] <aslak> Tashtego, heya.. :)
[21:24:04] <Tashtego> hi :;))
[21:24:14] <Tashtego> may i take some of your time? ;)
[21:24:21] <aslak> just finished up dinner..
[21:24:23] <aslak> sure
[21:24:41] <Tashtego> great. could it be that only the string "test.war is accepted from shrinkwrap?
[21:24:54] <Tashtego> any else war file name leads to exceptions in my unit tests
[21:25:38] <aslak> Tashtego, shrinkwrap supports any name, arquillian on the other hand in alpha4 requires the test.war to be named test so it can know where it is deployed
[21:25:50] <Tashtego> which leads to another problem...
[21:26:00] <Tashtego> my first unit test class works fine
[21:26:06] <aslak> this is changed in next v. where we do some inspection of the deployment to fetch which servlets are deployed etc..
[21:26:07] <Tashtego> but as soon as i have two files with unit tests...
[21:26:19] <Tashtego> the undeployment of the first test.war fails and i cant test the second test.war :(
[21:26:38] <aslak> Tashtego, what failes during undeploy?
[21:26:46] <aslak> Tashtego, and which container
[21:26:51] <Tashtego> maybe thats a but with embedded eclipse
[21:26:59] <Tashtego> my dependency is version... let me check
[21:27:35] <Tashtego> 3.1-b25  glassfish-embedded-all
[21:27:58] <Tashtego> cant upgrade to a newer version of glassfish becuase then the classes changed too much and arquillian doesnt work anymore
[21:27:59] <aslak> 3.1-b25? didn't know that worked at all
[21:28:09] <Tashtego> i also tried older versions
[21:28:14] <Tashtego> but thats the latest version that works
[21:28:38] <aslak> i know glassfish had a undeploy issue in some v, don't remember which. it would fail to deploy the second because the web container already had a deployment named test..
[21:29:09] <Tashtego> thats exactly the problem
[21:29:26] <Tashtego> but i cant upgrade to a newer version i guess because then arquillian doesnt work
[21:29:35] <Tashtego> there would happen another exception
[21:29:45] <aslak> Tashtego, yea, the whole glassfish embedded api changed..
[21:29:55] <aslak> Tashtego, you using this in production ?
[21:30:48] <aslak> Tashtego, the next dev v has a gf 3.1 embedded container that works..  https://github.com/arquillian/arquillian/tree/ARQ-370
[21:30:49] <Tashtego> well it is my personal project (one man show), but i plan to go "live" this summer. in about 3 month
[21:30:49] <jbossbot> jira [ARQ-370] Merge remote aslakknutsen/the_bigger_picture back into upstream/master [Open (Unresolved) Task, Major, Andrew Rubinger] https://issues.jboss.org/browse/ARQ-370
[21:31:07] <Tashtego> so its not just a tech demo but its the latest version of my webapp
[21:31:33] <aslak> if you can live with a dev v. until the release, then you can grab and build that
[21:32:03] <aslak> Tashtego, also requires this shrinkwrap branch: https://github.com/shrinkwrap/shrinkwrap/tree/SHRINKWRAP-140
[21:32:04] <jbossbot> jira [SHRINKWRAP-140] Support loading artifacts from a Maven repository [Open (Unresolved) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-140
[21:32:14] <Tashtego> my workaround right now is writing the unit test, testing it and then ignoring temporarly the file. so there will always be just one test.war
[21:32:26] <Tashtego> but when will there be a newer version ;) i am excited about arquillian ;)
[21:32:40] <aslak> Tashtego, when it's done.. :)
[21:33:11] <Tashtego> how comes i know that sentence ;)  ... i appreciate your work!! ;)
[21:33:16] <Tashtego> love arquillian.
[21:33:19] <aslak> :)
[21:33:35] <aslak> glad you like it
[21:34:46] <Tashtego> hope its ok when i sometimes hit you here with my experiences / problems with arquillian. a bit feedback always helps ;)
[21:35:32] <aslak> Tashtego, oh definitely. your feedback is appreciated
[21:35:58] <nickarls> aslak: is there already a JIRA for "arq swallows runtime weld-exceptions" ?
[21:36:30] <aslak> nickarls, hehe, it's now swallowed, it can't deserialize it.. :)
[21:36:48] <aslak> nickarls, and yes..  something related to exception proxy
[21:37:13] <aslak> ARQ-299
[21:37:15] <jbossbot> jira [ARQ-299] Create a IN_CONTAINER Exception Proxy [Open (Unresolved) Feature Request, Major, Andy Gibson] https://issues.jboss.org/browse/ARQ-299
[21:37:25] <nickarls> ok, goodie
[21:37:33] <aslak> got some code from andy there. planning on incorporating it in next release
[21:41:04] <ALR> aslak: I'm leaving you alone until you're caught up. :)
[21:41:18] <ALR> But just know I'm here when you wanna revisit discussions on the upcoming release.
[21:41:20] *** jeand has quit IRC
[21:41:29] <ALR> And Welcome Home.
[21:46:21] *** michaelschuetz has joined #jbosstesting
[21:48:09] <aslak> ALR, heya.. thanks! yea, catching up. i'll get back to you :)
[21:48:17] <ALR> aslak: Sure thing kid.
[21:49:11] <aslak> ALR, do you know anything about the new code gen api stuart is working on?
[21:49:37] <ALR> aslak: Stuart?
[21:49:49] <ALR> aslak: Lincoln and James, yes.
[21:50:22] <aslak> code gen might be the wrong word. class file gen
[21:50:35] <ALR> aslak: Oh, no, I don't.
[21:50:43] <ALR> I saw a cool one at a local JUG here.
[21:50:51] <ALR> Think ShrinkWrap but for making bytecode
[21:51:12] <ALR> And each method cooresponded to an instruction.
[21:51:23] *** michaelschuetz has quit IRC
[21:51:27] <aslak> mm.. name?
[21:51:50] <ALR> It's unpublished, the guy hasn't released it anywhere.  It was a preso; I can get you the guy's name.
[21:52:10] <aslak> aa.. :)
[21:52:10] <ALR> aslak: This guy: http://www.meetup.com/boston-java/members/2007584/
[21:52:37] <ALR> Oh, he DID put it up
[21:52:37] <ALR> https://github.com/dougqh/JAK
[21:53:27] <ALR> Taking this to #jboss-as7
[21:53:37] <ALR> Ah, but Stuart's not awake now.
[21:53:51] <ALR> He practically lives on Mars.
[21:53:56] <aslak> hehe
[21:54:55] <ALR> aslak: For instance check this out:
[21:54:56] <ALR> https://github.com/dougqh/JAK/blob/master/net.dougqh.jak/test-src/net/dougqh/jak/api/ClassLoaderTest.java#L54
[21:55:22] <aslak> right, static method chaining..
[21:55:54] <ALR> Yeah, with class building grammars.
[21:55:55] <ALR> Nice DSL
[21:56:25] <ALR> aslak: Why do you ask?
[21:57:01] <nickarls> No more CNFE, you can make them on the fly if they're missing! No... wait.
[21:57:21] <ALR> That's why I like Byteman.
[21:57:25] <aslak> ALR, no, just though id throw it in in the "generating java source code" thread dan started
[21:57:25] <ALR> Code works?
[21:57:30] <ALR> Now it's doesn't!
[21:57:34] <ALR> *it
[21:57:54] <ALR> aslak: I think the missions are different.
[21:58:03] <ALR> aslak: But sure, throw it in.
[21:58:12] <ALR> In Dan's Thread I think the more relevant thing is:
[21:58:23] <ALR> Gen source > Compile that > Stuff the result into SW
[21:58:25] <aslak> but i have no more info then stuart is working on something.. hehe
[21:58:35] <ALR> I wonder what he needs it for?
[21:58:43] <ALR> Unless it's a side thing unrelated to AS7.
[21:59:07] <aslak> i 'think' it's used for proxy generation in as7.. don't quot eme on that tho
[21:59:26] <aslak> dmlloyd, ^
[21:59:46] *** lightguard_jp is now known as lightguard_jp_aw
[22:00:20] <aslak> ALR, your right.. that thread is more about source gen, not class gen
[22:00:22] *** johnament has joined #jbosstesting
[22:02:53] * dmlloyd reads back
[22:04:23] <dmlloyd> yeah it's class generation for proxies
[22:04:41] <ALR> dmlloyd: I emailed Stuart pointing him to it.
[22:04:58] <dmlloyd> sun has a source generation library which is pretty good (though completely undocumented)
[22:05:00] <ALR> Made for an impressive presentation.
[22:05:14] <dmlloyd> jamezp used it for the logger generation thing
[22:05:28] <ALR> Yeah, we're talking about that. in particular.
[22:05:42] <ALR> And how it overlaps w/ Lincoln's stuff in Seam Forge
[22:06:10] <dmlloyd> I know that the solder people were leveraging it for annotation-driven logger generation
[22:06:24] <dmlloyd> the jboss-logging-tools project I mean
[22:06:27] <ALR> Yup.
[22:06:37] <ALR> Dan's working now on unifying everyone so we don't duplicate efforts.
[22:07:06] <ALR> I just slapped him for making it an email chain and not a forum thing. :)
[22:07:08] <dmlloyd> okay.  please have him keep jamezp in the loop
[22:07:14] <ALR> James is on the Thread.
[22:07:18] <dmlloyd> cool.
[22:07:29] * dmlloyd will merge what ever comes out of that :)
[22:08:30] <aslak> I think dan was talking about the sodler currently had a forked v. of jboss-logging. something about having it generate a more dynamic proxy to not tie it to jboss or soemthing.. not 100% clear on the details
[22:08:32] <dmlloyd> stuart has just arrived into #jboss-as7 from mars
[22:08:39] <dmlloyd> a.k.a new employee orientation :)
[22:08:49] *** lightguard_jp_aw is now known as lightguard_jp
[22:08:52] <ALR> Ah cool.
[22:37:42] *** ldimaggi has quit IRC
[22:40:45] *** michaelschuetz has joined #jbosstesting
[23:02:53] *** johnament has left #jbosstesting
[23:43:20] *** maeste_afk has quit IRC
[23:43:48] *** maeste_afk has joined #jbosstesting
[23:45:51] *** maeste_afk has quit IRC
[23:46:18] *** maeste_afk has joined #jbosstesting
[23:54:59] *** wolfc has quit IRC





top