[00:09:05] *** ldimaggi has joined #jbosstesting
[00:21:42] *** jeand has quit IRC
[00:23:12] <aslak> lightguard_jp, https://github.com/arquillian/arquillian-testrunner-spock/tree/Alpha3
[00:23:54] <lightguard_jp> aslak: Thanks! We need to test in-container and client, and specify groovy needs to be on the CP?
[00:24:06] <lightguard_jp> Is there a way to test what's available on the classpath?
[00:26:12] <aslak> lightguard_jp, yea, groovy needs to be on cp for client and incontainer. currently the incontainer will bundle up groovyall and deploy it, which will go through deployment scanning etc and take like 15 sec or so pr test
[00:26:28] <aslak> lightguard_jp, adding goorvyall.jar to contianer/lib will probably speed it up a bit
[00:26:35] <lightguard_jp> Yeah
[00:27:21] <aslak> lightguard_jp, available on cp ?
[00:27:57] <lightguard_jp> If there's away to know what's available from maven on the classpath.
[00:28:09] <lightguard_jp> I guess it's not so much of a concern though.
[00:28:22] <lightguard_jp> We pull it from maven, bundle it and go.
[00:30:47] <aslak> lightguard_jp, kinda, you can scan for a artifactId in classloader sources, fetch the file, read manifest.fm to get the full groupid/artifactid/version
[00:31:20] <aslak> not classloader.getResource, but rather getResource("/"), parse all the URls and get a ref to the file
[00:31:33] <aslak> or similar
[00:32:11] <lightguard_jp> I think it's a concern for in-container as we'd want to add it to the archive that's deployed (or maybe we could test to see if Groovy is there first) as it'll already be there for a client test as a transitive dep
[00:32:30] <lightguard_jp> Actually either transitive or first level dep, depending how they do it.
[00:33:20] <aslak> lightguard_jp, not quite following.. you want to only bundle it up for incontainer testing if it's not in container ?
[00:33:32] <lightguard_jp> Yeah
[00:33:45] <lightguard_jp> Because it'll already be there if we're running in client mode.
[00:34:03] <lightguard_jp> But if we're running in the container we'll need it in the archive or in the container itself.
[00:34:56] <aslak> what we normally do, is not have a transitive dep from arq to groovy, the user provide that, then we package what the user provided if we need to move it to a remote server
[00:35:47] <lightguard_jp> Okay, I'll have to look into what we've done in other plugins.
[00:35:49] <aslak> but groovy is a bit big to be handled in this fashion.. having some what the same issue with jsfunit+++deps as well, but don't have a good solution for it
[00:35:54] <aslak> https://github.com/arquillian/arquillian-testrunner-spock/blob/Alpha3/src/main/java/org/jboss/arquillian/framework/spock/SpockAuxiliaryArchiveAppender.java
[00:36:35] <aslak> that's the current v. used by the spock runner.. basically package it up based on packages found on client cp
[00:36:53] *** aamonten has quit IRC
[00:41:37] <lightguard_jp> Hm
[01:57:45] *** lightguard_jp is now known as lightguard_jp_aw
[02:01:08] *** aslak has quit IRC
[02:08:26] *** jbossbot has quit IRC
[02:08:48] *** jbossbot has joined #jbosstesting
[02:19:08] *** ianbrandt has quit IRC
[02:41:50] *** lightguard_jp_aw is now known as lightguard_jp
[03:23:36] *** cjalmeida has joined #jbosstesting
[03:23:53] <cjalmeida> hi all.
[03:24:07] <cjalmeida> what's the best way to bundle libraries using shinkwrap?
[03:24:10] <cjalmeida> for remote testing?
[03:40:05] *** lightguard_jp has quit IRC
[04:25:48] *** adinn has joined #jbosstesting
[05:11:34] *** ldimaggi has quit IRC
[05:49:01] <adinn> dmlloyd: thanks for the mind dump -- I'll have a think about it and also play with AS 7 then get back to you
[05:49:39] <dmlloyd> okay.  I'm sure there's a good way to make it all work
[05:56:52] <adinn> dmlloyd: yes, -- in fact I think I was worrying prematurely about the Byteman code visibility since Aslak said it worked using -javaagent on the command line.
[05:57:03] <dmlloyd> cool.
[05:57:55] <adinn> dmlloyd: do you somehow explicitly hide classes that are loaded by the system classloader form being visible to app classloaders? if so how and by what policy?
[05:58:34] <dmlloyd> yes, we do.  Basically modules by default see nothing (other than java.* and sun.reflect.*), as I said in the email
[05:59:03] <dmlloyd> we do create a special module called "system" though
[05:59:10] <dmlloyd> it includes everything from the initial app CL
[05:59:32] <dmlloyd> in order to use that though, and avoid conflict issues, we filter that down before actually using it
[05:59:47] <dmlloyd> "javax.api" gives you all the non-java.* stuff from the JDK
[06:00:06] *** cjalmeida has quit IRC
[06:00:08] <dmlloyd> well, except for stuff we replace, like org.omg, javax.xml.stream, etc
[06:00:08] <adinn> so you only delegate loads for java.* and sun.reflect.*  to the sys loader by default?
[06:00:14] <dmlloyd> right
[06:00:27] <dmlloyd> the former for legal reasons, the latter for java.util.Proxy to work
[06:00:29] <dmlloyd> er
[06:00:34] <dmlloyd> java.lang.reflect.Proxy
[06:00:35] <dmlloyd> whatever it is
[06:01:06] <adinn> ok, so then adding extra packages to the modules list on the command line opens up this set but also costs in string prefix matching
[06:01:13] <dmlloyd> yeah
[06:01:13] <adinn> at every load
[06:01:16] <adinn> :-)
[06:01:19] <adinn> :-(
[06:02:30] <dmlloyd> so if you confine all your visible-to-everyone stuff to just one package (preferably with a short name!) it'd be idea
[06:02:32] <dmlloyd> ideal*
[06:03:32] <dmlloyd> I alluded to the JProfiler thing - they required org.jprofiler to be on that list for a while but in their latest one (6 I think?) they have a new way of solving the same problem
[06:03:38] <dmlloyd> not sure what they did though
[06:03:53] <adinn> hmm, well, the Byteman code is all under org.jboss.byteman* but there are a lot of subpackages
[06:04:08] <stuartdouglas> I fixed it in fakereplace by instrumenting loaded class loaders to always delegate org.fakereplace
[06:04:22] <adinn> :-) nice
[06:04:36] <stuartdouglas> I assume that is how jprofiler fixed it as well
[06:05:39] <adinn> well, I could always try to do the same I guess but that needs to work with a dynamic agent load . . . I suppose that's ok if you redefine . . .
[06:06:50] <dmlloyd> cool idea
[06:07:09] <stuartdouglas> yea, I use retransformation
[06:07:34] <stuartdouglas> otherwise it is to hard to tell with 100% certainty if a given class is a CL if you just try and do it at load time
[06:07:59] <stuartdouglas> as the super class may not have been loaded yet, so it is hard to tell if the superclass is or is not a class loader
[06:09:14] <adinn> Anyway, whatever Aslak has tried I think the modules loader is likely to stop Byteman injection working at all -- when I transform a class to inject a rule  I have to insert references to Byteman exception classes so I can catch a THROW or RETURN exit from the rule code. so for an app class loaded via the modules classloader this is likely to lead to a verify error because the exception class will fail to resolve.
[06:09:53] <dmlloyd> yeah, we've seen similar things before.
[06:10:57] <adinn> stuartdouglas: honestly not loading the super is the biggest pain -- all so a transformer can redefine the super hierarchy but I am sure that is done rarely if at all
[06:11:41] <stuartdouglas> I know, it is a massive pain
[06:12:13] <stuartdouglas> even if the super was loaded first the tranformer could still transform the heirachy
[06:13:11] <adinn> did I mention the hack I used in Byteman to get round this for checking rules which inject into overriding classes?
[06:13:26] <stuartdouglas> no
[06:13:40] <stuartdouglas> manually load the bytecode?
[06:14:02] <stuartdouglas> load then retransform?
[06:14:20] <adinn> yes, I try loading a .class file dor the parent as a resource and then use a very minimal ASM classreader to grab the super/interfaces and so on recursively. it works 9% of the time and is pretty quick
[06:14:26] <adinn> ^9^99^ :-)
[06:15:13] <dmlloyd> it will probably work less well under Modules :(
[06:15:26] <dmlloyd> actually I take that back
[06:15:31] <stuartdouglas> fakereplace is pretty slow at the moment, it needs a lot of work to get it to the stage where it is actually a useful tool
[06:15:42] <stuartdouglas> the recursive bit will be the problem
[06:15:48] <dmlloyd> I'm not really sure whether you can have non-immediately-visible super-supertype
[06:15:54] <dmlloyd> probably not, I guess
[06:16:22] <adinn> no should not be possible else the subclass load would fail anyway
[06:16:39] <stuartdouglas> I think it may be possible
[06:16:42] <dmlloyd> assuming you're looking for supertypes in the subclass' defining class loader
[06:17:06] <dmlloyd> if you're in some sibling CL which just references the class, its loader may not be able to see the supertype(s)
[06:17:53] <dmlloyd> yeah looks like you get the defining loader, so it's probably ok
[06:17:56] <dmlloyd> maybe
[06:18:30] <dmlloyd> anyway the scenario I'm thinking of is class A {} class B extends A {} class C extends B {}
[06:18:46] <dmlloyd> each in a different module, where C's module sees B (but not A), and B's module sees A
[06:19:03] <dmlloyd> C could conceivably be linked since B is fully loadable
[06:19:08] <dmlloyd> but, maybe not :)
[06:19:31] * dmlloyd should write a test
[06:19:47] * dmlloyd should find a sucker, er volunteer, to write a test
[06:19:58] <adinn> oops, <ducks>
[06:20:08] <stuartdouglas> ok
[06:32:41] <stuartdouglas> seems to work
[06:35:28] <stuartdouglas> dmlloyd: that works, it is possible for a sub class to have an indirect superclass that is not visible to the CL
[06:35:43] <dmlloyd> interesting.
[06:36:17] <dmlloyd> too bad there's no way to know what class loader satisfied a resource load request
[06:37:36] <stuartdouglas> https://github.com/stuartwdouglas/jboss-modules/commit/47becc9a5f22d986a11d4a4ef92b1b49b563d5b2
[06:37:37] <jbossbot> git [jboss-modules] 47becc9.. Stuart Douglas random test
[06:42:40] <adinn> wow freaky!
[06:46:27] <adinn> so it works because there is an individual import to establish the validity of each superclass reference but no honouring of transitive reference chains. that's pretty amazing.
[06:46:47] <adinn> :-)
[06:46:59] <stuartdouglas> I can't remember anything in the JVM spec that would imply that this should not work
[06:54:02] <dmlloyd> yeah I was trying to think of a reason why it wouldn't work but was unable to
[06:54:12] <dmlloyd> unless C directly referenced A in some other way
[06:55:54] <adinn> no, I don't think the JVM spec requires anything other than for the classloader which is trying to resolve a subclass to be able to see the superclass. if the classloaders are hiding *parents* of the superclass from the subclass that won't matter so long as the same criterion was met relative to their children when they were resolved.
[06:56:49] <adinn> but one interesting thing is that you can still access A reflectively and still obtain a handle on its classloader
[06:56:53] <adinn> that's kind of weird
[06:58:43] <dmlloyd> if you use B's CL from C, sure, you could get at A that way
[06:58:56] <dmlloyd> or use C.class.getSuperclass().getSuperclass(), more simply
[06:59:05] <dmlloyd> or B.class.getSuperclass() even more simply :)
[06:59:43] <dmlloyd> though now that I say it, that's probably what you meant
[06:59:51] <adinn> :-0
[07:01:07] <dmlloyd> even weirder, if A imported C, A could access C directly without seeing B :)
[07:05:07] <adinn> so what is really counterintuitive is that if we have an instance of C called c and we execute: Class<?> c1 = c.getClass(); Class<?> c2 = c1.getSuper(); Class<?> c3 = c2.getSuper(); String n = c3.getName(); then when we execute c1.getClassLoader().loadClass(n) it throws a CNFE!
[07:05:22] *** ALR1 has joined #jbosstesting
[07:05:32] *** ALR1 has quit IRC
[07:06:21] *** ALR has quit IRC
[07:23:16] *** lightguard_jp has joined #jbosstesting
[08:05:46] *** tdiesler has joined #jbosstesting
[08:14:44] *** rruss has quit IRC
[08:37:17] *** jeand has joined #jbosstesting
[08:37:54] *** michaelschuetz has joined #jbosstesting
[08:40:08] *** mgoldmann has joined #jbosstesting
[08:53:32] *** michaelschuetz1 has joined #jbosstesting
[08:53:45] *** michaelschuetz has quit IRC
[09:00:02] *** rruss has joined #jbosstesting
[09:01:18] *** ge0ffrey has joined #jbosstesting
[09:06:10] *** lightguard_jp has quit IRC
[09:11:23] *** alesj has joined #jbosstesting
[09:13:16] *** adinn has left #jbosstesting
[09:14:43] *** kpiwko has joined #jbosstesting
[09:18:19] *** jeand has quit IRC
[09:21:58] *** jeand has joined #jbosstesting
[09:37:50] *** jharting has joined #jbosstesting
[09:46:11] *** aslak has joined #jbosstesting
[09:54:53] *** ge0ffrey_ has joined #jbosstesting
[09:57:35] *** ge0ffrey has quit IRC
[10:04:01] *** rruss has quit IRC
[10:05:58] <nickarls> aslak: happy syttende mai ;-)
[10:08:36] *** torben has joined #jbosstesting
[10:09:45] *** michaelschuetz1 has quit IRC
[10:15:56] *** michaelschuetz has joined #jbosstesting
[10:18:29] *** michaelschuetz1 has joined #jbosstesting
[10:20:19] *** michaelschuetz has quit IRC
[10:21:28] *** michaelschuetz has joined #jbosstesting
[10:22:44] *** michaelschuetz1 has quit IRC
[10:23:10] *** galderz has joined #jbosstesting
[10:25:28] *** aslak has quit IRC
[10:26:20] *** aslak has joined #jbosstesting
[10:28:01] *** aslak has quit IRC
[10:28:39] *** aslak has joined #jbosstesting
[10:39:21] *** aslak has quit IRC
[10:39:57] *** aslak has joined #jbosstesting
[10:42:14] *** maeste has joined #jbosstesting
[10:43:02] <aslak> nickarls, thank you ! :)
[10:44:12] *** aslak has quit IRC
[10:48:19] *** rruss has joined #jbosstesting
[10:56:16] *** aslak has joined #jbosstesting
[10:56:16] *** aslak has quit IRC
[10:56:16] *** aslak has joined #jbosstesting
[11:27:56] *** alesj has quit IRC
[11:31:42] *** vtunka has joined #jbosstesting
[11:42:08] *** vtunka has quit IRC
[11:53:37] *** maschmid has joined #jbosstesting
[11:56:29] *** davidbos has joined #jbosstesting
[12:28:41] *** tdiesler has quit IRC
[12:35:29] *** tdiesler has joined #jbosstesting
[12:49:54] *** DavideD has joined #jbosstesting
[13:03:06] *** michaelschuetz has quit IRC
[13:03:54] *** michaelschuetz has joined #jbosstesting
[13:44:32] *** Jaikiran has joined #jbosstesting
[14:02:31] *** rruss has quit IRC
[14:02:42] *** rruss has joined #jbosstesting
[14:09:21] *** rruss has quit IRC
[14:09:31] *** rruss has joined #jbosstesting
[14:12:15] *** vtunka has joined #jbosstesting
[14:32:52] *** michaelschuetz has quit IRC
[14:33:37] *** michaelschuetz has joined #jbosstesting
[14:50:23] *** cjalmeida has joined #jbosstesting
[14:55:53] *** ldimaggi has joined #jbosstesting
[15:11:16] *** [jdlee] has joined #jbosstesting
[15:14:24] *** [jdlee] has quit IRC
[15:14:24] *** [jdlee] has joined #jbosstesting
[15:19:13] *** [jdlee] has quit IRC
[15:19:54] *** jdlee has quit IRC
[15:20:55] *** yzaslavs has joined #jbosstesting
[15:20:56] *** jdlee has joined #jbosstesting
[15:20:57] *** jdlee has joined #jbosstesting
[15:22:30] <cjalmeida> hello
[15:22:46] <cjalmeida> is there any doc on the maven resolver for shinkwrap?
[15:30:13] *** jharting has quit IRC
[15:35:27] *** bobmcw has quit IRC
[15:44:30] *** bobmcw has joined #jbosstesting
[15:52:39] *** jdlee has quit IRC
[15:55:36] *** jdlee has joined #jbosstesting
[15:56:06] *** jdlee has quit IRC
[15:56:38] <kpiwko> cjalmeida: hi, we have javadoc + test classes, unfortunately no html/pdf doc
[15:56:53] *** jdlee has joined #jbosstesting
[15:56:53] *** jdlee has joined #jbosstesting
[16:00:45] *** tdiesler has quit IRC
[16:21:48] *** aamonten has joined #jbosstesting
[16:22:25] <aamonten> aslak: hi
[16:26:34] *** michaelschuetz has quit IRC
[16:27:21] *** michaelschuetz has joined #jbosstesting
[16:31:51] <aslak> aamonten, heya
[16:32:04] <aamonten> aslak: how are you?
[16:32:44] <aamonten> aslak: do you have a sec to join us at switchyard channel? its about arquillian support
[16:32:47] <aslak> aamonten, fine, your self?
[16:32:52] <aslak> sure
[16:32:54] <aamonten> fine, thanks
[16:33:13] <aslak> hmm.. i'm normally in there.. guess it got lost in a reinstall ro something
[16:45:05] *** vtunka has quit IRC
[17:08:00] *** michaelschuetz has quit IRC
[17:13:21] *** Jaikiran is now known as Jaikiran|Dinner
[17:23:30] *** maeste has quit IRC
[17:24:00] *** jpederse has joined #jbosstesting
[17:24:33] *** jpederse has left #jbosstesting
[17:24:43] *** galderz has quit IRC
[17:33:05] *** aamonten has quit IRC
[17:38:53] *** maeste has joined #jbosstesting
[17:41:49] <kpiwko> cjalmeida: you might want to check these file for more information how to use maven resolver https://github.com/shrinkwrap/shrinkwrap/tree/master/extension-resolver/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven
[17:46:10] *** kpiwko has quit IRC
[18:04:03] *** maschmid has quit IRC
[18:26:17] *** DavideD has quit IRC
[18:29:37] *** Jaikiran|Dinner has quit IRC
[18:30:12] *** torben has quit IRC
[18:33:24] *** ianbrandt has joined #jbosstesting
[18:39:49] *** torben has joined #jbosstesting
[18:42:51] *** maeste has quit IRC
[19:01:03] *** torben has quit IRC
[19:01:18] *** davidbos has quit IRC
[19:07:07] *** ALR1 has joined #jbosstesting
[19:11:15] *** lightguard_jp has joined #jbosstesting
[19:29:19] *** ge0ffrey_ has quit IRC
[19:38:59] *** cjalmeida has quit IRC
[20:16:01] *** yzaslavs has quit IRC
[20:45:21] *** michaelschuetz has joined #jbosstesting
[21:07:05] *** michaelschuetz has quit IRC
[21:07:46] *** michaelschuetz has joined #jbosstesting
[21:22:36] *** mgoldmann has quit IRC
[21:36:28] *** michaelschuetz has quit IRC
[21:56:53] *** tdiesler has joined #jbosstesting
[22:03:13] *** pgmjsd has joined #jbosstesting
[22:28:10] <aslak> tdiesler, ping
[22:29:19] <tdiesler> hey
[22:33:53] <pgmjsd> If I'm running my tests with jboss-6-remote, how do I deploy things like DataSources and JMS destinations?
[22:34:10] <aslak> pgmjsd, @Deployment Descriptor
[22:34:43] <pgmjsd> Okay, so that works for any kind of descriptor thing?
[22:34:53] <aslak> tdiesler, is there any sharing of spi classes between arq appcl and arq incontainer bundle (embedded mode) ?
[22:35:43] <aslak> tdiesler, the JMXMethodExecutor seems to be find by casting to TestResult, but my new spi.command.Command gets classcast.  any osgi bundle magic i need to add ?
[22:36:50] <aslak> pgmjsd, from Arquillains side it only cares about the Descriptor interface, which is basically a getDescriptorName and exportToString. there might not be any impls for DataSource Descriptor etcm but Arq does not care.. :)
[22:37:19] <tdiesler> aslak, there is no sharing - you need to serialize the result
[22:37:24] <pgmjsd> aslak -
[22:37:36] <pgmjsd> So I could just deploy a file resource.
[22:37:39] <tdiesler> aslak, only applies to embedded of course
[22:38:21] <aslak> tdiesler, aa right.. i miss read the if there.
[22:38:33] <aslak> so serialize for embedded, because remote does it already
[22:39:09] <aslak> pgmjsd, if you wrap it up in the Descriptor interface, sure
[22:39:43] <tdiesler> aslak, yes
[22:40:09] <pgmjsd> aslak: Great... and if I want to deploy a JAR and a JMS endpoint, for example?   Multiple @Deployment methods?
[22:41:27] <aslak> pgmjsd, yea
[22:43:20] <pgmjsd> aslak: What if I want those things to be deployed with the test suite, rather than with every test class?   Maybe that's not a good idea.
[22:45:41] <jbossbot> git [descriptors] push master 8e9d434.. Andrew Lee Rubinger [maven-release-plugin] prepare release 1.0.0-beta-1
[22:45:41] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/03128c5...8e9d434
[22:45:44] <jbossbot> git [descriptors] push 1.0.0-beta-1 URL: http://github.com/shrinkwrap/descriptors/compare/0000000...eaf8c14
[22:45:48] <jbossbot> git [descriptors] push master bf2f791.. Andrew Lee Rubinger [maven-release-plugin] prepare for next development iteration
[22:45:48] <jbossbot> git [descriptors] push master URL: http://github.com/shrinkwrap/descriptors/compare/8e9d434...bf2f791
[22:47:56] <ALR1> aslak: ^^
[22:47:59] <ALR1> Released.
[23:03:24] <tdiesler> ALR1, aslak, I resolved AS7-773 We can now continue to upgrade that on-demand deployment to the new ARQ version
[23:03:32] <jbossbot> jira [AS7-773] Replace ARQ subsystem by on-demand deployment [Resolved (Done) Task, Major, Thomas Diesler] https://issues.jboss.org/browse/AS7-773
[23:04:04] <tdiesler> ALR1, aslak, I suggest we do this work in https://github.com/tdiesler/jboss-as/tree/as773 so it woulnt be too disruptive for other folks
[23:05:23] <tdiesler> ALR1, aslak, we could merge to master once we have smoke+itegration tests running on the new infrastructure. Note, I also migrated all smoke tests (i.e. the once I could) to the managed container. I suggest we first focus on that one
[23:12:23] <aslak> pgmjsd, that's  not supported currently, only pr testclass. you could do it in a extension but
[23:12:31] <aslak> ALR1, great, thanks
[23:13:17] <aslak> tdiesler, sounds good
[23:16:29] <aslak> tdiesler, where do you deploy the arq service?
[23:16:56] <aslak> tdiesler, is it only setup to be on demand start up ? or am i missing something
[23:27:17] *** jeand has quit IRC
[23:30:38] <tdiesler> aslak, its in the AbstractDeployableContainer http://pastie.org/1918560
[23:42:10] <aslak> aa , thanks
[23:43:04] *** tdiesler has quit IRC





top