[00:01:06] <jbossbot> git [shrinkwrap] push master cf1978b.. Andrew Lee Rubinger [SHRINKWRAP-266] Fix compile errors and rebase off current master
[00:01:07] 
[00:01:07] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/e4e313c...cf1978b
[00:02:02] *** alesj has quit IRC
[00:08:09] <jbossbot> git [shrinkwrap] push master d3bd9e4.. Tommy Tynja SHRINKWRAP-191 Added convenience method to add default MANIFEST.MF to ManifestContainers.
[00:08:10] 
[00:08:10] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/cf1978b...d3bd9e4
[00:13:47] <jbossbot> git [shrinkwrap] push master b397b22.. Ivan Pazmino javadoc for default extensions loading strategy
[00:13:47] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/d3bd9e4...b397b22
[00:15:45] <tdiesler> ALR, ?
[00:15:50] <ALR> tdiesler: ?
[00:16:37] <tdiesler> ALR, here is the latest https://github.com/tdiesler/jboss-as/tree/as734
[00:17:03] <ALR> tdiesler: Yep, my last run had everything there except your latest commit
[00:17:43] <tdiesler> ALR, you need to clone https://github.com/tdiesler/arquillian-core/tree/as734 and https://github.com/tdiesler/arquillian-container-osgi/tree/as734
[00:18:04] <ALR> tdiesler: That could be it; it's depending on SNAPs of those projects?
[00:18:39] <tdiesler> ALR, you should see a good build and managed container failing with ...
[00:18:47] <ALR> If so we gotta deploy the SNAPs, is all.
[00:18:59] <ALR> Aha
[00:18:59] <ALR> [ERROR] Failed to execute goal on project jboss-as-arquillian-common: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-common:jar:7.0.0.Beta4-SNAPSHOT: Could not find artifact org.jboss.arquillian.container:arquillian-container-osgi:jar:1.0.0-SNAPSHOT in jboss-public-repository-group (http://repository.jboss.org/nexus/content/groups/public/) -> [Help 1]
[00:19:02] <ALR> Yeah.
[00:19:09] <ALR> I'll bring in those and deploy the SNAPs.
[00:19:16] <ALR> So we can get at 'em from remote Hudsons.
[00:19:30] <tdiesler> ALR, http://fpaste.org/gKA0/
[00:19:49] <ALR> tdiesler: Hmm, managed container will then fail?
[00:20:04] <ALR> Do you know why?
[00:20:36] <ALR> (My latest patch should have a META-INF/services file to configure the ArquillianResource)
[00:20:40] <tdiesler> ALR, The status is that the arq service cannot get configured when it receives the first request
[00:20:56] <ALR> tdiesler: Wanna touch base in the AM, U.S. time tomorrow?
[00:21:04] <ALR> I'll clear some other tasks and we'll massage this back in place?
[00:21:15] <ALR> So afternoon for you?
[00:21:20] <tdiesler> ALR, I suggest you build those core and osgi container branches and the as7
[00:21:27] <ALR> Absolutely will.
[00:21:59] <tdiesler> ALR, shall I wait until you can reproduce the error?
[00:22:13] <ALR> tdiesler: Where are the SNAPs declared in AS7?
[00:22:41] <tdiesler> ALR, top level pom
[00:22:54] <ALR> Ah I see it
[00:23:04] <ALR> Was grepping on the build POM, common mistake :)
[00:23:07] <tdiesler> ALR, I removed all references to "the other" ARQ version
[00:23:28] <ALR> Saw that, yay!@
[00:24:16] <tdiesler> ALR, one thing to know is that the arq service deployment declares a single dependency on org.jboss.as.arquillian.service
[00:24:56] <ALR> tdiesler: I'm building your ARQ forks now.
[00:25:03] <tdiesler> ALR, so it is currently not self contained. The initialization error proabbaly comes from that module not seeing the right set of META-INF/services
[00:25:33] <ALR> Hrm.
[00:25:43] <ALR> If I can duplicate it, I can look-see why :)
[00:25:53] <ALR> So doing the building.
[00:25:53] <tdiesler> ALR, ok I'll wait
[00:27:56] <ALR> Hero.
[00:28:20] <ALR> ARQ branches built, AS7 chugging now
[00:29:40] <aslak> arq fork ?
[00:29:53] <aslak> aa.. the osgi branch
[00:30:05] <tdiesler> aslak, core as well ;-)
[00:30:16] <ALR> https://github.com/tdiesler/arquillian-core/tree/as734 and https://github.com/tdiesler/arquillian-container-osgi/tree/as734
[00:30:32] <tdiesler> aslak, a few changes to the JMX protocol
[00:30:34] <ALR> tdiesler has become authoritative.
[00:30:36] <ALR> :P
[00:31:03] <ALR> tdiesler: You tweet?
[00:31:25] <ALR> Found 'em.
[00:31:37] <ALR> Once, last July.  Power user.
[00:31:49] <aslak> i'll have a look in the morning..
[00:31:57] <aslak> bed time.. night :)
[00:32:04] <ALR> aslak: Nighty.
[00:32:31] *** aslak has quit IRC
[00:33:20] <ALR> tdiesler: Running org.jboss.as.arquillian.container.managed.IntegrationTestCase
[00:33:20] <ALR> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.424 sec
[00:33:32] <tdiesler> ALR, yes.
[00:33:43] <ALR> Ah I see:
[00:33:43] <ALR> Running org.jboss.as.arquillian.container.managed.JBossASManagedInContainerTestCase
[00:33:43] <ALR> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.139 sec <<< FAILURE!
[00:33:44] <ALR> Running org.jboss.as.arquillian.container.managed.JBossASManagedAsClientTestCase
[00:33:44] <ALR> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.764 sec <<< FAILURE!
[00:33:45] <tdiesler> ALR, that is legacy.
[00:34:13] <ALR> Legacy? That's arquillian2
[00:34:18] <ALR> Which I upgraded to the new ARQ
[00:35:01] <tdiesler> ALR, Running org.jboss.as.arquillian.container.managed.JBossASManagedAsClientTestCase
[00:35:01] <tdiesler> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.698 sec
[00:35:17] <tdiesler> ALR, as client should pass
[00:35:24] <ALR> tdiesler: As Client failing here
[00:35:40] <ALR> Caused by: java.util.concurrent.ExecutionException: java.lang.Exception: {"Services which failed to start:" => ["service module.service.\"deployment.sar-example.sar\".main"]}\
[00:35:46] <ALR> Deployment problem
[00:36:11] <tdiesler> ALR, try running as in a diffent shell first
[00:36:34] <ALR> tdiesler: ie...opening a new shell?  Or just cd-ing into the directory?
[00:36:35] <tdiesler> ALR, then you won't have bootstrap issues and can debug the server
[00:36:55] <ALR> tdiesler: I'm pushing SNAPs of those OSGi forks remote.
[00:36:59] <ALR> And will run in my Hudson
[00:37:27] <tdiesler> ALR, it needs manual massaging right now.
[00:37:33] <ALR> k
[00:37:53] <ALR> What's being massaged?
[00:37:54] <tdiesler> ALR, lets see if you can get the arq service to deploy and receive the test request
[00:38:22] * ALR awaiting new instructions to massage
[00:38:30] <ALR> Like...what of the new shell?
[00:38:42] <tdiesler> ALR, what I do is run as7 in a differnt shell and the cd into jboss-as/arquillian
[00:38:55] <tdiesler> ALR, from there I run 'mvn install'
[00:38:57] <ALR> tdiesler: You mean you start AS7 first?
[00:39:02] <tdiesler> ALR, yes
[00:39:04] <ALR> Oh.
[00:39:17] <ALR> That's not gonna work for the AS7 build. :P
[00:39:42] <ALR> The managed container won't start it properly?
[00:39:44] <tdiesler> ALR, sure, but lets first fix the basic problems
[00:40:08] <ALR> A running build to me is the most basic. :)
[00:40:19] <ALR> Starting AS7 manually.
[00:40:24] <tdiesler> ALR, I know, but if that does not work that managed container won't either.
[00:41:33] <ALR> tdiesler: Odd.  Apparently I had a running AS somewher
[00:41:36] <ALR> *somewher
[00:41:40] <ALR> *somewhere
[00:42:03] <ALR> Ah, from a deceased Eclipse instance
[00:42:07] <tdiesler> ALR, you need to run the as734 build/target/ jboss.. of course
[00:42:16] <ALR> Course
[00:42:29] <ALR> So I have AS7 up.
[00:42:37] <ALR> Now running mvn install from arquillian/ of AS7
[00:42:59] <tdiesler> ALR, ok. You should see the arq service deploy
[00:43:02] <ALR> Client passes
[00:43:09] <ALR> InContainer fails.
[00:43:34] <tdiesler> ALR, with http://fpaste.org/gKA0/ ?
[00:44:46] <ALR> tdiesler: Yeah, at the end of the trace, Caused by: java.lang.IllegalArgumentException: No resource META-INF/services/org.jboss.arquillian.config.descriptor.api.ArquillianDescriptor was found configured for user view class org.jboss.arquillian.config.descriptor.api.ArquillianDescriptor
[00:45:49] <tdiesler> ALR, ok. Now you can figure out why ARQ cannot get configured when the JMXTestRunner receives the first request
[00:46:11] <ALR> tdiesler: OK.  Follow-up.
[00:46:20] <ALR> Why are we using these containers, not the AS7/arquillian2 ones?
[00:47:01] <tdiesler> ALR, when this works with a running AS instance. It's likely to work in managed - if there are no other bootstrap issues - like the JSR160 connector not being up, etc ...
[00:47:41] <tdiesler> ALR, because that is where the on-demand service lived. I used your stuff as copy paste template
[00:47:53] <tdiesler> ALR, could have done the other way as well
[00:47:54] <ALR> OK, cool.  So arquillian2 is going bye-bye then.
[00:48:16] <ALR> demos2 and testsuite2 though...those get ported OK into the new place?
[00:48:17] <tdiesler> ALR, yes I send an email to the dev list yesterday
[00:48:33] <ALR> Yeah, saw that too.  Just didn't verify all made it over yet :)
[00:48:44] <ALR> Yesterday was a holiday here in the US so I'm catching up a bit from it :)
[00:48:53] <ALR> I'll have a look at these errors then
[00:48:57] <ALR> Try to understand what's up.
[00:49:09] <ALR> I gotta get an Embedded container in soon too.
[00:49:22] <ALR> I took a few stabs at that last week.
[00:49:22] <tdiesler> ALR, I'd use the same container for all test suites. When that works, I'd consilidate the tests and get rid of the xx2 stuff
[00:49:54] <ALR> I only mention demos2 and testsuite2 because they were already refactored to newer versions of ARQ.
[00:50:02] <ALR> Hence shouldn't need to be touched; just moved.
[00:50:10] <tdiesler> ALR, yes
[00:50:40] <ALR> tdiesler: Also, I don't need to run the AS anymore it looks like
[00:50:43] <ALR> In another terminal
[00:50:46] <ALR> To see the right errors.
[00:51:01] <ALR> I was getting problems I think before because of an orphaned AS instance running)
[00:51:10] <tdiesler> ALR, the tests in managed container is the first hurdle. then I can migrate smoke and integration
[00:51:18] <ALR> Word up.
[00:51:22] <tdiesler> ALR, yes I saw that too
[00:51:42] <tdiesler> ALR, you're good to go, right?
[00:51:47] <ALR> Cool, let's talk tomorrow.
[00:51:51] <ALR> tdiesler: Looks that way.
[00:51:53] <ALR> Sleep tight.
[00:51:56] <ALR> And thanks.
[00:51:57] <tdiesler> ALR, yes - merci & god night
[00:52:03] *** tdiesler has left #jbosstesting
[01:03:21] *** johnament has joined #jbosstesting
[01:11:29] *** johnament has quit IRC
[01:22:41] *** johnament has joined #jbosstesting
[02:24:18] *** ldimaggi has joined #jbosstesting
[03:46:33] *** adinn has joined #jbosstesting
[05:03:22] *** burrsutter_ has quit IRC
[05:35:30] *** ldimaggi has quit IRC
[05:53:08] *** OndraZizka has quit IRC
[05:53:25] *** OndraZizka has joined #jbosstesting
[07:01:48] *** nickarls has quit IRC
[07:13:34] *** oskutka has joined #jbosstesting
[08:01:03] *** lightguard_jp has quit IRC
[08:23:46] *** kpiwko has joined #jbosstesting
[08:41:30] *** ge0ffrey has joined #jbosstesting
[08:43:11] *** aslak has joined #jbosstesting
[08:54:41] *** maschmid has joined #jbosstesting
[08:55:48] *** tdiesler has joined #jbosstesting
[08:55:56] <tdiesler> ALR, still up?
[08:56:22] <tdiesler> aslak, moin
[08:56:58] <aslak> tdiesler, heya.. not still up but just got up.. :)
[08:57:11] <aslak> oh sorry, missed the name there.. hehe
[08:57:26] <aslak> tdiesler, obviously not quite up yet..
[08:59:23] <tdiesler> aslak, if you were following last night discussion ... the arq system does not get configured properly when the first request comes in. I was thinking, in AS7 we have the fundamental difference that the arq infrastructure lives in a seperate deployment. Would it not be possible to get that infrastructure initialized when the arq service starts up (i.e. when the JMXTestRunner gets registered)?
[09:00:33] <aslak> tdiesler, the configuration happens only on client side
[09:01:05] <aslak> tdiesler, the configuration you where fiddeling with in arq.xml is configuration for the ContainerMethodExecutor
[09:01:08] <tdiesler> aslak, any other idea about http://fpaste.org/8QAv/
[09:02:01] <tdiesler> aslak, I'm talking about a failure in as7 when the first test request comes in. the arq-service is deployed and the JMXTestRunner registered
[09:02:53] <aslak> tdiesler, i think your reading to much of the client side config.. 2 sec
[09:03:36] <tdiesler> aslak, It seems that the JUnitTestRunner cannot get initialized properly. Here is the full trace http://fpaste.org/icZ3/
[09:04:01] <aslak> tdiesler, yea
[09:04:08] <aslak> tdiesler, your loading client side configuraiton incontainer
[09:04:36] <tdiesler> aslak, ok. why would that be?
[09:04:53] <aslak> tdiesler, you need the same as we added t othe OSGi bundle, the  ArquillianBundleExtensionLoader
[09:06:08] <aslak> basically because Arquillian dynamically configures it self for the incontainer side, all the 'jars' you find in maven are pre configured for client, then when run, will create a new set that is the incontainer config
[09:06:24] <aslak> when you bundle them up in the subsystem/osgi bundle, the original jars still have the client side config
[09:06:26] <tdiesler> aslak, yes. I was thinking in that direction as well - lets see
[09:08:19] <tdiesler> aslak, in AS we only have the original jars. Perhaps it can get fixed by not exporting the original META-INF/services
[09:09:11] *** nickarls has joined #jbosstesting
[09:09:27] <aslak> tdiesler, you only have the original jars in the osgi bundle as well, the 'fix' ther eis to override the ExtensionLoad on what to find
[09:09:50] <aslak> so it won't look for META-INF/services but 'something else
[09:10:03] *** nilian has joined #jbosstesting
[09:10:15] <aslak> tdiesler, had this been generated dynamically, the only set you would see is the correct incontianer one
[09:10:55] <tdiesler> aslak, its statically defined here http://fpaste.org/maSA/
[09:11:23] <tdiesler> aslak, the on-demand arq service deployment has a (single) dependency on this module
[09:12:30] <aslak> tdiesler, this is as7 subsystem module config, or part of the deployment ?
[09:13:10] <tdiesler> aslak, the deployment defines a dependency on this module
[09:14:53] <aslak> tdiesler, 'the deployment' == arq on-demand service or user deployment?
[09:14:54] <tdiesler> aslak, aslak, in turn this module has these depedencies http://fpaste.org/7ypZ/
[09:15:02] <tdiesler> aslak, yes
[09:15:17] <tdiesler> aslak, lets call it "arq service"
[09:16:22] <aslak> so you deploy the arq service (on demand from the container.start), into a hardcoded module def ?
[09:16:24] <tdiesler> aslak, sorry about the confusion. the arq service has a depedency on org.jboss.as.arquillian.service
[09:17:02] <tdiesler> aslak, I deploy the arq service on demand, which has a single dependency on org.jboss.as.arquillian.service
[09:17:36] <aslak> what is arquillian.service ? jsut a module definition?
[09:17:49] <tdiesler> aslak, ultimately org.jboss.as.arquillian.service would go away and the dependencies would be defined in the arq service directly
[09:18:30] <tdiesler> yes, org.jboss.as.arquillian.service is just a module dependecy definition without a local loader content
[09:18:37] *** davidbos has joined #jbosstesting
[09:19:21] <tdiesler> its a cheet that allows me to not have to rebuild the arq service every time I fiddle with its depedencies
[09:19:59] <tdiesler> it'd be a pain to read in the manifest def that is in the pom
[09:20:48] <tdiesler> int pom of the arq service I simply do this http://fpaste.org/OxTd/
[09:22:38] <tdiesler> anyway, the arq service contains the JMXTestRunner which cannot initializze the JUnitTestRunner because you say it is seeing some arq client side configuration
[09:22:53] *** lfryc has joined #jbosstesting
[09:23:02] <tdiesler> this is likely to come from here http://fpaste.org/maSA/
[09:23:30] <tdiesler> perhaps I'm pulling in more arq core stuff than I should
[09:26:37] <aslak> tdiesler, does the user deployment ahve a module dep on arq.ervice+
[09:26:41] <aslak> arq.service?
[09:28:20] <aslak> tdiesler, what's your branch btw?
[09:29:42] *** adinn has left #jbosstesting
[09:31:25] <tdiesler> https://github.com/tdiesler/jboss-as/tree/as734
[09:32:59] <tdiesler> no, the test deployment has a dependency on these http://fpaste.org/rWW6/
[09:33:44] <aslak> test deployment == user deployment
[09:35:37] *** jharting1 has joined #jbosstesting
[09:36:15] *** jharting has joined #jbosstesting
[09:36:28] <tdiesler> aslak, yes. the one from @Deployment
[09:36:40] *** jharting1 has quit IRC
[09:37:21] <tdiesler> aslak, let me build the dependencioes from ground up again. I feel there is lots of redundant/incorrect stuff in there right now
[09:38:16] <aslak> tdiesler, well, it's not that the arq.service is including to much.. it's  just exposing the 'client' side
[09:42:10] *** galderz has joined #jbosstesting
[09:42:26] <tdiesler> aslak, from arq.core ?
[09:42:54] *** ALR has quit IRC
[09:43:35] *** aslak has quit IRC
[09:44:05] *** aslak has joined #jbosstesting
[09:44:31] <aslak> tdiesler, the client side config is 'hardcoded' in the jars, the incontainer side is dynamically generated on the fly
[09:45:04] *** jharting has quit IRC
[09:45:14] <aslak> tdiesler, if you your not using the output of the dynamic generateion, e.g. all the AuxilliaryArchives you are passed to the DeploymentPackager, then you'll need to add a ExtensionLoader in the service like we do in osgi
[09:47:34] <aslak> tdiesler, which arq set is active in your branch? arq or arq2 ?
[09:47:42] <tdiesler> arq
[09:48:29] <aslak> brb, getting some food..
[09:49:15] *** jeand has joined #jbosstesting
[09:50:24] <tdiesler> aslak, I rebased the branch and removed some unwanted depedencies
[10:05:48] *** nilian has quit IRC
[10:08:32] *** alesj has joined #jbosstesting
[10:26:40] *** davidbos1 has joined #jbosstesting
[10:29:11] *** davidbos has quit IRC
[10:51:30] *** johnament has quit IRC
[10:51:58] *** maschmid is now known as maschmid_afk
[10:55:38] <aslak> tdiesler, ok
[10:57:16] <tdiesler> aslak, I added an ExtensionLoader, which however does not get used. Do I need to do anything other than add a meta-inf service for it?
[10:58:22] <aslak> yea
[10:58:28] <aslak> no other then.. no
[10:58:55] <aslak> tdiesler, using the right cl?
[11:02:26] <tdiesler> aslak, the tesst runner gets loaded - runner.execute fails http://fpaste.org/GmwB/
[11:03:19] <tdiesler> aslak, the junit testrunner gets loaded with the same cl that containes the meta-inf service for ExtLoader
[11:03:49] <aslak> tdiesler, what are you running to test it?
[11:04:46] <tdiesler> aslak, I start an as7 instance in a seperate shell. then run 'mvn install' from the arquillian module. You'd need the stuff in my local workspace
[11:05:44] <aslak> tdiesler, so we got remote working?
[11:06:49] <tdiesler> aslak, try https://github.com/tdiesler/jboss-as/tree/arqwip
[11:07:09] <tdiesler> yes, the managed container also uses the remote jmx connection
[11:07:37] <tdiesler> aslak, because there would be two MBeanServers in two different VMs
[11:08:36] <tdiesler> aslak, its a side effect of the managed container that it also works with a remote instance. I use this for easy server side debugging, which is currently not possible with the manged container
[11:09:06] <aslak> right
[11:09:25] <tdiesler> aslak, where could I set a breakpoint to verify that my ExtLoader gets used?
[11:10:25] <aslak> LoadableExtensionLoader line 115
[11:13:48] <tdiesler> aslak, this is broken because it uses the CL from the arq core module Collection<ExtensionLoader> loaders = serviceLoader.all(LoadableExtensionLoader.class.getClassLoader(), ExtensionLoader.class);
[11:14:47] <aslak> tdiesler, yea, where do you have the service ?
[11:15:20] <tdiesler> aslak, in the arq.service
[11:15:29] <aslak> where is LoadableExtensionLoader ?
[11:15:39] <tdiesler> arq.core
[11:16:11] <tdiesler> should this not use the CL of test runner that is calling this?
[11:17:18] <tdiesler> i.e. the target container has a module that sets up the server side test runner. the CL for this TR should be used to load the server side services
[11:17:33] <aslak> what do you do in osgi?
[11:17:44] <aslak> isn't the testrunner part of the serviceP?
[11:18:47] <tdiesler> in osgi we stuff arq.core in the arq.bundle that also contains the jmxtestrunner
[11:19:05] <tdiesler> the code above works because it is the same CL
[11:19:12] *** johnament has joined #jbosstesting
[11:19:18] <tdiesler> in case of the arq-bundle
[11:19:35] <aslak> why is arq.service != arq.bundle ?
[11:20:27] <tdiesler> perhaps runner should be initialized with a CL before runner.execute(...) is called
[11:20:56] <tdiesler> in fact I'd like to see this failure earlier (i.e. when the arq.service is started)
[11:21:40] <tdiesler> conceptually the jmxtestrunner should only be available when it is fully initialized (i.e. eager init not on first test request)
[11:22:08] *** nilian has joined #jbosstesting
[11:22:09] <tdiesler> arq.service is not an osgi deployment
[11:23:02] <tdiesler> otherwise all test deployments would have to go through the osgi layer and be subject to super strict package import/export rules
[11:23:06] <aslak> tdiesler, there is no init, the request is init. that's a full init and shutdown
[11:23:30] <aslak> tdiesler, that i know.. but i mean, why is arq.service conceptually different from how the osgi bundle work
[11:23:45] <aslak> the arq osgi bundle that is
[11:25:03] <tdiesler> because the arq.service has a module dependency on arq.core. In the code you see above you use the CL from arq.core. This is turn does not container the ExtLoader def
[11:25:31] <tdiesler> this is the issue: LoadableExtensionLoader.class.getClassLoader()
[11:25:54] *** alesj has quit IRC
[11:26:04] <tdiesler> this CL cannot load the ExtLoader from arq.service
[11:26:11] <aslak> that's not what i'm asking
[11:26:15] *** alesj has joined #jbosstesting
[11:26:56] <aslak> why does arq.core and arq.service exist as two separate modules in msc, and one in osgi
[11:27:55] <tdiesler> module reuse
[11:28:35] <tdiesler> if you put all arq.core jars in arq.service you cannot have other modules that depend on arq.core stuff
[11:28:50] <aslak> why?
[11:28:57] <aslak> wouldn't they just depend on arq.service instead?
[11:29:12] <aslak> arq.service is arq.core stuff
[11:29:55] <tdiesler> we have as7 specific testenrichers that have depedencies on arq.core
[11:30:34] <tdiesler> anyway, I don't think that putting everything in one module to force a single CL is the right way to go
[11:31:14] <tdiesler> instead I suggest to think about an init strategy that is explicit about its service loader
[11:32:04] <tdiesler> i.e. when the arq.service is started it should have done the init of the test runner
[11:34:23] *** mgoldmann has joined #jbosstesting
[11:36:22] <aslak> tdiesler, which remote as7 container are you using?
[11:36:37] <aslak> the one in arq(1) is from pre Beta1
[11:37:38] <tdiesler> aslak, all testsuites should use the managed container for now
[11:38:05] <tdiesler> embedded and remote have not been migrated - in fact they are excluded from the build
[11:39:28] <aslak> tdiesler, didn't you just say you were using remote?
[11:40:11] <tdiesler> I said I start a remote as7 instance and use the managed container to explore a side effect of easy sever debugging ;-0)
[11:42:00] <tdiesler> you can do this to get the same result http://fpaste.org/NgZb/
[11:42:31] <tdiesler> but you cannot currently debug easily the server with the managed container
[11:44:24] <aslak> got it running
[11:46:16] <tdiesler> aslak, I could try to put core-impl-base in arq.service
[11:46:32] <tdiesler> other stuff should not have a dep on that guy anyway
[11:47:05] <aslak> java.lang.NoClassDefFoundError: org/jboss/as/arquillian/service/ArquillianDeploymentProcessor$DeploymentTrackerService ?
[11:47:44] <aslak> when inside ArquillianDeploymentProcessor
[11:47:47] <aslak> hehe
[11:59:34] *** Jaikiran has joined #jbosstesting
[12:02:01] <tdiesler> aslak, shall we step back a little and decide on a strategy on how to fix this properly?
[12:06:16] *** jharting has joined #jbosstesting
[12:08:50] <aslak> tdiesler, sure..
[12:09:20] <aslak> tdiesler, can module deploy module defs on the fly, or do they need to exists in the servers module registry?
[12:11:04] <tdiesler> any deployment is a "module def on the fly"
[12:12:15] <aslak> ok
[12:13:08] *** maschmid_afk is now known as maschmid
[12:13:10] <aslak> so why don't we do the following:
[12:13:17] <tdiesler> to work arround that LoadableExtensionLoader issue I could try to extract the ArqExtLoader from arq.service and put it alongside the other arq.core jars
[12:14:10] <tdiesler> we've got one ;-)
[12:16:04] <aslak> the ArqService should then contain all the enrichers etc that the user has defined on the classpath, and it should contain the incontainer v. of the arq configuration
[12:17:09] <aslak> we then have a @Observer registered with the jmx-as7 protocol that listens to BeforeDeploy, checks if there is a AsService something in the context, if it is, then deploy it to the contianer.. and listen to AfterSuite to undeploy it
[12:17:41] <aslak> the ArqService starts the JMX Endpoint that it uses for later to invoke the test
[12:17:57] <tdiesler> why is it a benefit to have two arq infrastructure deployments
[12:18:15] <aslak> tdiesler, because it's not hardcoded
[12:18:32] <aslak> and it's only deployed if the jmx-as7 protocol is used
[12:18:47] <aslak> and obviously the two module infrastruct is not working.. ;)
[12:19:29] <tdiesler> btw, the archive callback only works with the jmx protocol, right?
[12:19:35] <aslak> no
[12:20:40] <aslak> other good reasons.. it's self contained to arq, not included / configured in AS. and contained to the AS7 test suite that needs it
[12:22:54] <aslak> tdiesler, https://github.com/arquillian/arquillian-core/blob/master/protocols/servlet/src/test/java/org/jboss/arquillian/protocol/servlet/ServletCommandServiceTestCase.java
[12:28:00] <tdiesler> aslak, the arq service is currently deployed on server start. It is a hard coded thing, but nevertheless it is a deployment. If I understand correctly, you want this infrastructure bit to be deployed as part of the protocol (i.e. deploy/undeploy with every test). The latter is IMHO just a variation of the former and we can go there if it gernally works that the arq server side bits come from a deployment
[12:29:00] *** nilian has quit IRC
[12:29:39] <tdiesler> aslak, I was suggeesting that the arq.service is fully functional when it started
[12:30:10] <tdiesler> aslak, this requirement would be no different if it was deployed as part of the testrun
[12:31:32] <tdiesler> aslak, I think what remains is to get the dependencies sorted out correctly. whether the arq.service is packaged at as build time and deployed at as7 start or the arq.service is packaged dynaimically and deployed before the test is secondary
[12:33:04] <aslak> tdiesler, there is a major difference which you are ignoring
[12:33:35] <aslak> tdiesler, arq was built to be dynamic, not hardcoded
[12:33:44] <aslak> tdiesler, the client side is creating the server side
[12:34:12] <aslak> tdiesler, and no, i'm not suggesting to deploy it pr test
[12:34:51] <aslak> and fully funtional to do what? dynamically configure it self.. ?
[12:35:08] <aslak> arq has no long living runtime on the server side.. it's pr test
[12:35:23] <aslak> the only startup is the end point
[12:36:25] <tdiesler> aslak, ok if you take me by the hand a little I could try to do what you suggest
[12:36:44] <aslak> gladly
[12:37:45] <tdiesler> have a look at JBossASDeploymentPackager
[12:38:08] <tdiesler> this guy currently ignores         excludedAuxillaryArchives.add("arquillian-core.jar");
[12:38:08] <tdiesler>         excludedAuxillaryArchives.add("arquillian-junit.jar");
[12:38:44] <aslak> tdiesler, testDeployment.getAuxiliaryArchives() + module def <-- that's your arch service
[12:38:50] <aslak> arc
[12:38:51] <aslak> arq
[12:40:24] <tdiesler> ok, currently they are embedded in the user deployment - they would now need to get deployed before the user deployment, right?
[12:42:33] <aslak> tdiesler, what do you mean currently?
[12:44:59] <aslak> tdiesler, at the point of DeploymentPackager, they are separate, you have the ApplicationArchive(@deployment) and all the others.. it's up to the Protocol to build a archive in a way that it can communicate with it
[12:45:29] <aslak> tdiesler, in the other cases, e.g. servlet.. it can change the deployment by adding a War etc.. in your case, you create two different archives,
[12:46:27] <aslak> one which is the ArqService that you plan to deploy (but somewhere else, just have to bind it to the context) and the just add a little to ArqService dep to the applicationArchive
[12:51:33] <tdiesler> aslak, DeploymentPackager.generateDeployment(...) returns one archive, this would be the @Deployment one with the added depedency on the arq.service deployment, right?
[12:51:43] <aslak> yea
[12:52:21] <aslak> tdiesler, baiscally just testDeployment.getApplicationArchive() with a little Manifest.mf manipulation
[12:52:37] <tdiesler> ok, when DeploymentPackager generates the arq.service as well what does it do with it? How can I get that deployed before the user deployment
[12:53:06] <tdiesler> aslak, yes. the deployemnt of the arq.service is what I am not clear about
[12:53:14] <aslak> tdiesler, right..
[12:53:36] <aslak> tdiesler, create a little holder object.. ArqService.getArchive or something
[12:53:47] <aslak> just to have a Type to bind it to
[12:54:14] <tdiesler> and use the normal injection thing?
[12:54:49] <aslak> DeploymentPackager itself it not injected, but Protocol is, so you can do in Protocol, @Inject @ContainerScoped InstancePtroducer<ArqServiceHolder> inst; and pass tha tObject down to DeploymentPackager
[12:55:51] <aslak> generateDeployment is called pr TestClass, so DeploymentPackager can check ebfore starting to create the ArqService, inst.get() != null, if null create and do inst.set(service)
[12:56:18] <tdiesler> ok
[12:56:59] <tdiesler> and in the container.deploy I can pick it up and deploy the arq.service
[12:57:00] <aslak> tdiesler, then create a Observer that can deploy it and register it in JBossASProtocolExtension
[12:57:11] <aslak> builder.observer(ArquillianServiceDeployer.class)
[12:57:56] <aslak> ArquillianServiceDeployer should have a method, public void doServiceDeploy(@Observes BeforeDeploy event) {  }
[12:58:28] <aslak> in the ArqServiceDeployer, @Inject Instance<ArqServiceHolder> and @Inject Instance<Container>
[12:58:41] <aslak> and it could hvae some bool to know if it has deployed it or not already..
[12:59:21] <aslak> but basically, if ArqServiceHolder != null && !hasBeenDeployed container.get().getDeployableContainer().deploy(arqServiceHolder.get())
[13:00:16] <aslak> and another method, public void undeploy(@Observes BeforeStop event) {} and undeploy it
[13:01:14] <tdiesler> ok, I'll try that
[13:06:35] *** ldimaggi has joined #jbosstesting
[13:13:48] *** nilian has joined #jbosstesting
[13:14:54] *** aslak has quit IRC
[13:15:38] *** aslak has joined #jbosstesting
[13:17:07] *** johnament has quit IRC
[13:51:59] <tdiesler> aslak, where would I produce the holder instance? http://fpaste.org/6mnS/
[13:52:49] <tdiesler> aslak, Protocol.getPackager too early? If so, how do I pass the holder to the packager?
[13:55:22] <aslak> tdiesler, aa, sorry.. your outside the container scope at package time.. make it @SuiteScoped instead
[13:56:54] <aslak> tdiesler, but why / what are you setting in getPackager)=
[13:56:55] <aslak> ()
[13:59:57] <tdiesler> the holder instance
[14:00:59] <tdiesler> aslak, alternatively I could inject the protocol into the ArqServiceDeployer, right?
[14:01:06] <aslak> no
[14:01:29] <tdiesler> ok, so @SuiteScoped instead
[14:02:25] <aslak> you could pass the Instance<Holder> to Packager, but that's same same i guess, still needs to be SuiteScoped
[14:03:28] <aslak> tdiesler, you should be able to, in ArquillianServiceDeployer.. instead of checking if Instance<Holder> is set, you can do, public void deploy(@Observes BeforeDeploy event, Holder holder).. it will then only call deploy if Holder is set
[14:04:19] <aslak> same with undeplot of course
[14:04:23] <aslak> undeploy
[14:09:59] <aslak> brb
[14:18:25] *** pgmjsd has joined #jbosstesting
[14:24:50] *** maeste has joined #jbosstesting
[14:35:59] *** pgmjsd has quit IRC
[14:39:31] *** pgmjsd has joined #jbosstesting
[14:45:48] <aslak> b
[14:46:38] *** burrsutter_ has joined #jbosstesting
[15:01:35] <aslak> tdiesler, hows it going?
[15:02:06] <jbossbot> git [arquillian-core] push master 44cbb95.. Aslak Knutsen ARQ-49 Rewrite to use archive.getAsType for nested Archives, removes the compile time dep on shrinkwrap-impl
[15:02:07] <jbossbot> jira [ARQ-49] Arquillian depends upon ShrinkWrap internals [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/ARQ-49
[15:02:07] <jbossbot> git [arquillian-core] push master URL: http://github.com/arquillian/arquillian-core/compare/7492392...44cbb95
[15:03:29] *** vtunka has quit IRC
[15:15:31] <tdiesler> aslak, I got the arq.service deployed
[15:16:21] <tdiesler> aslak, deploying. It defines a dependency on arq.protocol.jmx, which in turn dependens on some arq.core stuff
[15:16:45] <aslak> tdiesler, ?
[15:16:52] <aslak> arq.protocol.jmx is arq.service
[15:16:53] <tdiesler> aslak, I was seeing a linkage error due to some class being loaded twice from differnt cls
[15:17:29] *** vtunka has joined #jbosstesting
[15:17:30] <tdiesler> the arq.service has a dependency on arq.core jmx
[15:17:47] <tdiesler> remember jmx that lives with arq.core
[15:18:02] <aslak> why?
[15:18:27] <aslak> arq.service contains arq.core and jmx, arq.service expose the jmx.endpoint
[15:19:53] <tdiesler> let me check what it contains ...
[15:26:46] <tdiesler> aslak, jmx is not in there http://fpaste.org/CwbV/
[15:27:43] <tdiesler> aslak, should this be in the generated arq-core or another aux archive?
[15:31:07] <aslak> it won't contain the jmx part, since that is you in this case. it's the jmx-as7 reposinsibillity to add that part
[15:32:38] <tdiesler> aslak, so I need to fetch this from the mvn repo and embed it as well
[15:33:22] <aslak> tdiesler, no, add it by package or similar to the archive directly
[15:33:41] <tdiesler> ok
[15:41:05] <tdiesler> aslak, if the test fails the arq.deployment is not undeployed
[15:41:15] <tdiesler> the arq.service
[15:42:00] <aslak> it's not the test failing that's the problem..
[15:42:49] <aslak> tdiesler, it's probablt related to this: ARQ-282
[15:42:50] <jbossbot> jira [ARQ-282] DeployableContainer.stop(Context) never called [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/ARQ-282
[15:42:56] <aslak> tdiesler, see the comment
[15:47:29] *** rachmatowicz_ has joined #jbosstesting
[15:49:59] <tdiesler> aslak, how would I add another testenricher? adding a dependency to the pom that runs the test is not it, is it?
[15:51:27] <aslak> it is.. some what. a TestEnricher should be self contained
[15:52:58] <aslak> tdiesler, to it will in most cases contain 2 LoadableExtension impls, one that is activated on client side (and possible enrich when ran on client side if supported). it will also register a AuxilliaryArchiveAppender Service that can package it self up as a AuxilliaryArchive and be reexecuted with a 'Remote' LoadableExtension
[15:53:31] <aslak> e.g. https://github.com/arquillian/arquillian-core/tree/master/testenrichers/ejb/src/main/java/org/jboss/arquillian/testenricher/ejb
[16:01:33] *** rbattenfeld1 has joined #jbosstesting
[16:01:44] *** davidbos1 has quit IRC
[16:01:47] <aslak> rbattenfeld1, heya!
[16:01:59] <aslak> there.. made it.. :)
[16:02:16] <rbattenfeld1> hi aslak, congratulation!
[16:02:16] <aslak> rbattenfeld1, you normally pop in and out so far i never managed to reply before your gone again..  heh
[16:02:22] <aslak> far/fast
[16:02:50] <rbattenfeld1> yes, I have some times problem with my connection:-(
[16:03:33] <rbattenfeld1> So, arquillian is in final state?
[16:04:16] <aslak> rbattenfeld1, api/spi locked yea..
[16:04:46] <aslak> rbattenfeld1, tho i have a major issue with Embedded containers, e.g. GlassFish Embedded which i'm not quite sure how to fix without change..
[16:05:20] <aslak> ARQ-456
[16:05:21] <jbossbot> jira [ARQ-456] Client side SPIs are found InContainer when running Embedded [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/ARQ-456
[16:06:12] <rbattenfeld1> I made good progress with the descriptors
[16:06:18] <tdiesler> aslak, so what do we do about the arq.service not getting undeployed?
[16:06:49] <aslak> tdiesler, did you try setting parallel in surefire?
[16:07:38] <aslak> <parallel>none</parallel>
[16:09:47] *** vtunka has quit IRC
[16:09:48] <aslak> rbattenfeld1, yea? I saw some updates  on the forum about trying to standarize the convenience apis
[16:10:01] <tdiesler> aslak, now the arq.service deploys and runs the test - I get http://fpaste.org/kEqJ/
[16:10:39] <aslak> tdiesler, and your including all auxiliary archives?
[16:10:54] <aslak> tdiesler, and all LoadableExtensions are found?
[16:11:21] <aslak> tdiesler, it's not getting a TestResult back, meaning there is no TestExecutor there
[16:11:52] <aslak> tdiesler, which should be the LocalTestExecuter registered in ContainerTestRemoteExtension
[16:11:53] <tdiesler> aslak, yes no parallel does hte trick: Stopped deployment arquillian-service in 15ms
[16:12:07] <aslak> tdiesler, great.. atleast we have a work around
[16:12:43] *** rbattenfeld1 has quit IRC
[16:12:44] <aslak> see what the surefire guys says, http://jira.codehaus.org/browse/SUREFIRE-743
[16:12:45] <jbossbot> jira [SUREFIRE-743] JUnit 4.x provider never calls notifier.testRunFinished [Open (Unresolved) Bug, Major, Unassigned] http://jira.codehaus.org/browse/SUREFIRE-743
[16:14:45] *** rbattenfeld1 has joined #jbosstesting
[16:15:35] *** oskutka has quit IRC
[16:16:14] <aslak> rbattenfeld1, do you have impl generation down now?
[16:19:02] <rbattenfeld1> no, I focused on the API generation but the impl should be straight forward, e.g. as well generated
[16:19:15] <aslak> cool
[16:19:47] *** galderz has quit IRC
[16:20:04] *** burrsutter_ has quit IRC
[16:20:13] <tdiesler> aslak, the arq.service has metainf/services/LoadableExtension, which contains org.jboss.arquillian.testenricher.cdi.container.CDIEnricherRemoteExtension. Thats not right, is it?
[16:21:18] <tdiesler> aslak, content is here http://fpaste.org/Hpod/
[16:21:20] <aslak> tdiesler, you merge them all ?
[16:21:47] <aslak> aa.. the LoadableExtension definitions will overwrite each other
[16:22:02] *** galderz has joined #jbosstesting
[16:22:21] <tdiesler> yes, I merge them all: http://fpaste.org/1zvp/
[16:22:45] <aslak> tdiesler, any support for /lib in those service jars?
[16:22:49] <tdiesler> aslak, that would be a common problem
[16:23:37] <tdiesler> aslak, no. next best would be to deploy them individually
[16:23:51] *** vtunka has joined #jbosstesting
[16:24:23] <tdiesler> aslak, or somehow merge the content of those loadable extensions
[16:24:48] *** rruss has joined #jbosstesting
[16:25:14] <aslak> tdiesler, yea.. i think merge the content in the first round..
[16:26:16] <aslak> tdiesler, you can create a little Inner Asset class that reads the content other the other AuxiliaryArchives and pass it as it's own stream
[16:26:25] <aslak> of the other
[16:29:32] <aslak> could be a feature of UberJarArchive do to it automagically
[16:29:42] *** rbattenfeld1 has quit IRC
[16:30:12] <aslak> or is it the Shard plugin that does that..
[16:35:15] *** jharting has quit IRC
[16:35:30] *** tdiesler has left #jbosstesting
[16:37:29] *** jlocker has joined #jbosstesting
[16:38:21] *** tdiesler has joined #jbosstesting
[16:40:27] *** rachmatowicz has quit IRC
[16:40:45] *** rachmatowicz_ has quit IRC
[16:41:03] *** rachmatowicz has joined #jbosstesting
[16:47:26] *** rbattenfeld has joined #jbosstesting
[16:50:51] <rbattenfeld> Aslak: I had to leave. I just wanted mention that in the impl test folder a simple unit test exists showing the navigation
[16:51:30] <aslak> rbattenfeld, yea, i see it.. :)
[16:52:07] <aslak> rbattenfeld, non of the convenience stuff is in yet right?
[16:52:41] <rbattenfeld> Yes, correct. This comes in a few days
[16:54:34] <rbattenfeld> The cool thing is, once the api is good, all the other deployment descr are there at the same time. Including different versions
[16:57:10] <rbattenfeld> Aslak: any further comments and wishes are welcome
[16:57:45] <aslak> rbattenfeld, yea, that's the cool part
[16:58:13] <aslak> rachmatowicz, i've got to reread the forum posts and look it over again.. :)
[17:00:09] <aslak> yea, those where both intended for rbattenfeld .. :)
[17:01:49] <rbattenfeld> Aslak: is there someting on the forum?
[17:02:34] <aslak> rbattenfeld, just the initial discussion
[17:05:25] <tdiesler> aslak, better. now I get an assertion error in your IntegrationTestCase. How is this injection supposed to work?
[17:07:28] <tdiesler> aslak, almost there http://fpaste.org/IR7c/
[17:07:39] <rbattenfeld> Aslak: have a nice evening and a nice free day tomorrow
[17:08:01] <aslak> tdiesler, where is that test  =?
[17:08:04] *** rbattenfeld has left #jbosstesting
[17:09:01] <aslak> tdiesler, can't see it in your branch
[17:09:23] *** burrsutter_ has joined #jbosstesting
[17:09:25] <aslak> https://github.com/tdiesler/jboss-as/tree/as734/arquillian/container-managed/src/test/java/org/jboss/as/arquillian/container/managed ?
[17:10:00] *** alesj has quit IRC
[17:10:55] *** alesj has joined #jbosstesting
[17:11:40] <tdiesler> aslak, hang on - pushing
[17:13:09] <tdiesler> aslak, pushed
[17:14:39] <aslak> tdiesler, ok.. hmm
[17:14:47] <aslak> tdiesler, well, in the case of CDI
[17:16:04] <aslak> the CDIInjectionEnricher rely on there being a BeanManager in Arq Context somewhere, by default this is provided via BeanManagerProvider
[17:16:46] <aslak> BeanManagerProvider rely on there being a (Initial)Context in the ArqContext, which is normally provided by testenricher-initialcontext
[17:17:31] <aslak> from incontianer, that just does new InitialContext
[17:17:45] <aslak> but coming from the service, i assume that won't be correct
[17:18:36] <tdiesler> aslak, perhaps it should use the cdi enricher that lives in AS7
[17:19:32] <aslak> tdiesler, as6 had a unified injection manager, does that still exist in some fork in as7?
[17:19:40] <aslak> fork/form
[17:21:44] *** kpiwko has quit IRC
[17:22:34] <aslak> tdiesler, in the old arq subsystem.. wasn't there a special beanmanager lookup somewhere ? or do i remmeber wrong?
[17:23:33] *** maschmid has quit IRC
[17:23:44] <tdiesler> aslak, maybe ALR knows. This test used to work on arq2 managed
[17:24:15] <tdiesler> aslak, I'll ignore it for now
[17:24:19] <aslak> tdiesler, arq2 managed use the Servlet Protocol
[17:24:30] <aslak> i think
[17:34:31] <tdiesler> aslak, yes
[17:35:21] <tdiesler> aslak, I'll call it a day. https://github.com/tdiesler/jboss-as/commit/c7c7a2b65c5c7bed9fcfacf1f5c764d57290ee85
[17:35:22] <jbossbot> git [jboss-as] c7c7a2b.. Thomas Diesler [AS7-734] Arquillian Managed Container pass. Next: migrate smoke and integration tests
[17:35:23] <jbossbot> jira [AS7-734] Consolidate Arquillian test infrastructure [Open (Unresolved) Task, Blocker, Thomas Diesler] https://issues.jboss.org/browse/AS7-734
[17:35:34] <tdiesler> thanks for your help
[17:36:11] <aslak> tdiesler, you got it running?
[17:36:14] *** nilian has quit IRC
[17:36:57] <tdiesler> aslak, well yes but cdi is not there yet
[17:37:21] <aslak> tdiesler, right.. i'm compiling etc now.. seeing if i can figure out the cdi part
[17:37:27] <tdiesler> aslak, the other tests in managed pass
[17:37:44] <aslak> tdiesler, yea, but they don't do any enrichment.. :)
[17:38:33] <tdiesler> aslak, I'll tkae a stab at migrating the smoke tests tomorrow. Then we will see this enrich issue again.
[17:38:47] <tdiesler> BTW, do you have a bank holiday tomorrow?
[17:39:22] <aslak> tdiesler, officially yea.. :) but i'll be around
[17:39:37] <tdiesler> aslak, same here ;-)
[17:39:50] *** tdiesler has left #jbosstesting
[17:40:27] *** tdiesler has joined #jbosstesting
[17:40:47] <tdiesler> aslak, cheers & ttyt
[17:40:56] *** tdiesler has left #jbosstesting
[17:40:58] <aslak> tdiesler, l8r
[17:41:03] <aslak> .. too slow..
[17:48:23] *** burrsutter_ has quit IRC
[17:57:02] *** ge0ffrey has quit IRC
[17:57:37] *** maeste has quit IRC
[18:25:00] *** jharting has joined #jbosstesting
[18:30:38] *** pgmjsd has quit IRC
[18:30:53] <aslak> stuartdouglas, ping
[18:40:08] *** jlocker has quit IRC
[18:46:32] *** ldimaggi has quit IRC
[18:52:08] *** tdiesler has joined #jbosstesting
[18:52:45] <aslak> tdiesler, welcome back.. :)
[18:53:09] <tdiesler> aslak, quickly wnated to look at smth. after a clean build. surefire does not pick up any test any more. have you seen this?
[18:53:36] <aslak> tdiesler, which surefire v. is in use?
[18:54:16] <tdiesler> 2.5
[18:54:50] <aslak> tdiesler, there was a bug in 2.6 or 2.5, don't remember correctly, but if the Junit47Provider(the one you force with parallel=none) failed in beforeClass(e.g. deployment) it would faulsly fail internally and unregister it's own listener, and end up reporting no tests ran
[18:56:26] <aslak> SUREFIRE-629
[18:56:26] <jbossbot> jira [SUREFIRE-629] NullPointerException in DemultiplexingRunListener, falsely report of "No tests were executed!" [Closed (Fixed) Bug, Critical, Kristian Rosenvold] http://jira.codehaus.org/browse/SUREFIRE-629
[18:56:40] <aslak> fixed in 2.6
[18:58:38] <aslak> tdiesler, there is a bug in the ArqService somewhere.. it doesn't cleanlu undeploy
[18:59:29] <aslak> tdiesler, https://gist.github.com/1002764
[19:00:01] <aslak> tdiesler, that is from the second run on the same server. multiple Processors seems to be active, one of them probably pointing to some non existing service
[19:07:51] <aslak> i guess it's the Listener that is not removed during stop
[19:10:39] *** ALR has joined #jbosstesting
[19:19:45] <aslak> ALR, good morning!
[19:19:53] <ALR> aslak: Morning?! :)
[19:20:12] <ALR> (Lately I've been holding off on IRC until I get my day well under way...too distracting otherwise)
[19:20:29] <ALR> So what's up?
[19:20:32] <aslak> ALR, it's always morning the first time you see someone.. :)
[19:20:35] <ALR> Haha
[19:24:41] <tdiesler> from a radio interview: Q: So when do you get up every day, Mr. Hendrix
[19:24:41] <tdiesler> A: Well, I do get up every day.
[19:26:18] *** jlocker has joined #jbosstesting
[19:26:26] * ALR finding a USB cable to fit his mouse, brb
[19:26:32] <ALR> Needs charging
[19:27:23] *** galderz has quit IRC
[19:29:44] <aslak> tdiesler, did a surefire v. upgrade change anything ?
[19:33:59] *** jharting has quit IRC
[19:39:23] *** galderz has joined #jbosstesting
[19:40:11] <aslak> tdiesler, ContextManager + Builder is not called from what I can see in the new ArqService
[19:40:33] <aslak> tdiesler, it calls all the SetupActions etc, which Weld has one of that does 'something'
[19:40:39] *** Jaikiran has quit IRC
[19:44:14] *** burrsutter_ has joined #jbosstesting
[19:45:56] <tdiesler> aslak, surefire 2.6 is not available
[19:46:23] <aslak> tdiesler, ?
[19:46:54] <aslak> tdiesler, http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
[19:47:22] *** nilian has joined #jbosstesting
[19:47:54] <aslak> dinner..
[19:48:00] <tdiesler> aslak, sorry. take it back must have been a hickup with nexus
[19:54:48] <ALR> tdiesler: Did you force updates to your AS7 branch and rewrite history?
[19:54:57] <ALR> Pulling in your latest comes up with merge conflicts.
[19:55:09] <ALR> (I see a forced update in here)
[19:55:18] <ALR> Maybe due to rebasing w/ AS upstream?
[19:56:17] <tdiesler> ALR, yes its a rebase
[19:57:00] <ALR> Coool.
[19:57:04] <ALR> I had some changes.
[19:57:13] <ALR> They seem superceded by your new stuff though.
[19:57:57] <ALR> Though the AS build is failing in "server" module...hmm..
[20:02:35] *** lfryc has quit IRC
[20:07:31] *** Tashtego has joined #jbosstesting
[20:08:14] <tdiesler> ALR, here is the latest
[20:08:15] *** rruss has quit IRC
[20:08:15] <tdiesler> https://github.com/tdiesler/jboss-as/commit/5bb784a919fae43f22cc8e2a430419e09d1c1fef
[20:08:16] <jbossbot> git [jboss-as] 5bb784a.. Thomas Diesler Use surefire-2.6. Copy jboss target build to respective testsuite target/jbossas
[20:09:11] <ALR> Got it
[20:09:12] <tdiesler> ALR, status is that smoke and integration tests compile and the arq.service is generated by hte AS7 jmx protocol
[20:09:24] *** nilian has quit IRC
[20:09:36] <ALR> tdiesler: Can I go in now and just go through the tests one-by-one, porting and making 'em work?
[20:09:39] *** nilian has joined #jbosstesting
[20:10:40] <tdiesler> ALR, we used to have some ContextManager + Builder stuff in the JMXTestRunner. I removed that, with the effectd that the CDI test (the one that is currently ignored in container-managed) fails
[20:10:56] <ALR> Hmm
[20:11:27] <tdiesler> ALR, also there is a condition that an MSC listener in the arq.service tries to access an invalid service target
[20:11:41] <tdiesler> The effect is that surefire does not report test results
[20:11:56] <ALR> I'll look out for it.
[20:12:01] * ALR building the new stuff now.
[20:12:03] <tdiesler> ALR, ContextManager + Builder can easily be resurected
[20:12:19] <ALR> Sweet
[20:12:31] <ALR> JMXTestRunner now lives  __ ?
[20:12:36] <tdiesler> ALR, its should be a matter of ading stuff to the arq.service
[20:12:46] <ALR> In AS7.
[20:13:00] <tdiesler> arquillian/service is leagcy and not build any more
[20:13:49] <tdiesler> the ArquillianService now lives with protocol-jmx. This guy registers a subclass of the JMXtestRunner
[20:15:53] <ALR> tdiesler aslak: Confirm call tomorrow, same time?
[20:16:36] <tdiesler> ALR, note, I could remove all static arquillian modules from jboss-[version]/modules
[20:17:09] <tdiesler> ALR, tomorrow is a bank holiday in europe - I can promisse yet. Perhaps we can meet on Fri?
[20:17:19] <tdiesler> s/can/can't/
[20:18:59] <tdiesler> have a look at JBossASDeploymentPackager. This is where the arq.service is created
[20:19:49] <ALR> Friday's great here, sure
[20:19:58] <ALR> arq.service.  Cool
[20:21:21] <tdiesler> Perhaps you like to investigate if there is a gurantee that the arq.service is up and the JMXTestRunner MBean registered before the test is deployed. Same for reverse
[20:22:14] <tdiesler> not sure if this is already given by the observer. see ArquillianServiceDeployer
[20:22:22] <ALR> I think Carlo mentioned something similar being a problem before
[20:22:40] <ALR> Where an installed service isn't necessarily started yet
[20:23:03] <tdiesler> anyway, we must make sure that the endpoint is registered properly before we deploy a test
[20:23:51] *** nilian has quit IRC
[20:23:54] <tdiesler> on the client side, the container can look and wait for the mbean
[20:24:02] *** nilian has joined #jbosstesting
[20:24:57] <tdiesler> AbstractDeployableContainer.waitForMBean(...)
[20:27:07] <tdiesler> I guess we need a few more days to resurrect most smoke tests. Integration tests should not be more difficult. Maybe we can be done by end of next week
[20:28:30] *** tdiesler has quit IRC
[20:32:18] <ALR> Super.
[20:32:21] <ALR> Ah he's gone.
[20:32:35] <ALR> (That's what I get for watching Eclipse bring in AS7) :)
[20:34:40] *** Tashtego is now known as Tashtego-afk
[20:52:37] *** alesj has quit IRC
[21:04:44] <ALR> aslak: You know where the old JMXTestRunner stuff that had the ContextManager bits is/was?
[21:04:58] <ALR> I've reproduced the CDI no-injection issue that tdiesler was talking about
[21:08:57] *** nilian has quit IRC
[21:10:00] *** nilian has joined #jbosstesting
[21:10:42] *** Tashtego-afk is now known as Tashtego
[21:10:54] *** lightguard_jp has joined #jbosstesting
[21:11:09] <aslak> ALR, not sure.. looking for it..
[21:12:02] <ALR> Me too
[21:12:32] <aslak> ALR, weld seems to attache it to the DeploymentUnit, so i'm guessing it's in arq service somewhere.. :)
[21:13:27] <ALR> aslak: Well there's this stuff: https://github.com/ALRubinger/jboss-as/tree/master/arquillian/service/src/main/java/org/jboss/arquillian/context
[21:13:48] <aslak> ALR, yea, but it's where that is called from
[21:14:00] <ALR> aslak: Maybe this? https://github.com/ALRubinger/jboss-as/blob/master/arquillian/service/src/main/java/org/jboss/as/arquillian/service/ArchiveDeployerTestEnricher.java
[21:15:21] <aslak> no, that's a enricher for exposing a deployer. replaced wiht stuff from arq-core
[21:15:28] <aslak> @ArquillianResource Deployer
[21:16:11] <ALR> aslak: I think this: https://github.com/ALRubinger/jboss-as/blob/master/arquillian/service/src/main/java/org/jboss/as/arquillian/service/ArquillianService.java#L110
[21:16:13] <aslak> ALR, https://github.com/jbossas/jboss-as/blob/master/arquillian/service/src/main/java/org/jboss/as/arquillian/service/ArquillianService.java
[21:16:17] <aslak> yea
[21:16:24] <ALR> Bingo-ringo.
[21:16:31] <ALR> I'll see if I can't port that nonsense in.
[21:17:49] <aslak> ALR, it's a bit strange tho. because what it does in the Weld case
[21:17:51] <aslak> https://github.com/jbossas/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/arquillian/WeldContextSetup.java
[21:18:24] <aslak> seems to be to only lookup the BeanManager from  InitialContext as what arq default tries, but can't find
[21:18:34] <aslak> maybe there is some other magic some where.. the TCCL stuff or similar
[21:18:46] <ALR> Im guessing this way delegates via AS.
[21:18:50] <ALR> Stuart wrote it
[21:19:05] *** gastaldi has joined #jbosstesting
[21:19:08] <gastaldi> hey
[21:19:13] <gastaldi> ALR: ping
[21:19:29] <ALR> gastaldi: Gi.
[21:19:32] <ALR> *Hi.
[21:20:08] <aslak> ALR, well, it seems to just setup the Scopes to be mapped to a ThreadLocal store
[21:20:09] <gastaldi> hi
[21:20:27] <gastaldi> ALR: I need a Birt Runtime to be available during testing
[21:20:30] <gastaldi> is that possible ?
[21:20:40] <gastaldi> on hudson
[21:20:53] <aslak> ALR, if you see line 69 in the WeldContextSetup, it only fetch it via InitialContext
[21:20:59] <ALR> gastaldi: I don't know much about BIRT at all.  What's the runtime?
[21:21:24] <ALR> aslak: Yeah, seems like a lot of work and registration just to get at a BeanManager
[21:21:42] <gastaldi> Its a zip that has a structure similar to Eclipse
[21:21:58] <gastaldi> A bunch of jars that the OSGI runtime container needs to startup Birt
[21:22:26] <aslak> ALR, well, it's not getting it, it's setting up the contexts so @RequestScoped SessionScoped etc work. they are normally handled and mapped to RequestMap and Session and so on
[21:22:30] <ALR> gastaldi: I'm missing context.  You're using Arquillian?
[21:23:02] <ALR> aslak: The contexts for the test.  Not the deployment itself.
[21:23:58] <aslak> ALR, yes, so Scoped CDI beans work when executed from the Service..  in the Servlet Protocl ew just piggyback on what the ServletContainer have setup already
[21:24:00] <gastaldi> ALR: Yes, I am using Arquillian
[21:24:08] <gastaldi> I talked to lightguard_jp before
[21:25:18] <ALR> gastaldi: What backing container are you using to bridge Arquillian tests to the OSGi/BIRT thing?
[21:25:36] <aslak> ALR, you know if InitialContext use TCCL to 'knwo which component' it operating on?
[21:25:59] <gastaldi> Weld-SE
[21:27:13] <ALR> gastaldi: I'm afraid I'll need you to be more specific.  I'm not familiar with what you need to do to bootstrap BIRT.
[21:27:25] <ALR> Very generally speaking, Arquillian brings up the runtime.
[21:27:37] <ALR> If you don't have the runtime brought up, you need an ARQ connector to do so
[21:27:44] <gastaldi> hum
[21:27:56] <ALR> aslak: JNDI uses TCCL to figure out the ENC.
[21:28:10] <ALR> (Enterprise Naming Context)
[21:28:12] <gastaldi> See if that helps on understanding: http://www.eclipse.org/birt/phoenix/deploy/reportEngineAPI.php
[21:28:29] <gastaldi> My concern is on EngineConfig
[21:28:43] <aslak> ALR, ok, that's why the Lookup in WeldContextSetup work, TCCLSetup is ran before it, which set's the TCCL to the CL from the TestDeployment
[21:28:46] <ALR> gastaldi: Hehe, I think you've got this backwards.
[21:28:52] <ALR> We can explain to you how ARQ is setup
[21:28:58] <ALR> And point you at resources to make a proper container.
[21:29:00] 
[21:29:14] <gastaldi> ok
[21:29:26] <ALR> aslak: If it needs ENC access, yes.
[21:31:37] <aslak> ALR, yea, BeanManager is bou nd to comp:/BeanManager
[21:31:47] <ALR> Thar she blows.
[21:31:51] <ALR> I'm gonna play a bit
[21:31:54] <ALR> See if I can't hook this in.
[21:31:56] <ALR> Thanks
[21:32:09] <ALR> The question I'll next answer is: where to hook it? :)
[21:32:22] <ALR> Now that we've moved JMXTestRunner and the start() cycle
[21:33:11] <aslak> ALR, well, it's not changed.. in the old it creates a anonymous v of it to override runXXX..
[21:33:37] <ALR> Yup.
[21:34:04] <ALR> Basically wrapping in calls to super()
[21:35:02] <ALR> But now we have the arq.service sent along with the deployment..
[21:35:04] <ALR> Finding that
[21:35:54] <ALR> Aha, found it
[21:37:08] <ALR> aslak: Look right to you? https://github.com/tdiesler/jboss-as/blob/as734/arquillian/protocol-jmx/src/main/java/org/jboss/as/arquillian/service/ArquillianService.java#L121
[21:38:22] <ALR> Basically take the same approach as before; override the runTestMethod* stuff of JMXTestRunner in start() of the Service?
[21:38:43] <aslak> ALR, think so
[21:39:17] <aslak> ALR, start there to see if that makes it run.. then we can see if there is a 'proper' approach.. :)
[21:39:38] <ALR> Ha.
[21:39:41] <ALR> Magic!
[21:39:50] * ALR off to hacking again.
[21:40:11] <gastaldi> brb
[21:40:13] *** gastaldi has left #jbosstesting
[21:50:03] *** oskutka has joined #jbosstesting
[22:10:24] *** oskutka has quit IRC
[22:16:29] *** galderz has quit IRC
[22:32:16] *** rruss has joined #jbosstesting
[22:33:44] *** mgoldmann has quit IRC
[22:43:24] *** kenfinnigan has joined #jbosstesting
[22:48:13] *** nilian has quit IRC
[22:49:54] *** kenfinnigan has left #jbosstesting
[22:53:00] <stuartdouglas> aslak: you pinged
[22:53:02] <stuartdouglas> ?
[22:53:22] <aslak> stuartdouglas, i think we figured it out
[22:53:26] <aslak> :)
[22:53:44] <stuartdouglas> cool
[23:01:35] *** jharting1 has joined #jbosstesting
[23:02:15] *** jharting2 has joined #jbosstesting
[23:02:34] *** jharting1 has quit IRC
[23:02:42] *** jharting2 has quit IRC
[23:03:01] *** jharting1 has joined #jbosstesting
[23:13:45] *** jeand has quit IRC
[23:19:40] *** jharting has joined #jbosstesting
[23:20:20] *** burrsutter_ has left #jbosstesting
[23:20:51] <aslak> ALR, the hacking working ?
[23:21:06] *** jharting1 has quit IRC
[23:21:07] <ALR> aslak: Don't know yet
[23:21:13] <ALR> Tests get registered and installed
[23:21:16] <ALR> in getConfig
[23:21:20] <ALR> And they're not there
[23:21:30] <ALR> So I'm missing where the ARQ config is installed under a test class name
[23:21:33] <ALR> Putting that back :)
[23:21:46] <aslak> HMM
[23:21:47] <ALR> Holy shit, I think Boston is under attack.
[23:21:48] <aslak> hmm
[23:21:49] <ALR> Tornado warning
[23:21:51] <ALR> Lightening
[23:21:53] <aslak> cool
[23:34:45] *** rachmatowicz has quit IRC
[23:40:01] <ALR> aslak: Got a green on CDI injection
[23:40:05] <ALR> Let's see what else breaks.
[23:41:15] <ALR> Breaks ManagedInContainerTestCase
[23:41:22] <ALR> Hmm, but not in the IDE.
[23:41:25] <ALR> Doing a full AS run
[23:43:37] <aslak> ALR, goodie
[23:44:37] <ALR> But yeah, looks like CDI working now.
[23:54:42] <ALR> aslak: Still here?
[23:54:49] <ALR> @RunAsClient working fine.
[23:54:57] <ALR> As container, not.  But works OK from the IDE.
[23:55:20] <ALR> Reason: Arquillian Service never registers the test class name
[23:55:31] <ALR> Can you think of why that might be?
[23:56:49] <aslak> but it does from ide?
[23:57:05] <ALR> Yeah.
[23:57:08] <ALR> All green from IDE.
[23:57:10] <ALR> Weird, right?
[23:57:12] <aslak> fresh started as in both cases ?
[23:57:15] <ALR> Yes.
[23:57:36] <aslak> could be something that is missing on cp when in maven that eclipse pulls in.. e.g. test scoped
[23:58:17] <aslak> ALR, or something that is lagging behind in eclipse or the other way around
[23:58:24] <aslak> mvn clean has the same ?
[23:58:45] <ALR> That's a decent point...a missing CP dependency
[23:58:49] <ALR> But not really...
[23:59:00] <ALR> Because in test scope you get most of it when running from Maven





top