[00:11:55] *** michaelschuetz has quit IRC
[00:38:50] *** nickarls has quit IRC
[00:38:50] *** marcel has quit IRC
[00:41:59] *** nickarls has joined #jbosstesting
[00:41:59] *** marcel has joined #jbosstesting
[00:55:04] *** mgoldmann_ has quit IRC
[02:10:25] *** rruss has quit IRC
[02:23:59] *** ldimaggi has joined #jbosstesting
[02:42:34] *** ianbrandt has quit IRC
[05:17:23] *** rruss has joined #jbosstesting
[05:22:41] *** jganoff has joined #jbosstesting
[05:26:01] *** jganoff has quit IRC
[05:26:48] *** rruss has quit IRC
[05:41:34] *** ldimaggi has quit IRC
[05:42:03] *** bobmcw has quit IRC
[05:42:03] *** bobmcw_ has joined #jbosstesting
[05:55:12] *** bobmcw_ is now known as bobmcw
[05:55:13] *** bobmcw has joined #jbosstesting
[05:59:33] *** oskutka has joined #jbosstesting
[06:25:30] *** bgeorges has joined #jbosstesting
[06:33:10] *** oskutka has quit IRC
[07:04:40] *** kpiwko has joined #jbosstesting
[07:18:35] *** oskutka has joined #jbosstesting
[07:29:35] *** jeand has joined #jbosstesting
[08:14:02] *** tdiesler has joined #jbosstesting
[08:16:47] *** jharting has joined #jbosstesting
[08:32:35] *** maschmid has joined #jbosstesting
[08:44:45] *** maeste has joined #jbosstesting
[08:52:29] *** bgeorges has quit IRC
[09:03:07] *** davidbos has joined #jbosstesting
[09:04:38] *** aaronwalker has quit IRC
[09:14:20] *** lfryc has joined #jbosstesting
[09:22:51] *** PeteRoyle has quit IRC
[09:33:23] *** PeteRoyle has joined #jbosstesting
[09:37:27] *** PeteRoyle has quit IRC
[09:38:47] *** OndraZizka has joined #jbosstesting
[09:40:12] *** OndraZizka is now known as OndrejZizka
[09:40:37] *** OndrejZizka has joined #jbosstesting
[09:47:57] *** michaelschuetz has joined #jbosstesting
[09:57:01] *** mgoldmann has joined #jbosstesting
[10:03:24] *** michaelschuetz1 has joined #jbosstesting
[10:05:13] *** lightguard_jp has quit IRC
[10:05:15] *** michaelschuetz has quit IRC
[10:19:59] *** galderz has joined #jbosstesting
[10:20:49] *** mgoldmann has quit IRC
[10:21:20] *** mgoldmann has joined #jbosstesting
[10:33:13] *** michaelschuetz1 has quit IRC
[10:33:57] *** michaelschuetz has joined #jbosstesting
[10:45:50] *** tdiesler has quit IRC
[10:46:47] *** michaelschuetz has quit IRC
[10:48:20] *** michaelschuetz1 has joined #jbosstesting
[10:48:22] *** tdiesler has joined #jbosstesting
[10:57:06] *** OndrejZizka has quit IRC
[10:57:56] *** maschmid is now known as maschmid_lunch
[11:02:48] *** tdiesler has quit IRC
[11:03:12] *** tdiesler has joined #jbosstesting
[11:10:32] *** tdiesler has quit IRC
[11:10:55] *** tdiesler has joined #jbosstesting
[11:26:15] *** tdiesler has quit IRC
[11:26:37] *** tdiesler has joined #jbosstesting
[11:27:35] *** davidbos has quit IRC
[11:31:01] *** galderz has quit IRC
[11:31:12] *** michaelschuetz1 has quit IRC
[11:31:58] *** michaelschuetz has joined #jbosstesting
[11:39:11] *** tdiesler has quit IRC
[11:39:35] *** tdiesler has joined #jbosstesting
[11:40:43] *** davidbos has joined #jbosstesting
[11:45:31] *** tdiesler has quit IRC
[11:45:47] *** tdiesler has joined #jbosstesting
[11:46:57] *** tdiesler has quit IRC
[11:47:19] *** tdiesler has joined #jbosstesting
[11:55:36] *** maschmid_lunch is now known as maschmid
[12:13:03] *** davidbos has quit IRC
[12:24:31] *** galderz has joined #jbosstesting
[12:33:54] *** mgoldmann has quit IRC
[12:33:58] *** davidbos has joined #jbosstesting
[12:35:11] *** galderz has quit IRC
[12:41:27] *** tdiesler has quit IRC
[12:42:40] *** aslak has joined #jbosstesting
[12:55:43] *** michaelschuetz has quit IRC
[12:56:28] *** michaelschuetz has joined #jbosstesting
[12:56:50] *** oskutka has quit IRC
[13:06:27] *** ldimaggi has joined #jbosstesting
[13:09:01] *** PeteRoyle has joined #jbosstesting
[13:11:22] *** oskutka has joined #jbosstesting
[13:14:36] <kpiwko> heya aslak!
[13:19:11] *** vtunka has joined #jbosstesting
[13:20:08] <aslak> kpiwko, heya
[13:21:15] <kpiwko> aslak: how is progress on beta1 going on? do you plan to release it today?
[13:21:53] <aslak> kpiwko, no, geecon took to much time. :) early next week
[13:22:16] <kpiwko> aslak: great, I have a free saturday so can hack few things as well during weekend
[13:22:19] <kpiwko> :)
[13:22:44] <aslak> kpiwko, i have a patch for you bttw, drone update against arq-core
[13:23:05] <aslak> last minute hackup before the demo yesterdya
[13:24:01] <kpiwko> aslak, good to know, that's what I just started doing
[13:24:21] <kpiwko> aslak: did you spit drone to modules?
[13:24:31] <aslak> kpiwko, nope
[13:24:49] *** davidbos has quit IRC
[13:24:56] <kpiwko> aslak: so there's still something left for me to do
[13:26:41] <kpiwko> aslak: we (lfryc and me) would like to move ajocado - drone related stuff to ajocado, because last release of ajocado required modifications in drone which should not happen
[13:27:21] <kpiwko> aslak: so a modularization of drone will be handy...moroever, it would align with the rest of the arq
[13:27:39] <kpiwko> aslak: where is your patch so I can apply it to my trunk?
[13:30:00] *** aslak has quit IRC
[13:44:52] *** mgoldmann has joined #jbosstesting
[13:46:18] *** bgeorges has joined #jbosstesting
[13:46:23] *** bgeorges has quit IRC
[13:48:07] *** bgeorges has joined #jbosstesting
[13:53:17] *** bgeorges has quit IRC
[13:54:38] *** bgeorges has joined #jbosstesting
[13:55:18] *** aslak has joined #jbosstesting
[13:55:41] <aslak> kpiwko, ugh, krakow apartment network fell down for a bit..
[13:55:49] <aslak> kpiwko, https://github.com/arquillian/arquillian-extension-drone/tree/ARQ-361
[13:55:51] <jbossbot> jira [ARQ-361] Split up Arquillian repository [Coding In Progress (Unresolved) Feature Request, Major, Aslak Knutsen] https://issues.jboss.org/browse/ARQ-361
[13:56:17] <aslak> kpiwko, some more spi package names changes coming, but that should run against arq-core
[13:56:19] <aslak> current
[13:57:11] <aslak> kpiwko, you might want to look at depending only on arquillian-test-spi|api and not arquillian-container-testspi/container-spi, that will allow you to run Drone without the need for a Container etc, as we spoke about on confess
[13:57:39] <kpiwko> aslak: great
[14:01:28] *** torben has joined #jbosstesting
[14:02:16] *** kenglxn has joined #jbosstesting
[14:02:35] *** kenglxn has quit IRC
[14:11:54] *** Jaikiran has joined #jbosstesting
[14:22:09] <hatchetman82> is it possible to attach an interceptor to an EJB method without touching neither the EJB nor its deployment descriptor ?
[14:22:27] <hatchetman82> ....some runtime CDI voodoo maybe ?
[14:30:34] <kpiwko> aslak: once there is LoadableExtension, is DroneProfile still necessary?
[14:31:49] *** oskutka has quit IRC
[14:32:59] *** tdiesler has joined #jbosstesting
[14:34:46] *** tdiesler has quit IRC
[14:35:03] *** tdiesler has joined #jbosstesting
[14:36:46] <aslak> kpiwko, no, DroneProfile is replaced by LoadableExtension
[14:37:12] <kpiwko> aslak: I'll remote that file than
[14:37:18] <kpiwko> *then
[14:38:23] <hatchetman82> ..
[14:38:29] *** mgoldmann has quit IRC
[14:38:29] *** mgoldmann_ has joined #jbosstesting
[14:39:27] <aslak> hatchetman82, bytemanipulation ? ;)
[14:39:38] *** alesj has joined #jbosstesting
[14:39:56] <hatchetman82> @runtime ?
[14:40:04] <hatchetman82> dont think thats possible
[14:40:11] <aslak> JavaAgent
[14:40:15] <aslak> hehe
[14:40:25] <hatchetman82> way to extreme :-)
[14:40:40] <aslak> hatchetman82, runtime, you want to enable/add a interceptor to a running EJB ?
[14:40:44] <hatchetman82> its just that i've managed a nice little test setup so far without touching the production *.ear
[14:41:13] <hatchetman82> i have the prod.ear pre-deployed. arq. builds a test.ear with the local interface jars to everything
[14:41:24] <hatchetman82> both ears share th same classloader conf
[14:41:51] <hatchetman82> this way the test.ear can access pretty much everything in the prod.ear and i can use the same @Deployment to test everything
[14:42:03] <hatchetman82> only thing im missing is a way to "serialize" JMS calls
[14:42:36] <hatchetman82> in my older tests i'd have an interceptor around MDB methods that would maintain a global lock
[14:43:09] <hatchetman82> so test code would fire a message over JMS, wait on the global lock and be released when the MDB has finished
[14:43:22] <hatchetman82> but in this setup i cant touch the prod.ear
[14:43:37] <aslak> right
[14:43:51] <hatchetman82> so i need to find a way to add those interceptors around the MDB methods when the test.ear boots
[14:43:52] <aslak> topic ?
[14:44:06] <aslak> well, it won't be when the mdb is done tho
[14:44:14] <aslak> but you could get at the message
[14:44:40] <hatchetman82> you mean fetch the queue control from JMX and poll until the queue is empty ?
[14:45:04] <hatchetman82> tried that, but its not very elegant.
[14:45:28] <aslak> hatchetman82, no i meant if the point was to get the Message, and your prod.ear MDB is using a Topic, your test deployment could deploy a MDB/Listener that listens to the same topic, both would get the message
[14:45:44] <hatchetman82> oh.
[14:45:51] <hatchetman82> no, the test ear is the one doing the sending
[14:46:12] <hatchetman82> there's a prod component thats supposed to respond and eventually change something in the DB
[14:46:31] <hatchetman82> i'd like for the test code to wait for the message to be processed and then go looking at the DB
[14:46:43] <aslak> yea
[14:46:54] <hatchetman82> right now its Thread.sleep(10000), but you can imagine what that does to build run times :-)
[14:47:15] <aslak> i think this is ByteMan food. not sure how you can change the prod mdb with your new deployment
[14:48:02] <hatchetman82> if i specify some CDI annotation on the prod code without having any interceptors in the prod ear, will it explode ?
[14:48:33] <hatchetman82> (similar to my test ear exploding when i added CDI with that shrinkwrap example in it a couple of days ago)
[14:48:46] <aslak> hatchetman82, but even if you did, deploying your test deployment wil not effect the already deployed prod.ear
[14:51:03] <hatchetman82> weld wont work across ears ?
[14:51:27] <hatchetman82> even with that classloader trick that allows me local interface access across ears ?
[14:52:28] <aslak> nope
[14:52:51] <aslak> Weld is pr Deployment
[14:53:40] <aslak> or pr TopLevel Deployment with sub Managers in the nested Deployments..  but to my knowledge anyway, a extension in one deployment can not effect another
[14:54:01] *** tdiesler has quit IRC
[14:54:27] *** tdiesler has joined #jbosstesting
[14:57:44] <hatchetman82> ok,
[14:57:47] <hatchetman82> thanks
[15:21:23] *** mgoldmann_ has quit IRC
[15:37:54] *** michaelschuetz has quit IRC
[15:38:36] *** michaelschuetz has joined #jbosstesting
[15:51:55] <ALR> aslak, tdiesler: 7ish min?
[15:58:07] *** tdiesler has quit IRC
[16:02:29] *** PeteRoyle has quit IRC
[16:06:24] *** rruss has joined #jbosstesting
[16:08:59] *** Jaikiran is now known as Jaikiran|AFK
[16:13:59] *** maschmid has quit IRC
[16:15:15] *** alesj has quit IRC
[16:17:11] *** PeteRoyle has joined #jbosstesting
[16:19:55] *** vtunka has quit IRC
[16:24:29] *** PeteRoyle has quit IRC
[16:31:19] *** kpiwko has quit IRC
[16:32:44] *** tdiesler has joined #jbosstesting
[17:04:39] *** michaelschuetz has quit IRC
[17:13:14] *** jharting has quit IRC
[17:19:26] *** aslak has quit IRC
[17:28:36] *** davidbos has joined #jbosstesting
[17:28:46] *** davidbos has quit IRC
[17:33:47] <jbossbot> git [shrinkwrap] push master 10f4905.. Andrew Lee Rubinger [SHRINKWRAP-276] Some issues shown in the OpenEJB reader with the new ZIP Exporter....
[17:33:48] <jbossbot> jira [SHRINKWRAP-276] Invalid byte stream for ZipExporter [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-276
[17:33:48] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/332b1ab...10f4905
[17:38:49] *** ldimaggi has quit IRC
[17:39:12] *** ldimaggi has joined #jbosstesting
[18:09:27] *** aslak has joined #jbosstesting
[18:19:41] *** vtunka has joined #jbosstesting
[18:39:24] *** ianbrandt has joined #jbosstesting
[18:46:59] <ianbrandt> aslak, Greetings.  Would you have a moment to discuss an embedded container classloader issue I'm blocked on?... http://community.jboss.org/thread/166645
[19:00:23] *** bgeorges has quit IRC
[19:02:34] *** mgoldmann has joined #jbosstesting
[19:02:40] *** mgoldmann has quit IRC
[19:02:40] *** mgoldmann has joined #jbosstesting
[19:05:24] *** mgoldmann_ has joined #jbosstesting
[19:08:48] *** mgoldmann has quit IRC
[19:11:32] *** ge0ffrey has quit IRC
[19:26:52] *** vtunka has quit IRC
[19:36:21] <ALR> aslak: How do you handle JIRA for the containers in separate release cycles?
[19:36:36] <ALR> Still under ARQ?  What fix versions do you use?
[19:41:27] <aslak> ALR, eh, not sure yet.. currently they are under arq, and will probably have versions like JBOSS_1.0.0
[19:41:44] <ALR> Yeah.
[19:41:49] <ALR> Such a JIRA shortcoming.
[19:41:53] <aslak> yea
[20:06:29] *** rruss has quit IRC
[20:08:46] <jbossbot> git [shrinkwrap] push master d747f53.. Andrew Lee Rubinger [SHRINKWRAP-280] Remove comtainers that have been ported/forked into their own repos
[20:08:47] <jbossbot> jira [SHRINKWRAP-280] Pull out the container integration modules into their own repos [Open (Unresolved) Task, Blocker, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-280
[20:08:47] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/10f4905...d747f53
[20:15:47] *** lfryc has quit IRC
[20:18:15] <jbossbot> git [shrinkwrap] push master c5c97f1.. Andrew Lee Rubinger [SHRINKWRAP-280] Remove containers from the dist POM
[20:18:16] <jbossbot> jira [SHRINKWRAP-280] Pull out the container integration modules into their own repos [Open (Unresolved) Task, Blocker, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-280
[20:18:16] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/d747f53...c5c97f1
[20:20:06] <jbossbot> git [shrinkwrap] push master 409156f.. Andrew Lee Rubinger [SHRINKWRAP-280] Remote dist dep on tomcat6
[20:20:07] <jbossbot> jira [SHRINKWRAP-280] Pull out the container integration modules into their own repos [Open (Unresolved) Task, Blocker, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-280
[20:20:07] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/c5c97f1...409156f
[20:28:42] *** rruss has joined #jbosstesting
[20:41:52] *** mgoldmann_ has quit IRC
[20:52:28] *** Jaikiran|AFK has quit IRC
[21:02:59] <ALR> ShrinkWrap 1.0.0-beta-1: Out.
[21:03:02] <ALR> Worthy of note:
[21:03:08] <ALR> The container GAVs have moved
[21:03:12] <aslak> cool
[21:03:14] <ALR> to org.jboss.shrinkwrap.container
[21:09:08] *** michaelschuetz has joined #jbosstesting
[21:26:00] *** dblevins has quit IRC
[21:27:25] *** torben has quit IRC
[21:31:05] *** dblevins has joined #jbosstesting
[21:53:55] *** maeste has quit IRC
[21:54:08] *** tdiesler has quit IRC
[21:58:19] *** tdiesler has joined #jbosstesting
[22:00:51] *** tdiesler has quit IRC
[22:03:03] <ianbrandt> aslak, I've switched to the Jetty 6&7 containers to pass the time, and have hit another issue there.  What seems to be happening is org.jboss.arquillian.junit.Arquillian is initializing twice, once for the launch, and then again for the in-container test.  The ThreadLocal (deployableTest.get() == null) check is failing because the in-container test is running in a org.mortbay.thread.QueuedThreadPool thread, whereas launchi
[22:03:03] <ianbrandt> test happens on the main thread.  The result is the ContainerEventController is firing StartManagedContainers twice, and I of course get a port already in use exception.  Have you encountered this at all before?
[22:04:35] <aslak> ianbrandt, hmmm, yea.. it should be initialized twice, once for the client side and once for the incontainer side
[22:05:03] <aslak> ianbrandt, the problem is that the arquillian LoadableExtensions from the client is leaking into the embedded server
[22:05:26] <aslak> ianbrandt, so it's basically initializing the client side again
[22:05:58] <aslak> ianbrandt, as far as you ClassCastException, it's the same thing
[22:06:01] <ianbrandt> Ah, I wondered if this wouldn't be oddly related to my tomcat issue.
[22:06:14] <aslak> you/your
[22:06:58] <aslak> some Arquillian Classes are loaded in the War, but the LoadableExtension from AppCL leaks into Jetty, but when trying to load the extension from within the container it has two versions of that class and fails
[22:07:21] <ianbrandt> What do you think about the bootstrap Thread.setContextClassLoader idea?  Seems like a major change though.
[22:08:30] <aslak> ianbrandt, the 'fix' in Alpha5 was to set Jetty to do parent delegation first in the classloaders. In Alpha5 Arquillian had a extension point called Profile, which has a clinet side and a container side of extensions. but this has changed in current core, where the container side only exists as a new set o LoadableExtensions in the deployment
[22:08:53] <aslak> ianbrandt, won't work. AppCl will still leak
[22:09:16] <aslak> ianbrandt, it's the basic issue with Embedded containers, what ever shit you have on the appcl, it will mess with the runtime
[22:09:58] <aslak> ianbrandt, i have been wanting to explore the idea of just forking a new vm when we deal with embedded
[22:12:36] <aslak> or not just embedded, all containers in general. specially in the case of multiple contianers running on the same cp as well. it's to easy to mess up some lib on appCl that makes them fail
[22:13:35] <aslak> just two client libs from the same container in two different versions will cause trouble.
[22:14:40] <aslak> i had some attempt in Alpha5 of doing a ClassLoader pr Container, but it's tricky to get right, and how ever you do it, it will never be 100%
[22:16:04] <ianbrandt> I'm not a classloader expert by any means.  So you're saying you can't create new classloader that doesn't ultimately delegate back to the system/app cl?
[22:17:13] <ianbrandt> This thread was leading me to believe you could: http://comments.gmane.org/gmane.comp.jakarta.tomcat.user/210932
[22:18:08] <ianbrandt> If not forking a VM probably would be preferable.  I bet you'd just never hear the end of leakage issues otherwise.
[22:19:31] <ianbrandt> I mean if someone knows what they're doing and really wants to run embedded using the app classloader to supply the container libs okay, but I would think it'd still take a lot of care to keep the Arquillian instrumentation compliant.
[22:20:07] <aslak> ianbrandt, well yea, in this case tomcat is not on the appcl tho, he loads tomcat in a new cl
[22:20:09] <ianbrandt> Bet even then as embedded is a newer trend for Tomcat at least I wonder if other issues wouldn't pop up there.
[22:20:59] <ianbrandt> That's what I was proposing.
[22:21:40] <aslak> ianbrandt, that's what i did in Alpha5
[22:22:05] <aslak> ianbrandt, but you still have Arq on AppCl
[22:22:33] <aslak> which is what tomcat is finding to begin with
[22:23:06] <aslak> so then i started adding some filtering to the classloader to allow some stuff through and some stuff not.. and that's where it all got a bit iffy
[22:24:27] <aslak> since it's always the case that someone else is starting/bootstrapping Arquillian, we basically ahve no control over our own environment
[22:24:50] <ianbrandt> aslak, Just to make sure I'm following, when you say app cl do you mean what Tomcat would call the webapp's classloader, or the initial test launching system classloader (http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html)?
[22:25:16] <aslak> java -cp xxxxx
[22:26:22] <ianbrandt> Ah, got it.
[22:27:38] <ianbrandt> So I guess my thinking was with the bootstrap technique I could jail that off from the container, so the in-container test sees only what of arquillian is added to the webapp's libs.
[22:28:11] <ianbrandt> Then whatever of arquillian is needed to launch the embedded container, it won't get mixed up with the in-container test.
[22:28:34] <ianbrandt> So no leakage, but then of course each set needs to stand on it's own.
[22:29:04] <ianbrandt> But if Thead.setContextClassloader can't do that then I'm mistaken.
[22:29:20] <aslak> ianbrandt, yea, this is basically the Managed Container types
[22:30:22] <aslak> it's not really isolated to embedded containers, it's just a lot easier to make those fail
[22:30:42] <ianbrandt> just my luck ;)
[22:32:39] *** ldimaggi has quit IRC
[22:32:51] <aslak> :)
[22:39:31] <aslak> ianbrandt, my current thought is to fork of a new jvm pr container in the test, bootstrap it with the client lib/container/ what ever other thing is needed to start it, and a small arq remote mbean client. then communicate with that jvm for deployment etc over mbeans
[22:39:49] <aslak> but i haven't explored how yet
[22:47:39] <ianbrandt> aslak, So where I'm feeling at a disadvantage here is I'm still very familiar with the arquillian core API/impl.  Given a set core architecture/paradigm I could work out VM forking, classloader jailing, Mbeans etc. for the individual containers no problem, but when it comes to hacking on the core I still have a lot to learn before I would think I'd be the most qualified choice.
[22:48:04] <ianbrandt> (still not very familiar...)
[22:51:01] <aslak> ianbrandt, but what you do know for now is how to make a container
[22:52:18] <ianbrandt> aslak, I'm at least starting to get my head around that yes.
[22:52:24] <aslak> ianbrandt, a first start could be to remove the tomcat embedded libs from the appcl, and do the bootstrapping you have in those blog posts, but do it in the within the container only
[22:52:29] <aslak> arquillian would be non the wiser
[22:52:52] <aslak> do it within
[22:53:14] <aslak> basically a DeployableContainer that during start will 'bootstrap' up the new container within its own classloader
[22:53:36] <aslak> ianbrandt, sounds doable?
[22:53:42] <ianbrandt> Yes, that's exactly what I was suggesting originally.
[22:54:07] <aslak> ianbrandt, aa. ok. i missunder stood you then. i thought you wanted to do it on a higher level
[22:55:15] <aslak> hmm.. if that work, gthat would solve a lot. we could bootstrap all containers in the same fhasion. moving the deps from appcl to arq.xml container config etc
[22:55:28] <ianbrandt> ah, no no.  I wanted to bootstrap the container starting.  I guess I'd have to work out cross thread communication for stopping, etc. but that I can do.
[22:56:21] <aslak> ianbrandt, cool, test that. and see if you can make it a general 'bootstrap' what ever container as you go. :)
[22:57:43] <aslak> excellent..
[22:58:40] <aslak> i gotta get some sleep for the presentation to morrow.. :)
[22:59:46] <ianbrandt> aslak, So I guess what I'm starting to realize is that my Tomcat and Jetty issues are not because leaking was being depended upon by the in-container test.  It was because leaking was occurring the arquillian API provided to the in-container test is doing more than it would otherwise.  I.e. the LoadableExtension mechanism was loading more than intended.  So for my Tomcat problem ServletExtension shouldn't even be loaded
[22:59:47] <ianbrandt> in-container.  And for my Jetty issues Arquillian shouldn't reinitialize under another thread, causing another Jetty startup from the tests running within the first startup.  Does all that sound about right?
[23:00:32] <aslak> almost
[23:00:52] <aslak> Arquillian should reinitialize, but it's being reinitialized with the wrong LoadableExtensions
[23:01:51] <ianbrandt> Ah, okay, got it.  Lightbuld! ;)
[23:01:58] <aslak> :)
[23:03:44] <aslak> keep me posted on your progress. this is interesting stuff.
[23:03:47] <aslak> night ! :)
[23:03:53] <ianbrandt> aslak, have a good night.  I'll try the classloader bootstrap and report back.  Thanks@
[23:03:55] <ianbrandt> !
[23:13:52] *** jeand has quit IRC
[23:14:52] *** aslak has quit IRC
[23:25:15] *** hatchetman82 has quit IRC





top