[00:21:50] *** jose_freitas has quit IRC
[01:07:12] *** ALR has joined #jbosstesting
[01:27:24] *** bleathem has quit IRC
[01:35:05] *** rruss has quit IRC
[01:44:00] *** lightguard_jp has quit IRC
[02:00:25] *** ALR has quit IRC
[02:00:34] *** jamezp has joined #jbosstesting
[02:08:45] *** rruss has joined #jbosstesting
[02:24:24] *** johnament has joined #jbosstesting
[02:31:07] *** jose_freitas has joined #jbosstesting
[02:35:00] *** ianbrandt has quit IRC
[03:14:08] *** rruss has quit IRC
[03:23:14] *** ldimaggi has joined #jbosstesting
[03:35:39] *** jamezp is now known as jamezp_afk
[03:44:11] *** johnament has quit IRC
[03:52:06] *** bobmcw has quit IRC
[03:52:50] *** bobmcw has joined #jbosstesting
[05:12:04] *** ldimaggi has quit IRC
[05:45:38] *** jose_freitas has quit IRC
[06:32:59] *** rruss has joined #jbosstesting
[07:25:36] *** Jaikiran has joined #jbosstesting
[08:23:43] *** ge0ffrey has joined #jbosstesting
[08:38:06] *** mgoldmann has joined #jbosstesting
[08:42:05] *** maschmid has joined #jbosstesting
[09:12:02] *** pilhuhn has joined #jbosstesting
[09:55:05] *** jeand has joined #jbosstesting
[10:01:02] *** vtunka has joined #jbosstesting
[10:13:36] *** dabloem has joined #jbosstesting
[10:28:10] *** alesj has joined #jbosstesting
[10:36:04] *** maeste has joined #jbosstesting
[10:43:23] *** alesj has quit IRC
[10:57:18] *** jeand_ has joined #jbosstesting
[11:00:34] *** jeand has quit IRC
[11:31:54] <ge0ffrey> using arquillian-weld-se-embedded-1.1 should work, no?
[11:32:07] <ge0ffrey> with a WebArchive?
[12:21:17] *** DavideD has joined #jbosstesting
[12:23:18] <ge0ffrey> stuartdouglas: you got any experience with arquillian by any chance?
[12:24:49] <stuartdouglas> yes
[13:03:27] <ge0ffrey> stuartdouglas: I am constantly getting "ClassNotFoundException: classes.org.drools.guvnor.client.decisiontable.cells.PopupNumericEditCell"
[13:03:49] <ge0ffrey> but in my beans.xml I have <weld:scan><weld:exclude name="org.drools.guvnor.client.**"/>
[13:04:07] <stuartdouglas> is that classes.org.drools? or org.drools?
[13:04:23] <ge0ffrey> yea, it's says classes.
[13:04:28] <ge0ffrey> which is clearly wrong
[13:04:36] <stuartdouglas> thats really weird
[13:04:41] <stuartdouglas> can you post your are test?
[13:04:50] <ge0ffrey> https://gist.github.com/1153830
[13:05:56] <ge0ffrey> stuartdouglas: the whole @Deployment method is making my life difficult the past few working days, tbh :/
[13:06:04] <stuartdouglas> ge0ffrey: are you using the embedded container?
[13:06:24] <ge0ffrey> stuartdouglas: yes, now I am trial and erroring with arquillian-weld-ee-embedded-1.1
[13:06:30] <ge0ffrey> although I 've tried others before
[13:06:36] <stuartdouglas> that is part of the problem
[13:06:49] <stuartdouglas> you can't use a WebArchive with embedded
[13:07:17] <ge0ffrey> not with ee-embedded either?
[13:07:31] <stuartdouglas> nope
[13:07:43] <ge0ffrey> my project is a war
[13:07:46] <stuartdouglas> I would use AS7 or jetty
[13:08:02] <ge0ffrey> jetty and GWT in the same classpath = game over
[13:08:17] <stuartdouglas> ah
[13:08:18] <ge0ffrey> at least tomcat is, I can trie
[13:08:21] <ge0ffrey> try
[13:08:25] <stuartdouglas> tomcat or as7 then?
[13:08:39] <ge0ffrey> AS7: I am using weld .Finals's, not .AS7's
[13:09:02] <ge0ffrey> and AS7 didn't work before, so I want to do one refactor at a tim
[13:09:03] <ge0ffrey> e
[13:09:21] <ge0ffrey> I'll try jetty
[13:09:36] <stuartdouglas> jetty or tomcat?
[13:09:38] <ge0ffrey> stuartdouglas: tnx btw
[13:10:00] <ge0ffrey> tomcat + GWT = game over, because gwt-dev (which uses jetty) has tomcat classes
[13:10:39] <ge0ffrey> stuartdouglas: could you verify that the rest of my @Deployment method makes sense?
[13:10:48] <ge0ffrey> Can I include the entire WEB-INF dir at once?
[13:12:01] <stuartdouglas> ge0ffrey: also .addAsResource(new File("target/classes/")) is screwy
[13:12:20] <ge0ffrey> stuartdouglas: so what should I be?
[13:12:23] <ge0ffrey> *it be
[13:13:00] <stuartdouglas> I am not really sure
[13:13:15] <stuartdouglas> I don't know if there is an easy way to deploy a whole war
[13:13:37] <stuartdouglas> I would probably import in using the shrink-wrap ZipImporter
[13:15:16] <stuartdouglas> I think its like war.as(ZipImporter.class).import("target/mywar.war");
[13:15:20] <stuartdouglas> or something like that
[13:15:21] <ge0ffrey> stuartdouglas: but that means I have to build the entire war in the IDE to run a single unit test?
[13:15:51] *** aslak has joined #jbosstesting
[13:15:51] *** aslak has quit IRC
[13:15:51] *** aslak has joined #jbosstesting
[13:16:01] <stuartdouglas> if you only need some packages you can use addPackage()
[13:16:19] <ge0ffrey> stuartdouglas: we just need to be able to use @Inject in our unit tests (much like spring-testing) at this point.
[13:16:30] <ge0ffrey> I need all packages, all dependencies, all configuration
[13:17:09] <ge0ffrey> and I need to run 1020 tests
[13:17:55] <ge0ffrey> Is arquillian and shrinkwrap a good idea for that, or should I 'look into mimicing the seam lifecyle like we did in seam 2?
[13:18:38] <stuartdouglas> it might be possible to use a java archive deployment in the embedded container
[13:19:13] <stuartdouglas> I don't really know, you should probably talk to aslak
[13:19:19] <ge0ffrey> stuartdouglas: I 'll try jetty first
[13:19:53] <ge0ffrey> aslak, stuartdouglas: will using a Shrinkwrap with all classes, all dependencies and all WEB-INF resources scale to 1020 tests?
[13:20:05] <stuartdouglas> no idea
[13:20:17] <ge0ffrey> I'd use a single shrinkwrap in an abstract superclass, GuvnorTestBase
[13:20:19] <aslak> ge0ffrey, define scale ?
[13:20:42] <ge0ffrey> aslak: only build the war once of @Deployment
[13:21:02] <aslak> ge0ffrey, you can build it only once, but it will be deployed multiple times
[13:21:08] <ge0ffrey> aslak: only start weld once
[13:21:28] <ge0ffrey> aslak: each test witll deploy the shrinkwrap war?
[13:21:45] <aslak> ge0ffrey, this is a open issues with arq currently, there is a 1 to 1 mappingn between deployment and testcase
[13:21:52] <aslak> ge0ffrey, each test class
[13:22:06] <aslak> testcase/testclass
[13:22:07] <ge0ffrey> aslak: got an issue id for me to follow?
[13:23:08] <aslak> ARQ-197
[13:23:09] <jbossbot> jira [ARQ-197] Research support for @Deployment on multiple levels [Open (Unresolved) Feature Request, Minor, Unassigned] https://issues.jboss.org/browse/ARQ-197
[13:23:12] <stuartdouglas> aslak: I think ge0ffrey's case is going to be very common one, a lot of apps don't really break down into little deployments very well
[13:23:25] <aslak> stuartdouglas, i know..
[13:23:31] <ge0ffrey> aslak: spring-testing doesn't have that problem. They supply an abstract test superclass that supports reusing the ApplicationContext for all tests in all classes that extend your abstract class. (don't shoot the messenger :)
[13:24:01] <ge0ffrey> aslak: tnx for the reference, watching it
[13:24:06] <aslak> stuartdouglas, it's common, but i also think it's very common in the sense of converting a old test suite to arq.
[13:25:16] <aslak> i like to relate it to how everyone was saying that TDD was impossible because it's my code is not testable in that fhasion. but what TDD states is more the other way around, that if you can test it it's a sign of good design and so on..
[13:26:29] <aslak> to some extent that spans to a full EE app as well.. I can't test anything but my complete app.. well, your app is lacking proper separation among others
[13:27:05] <aslak> (not to state that testing the full app as a complete is not a valid usecase.. it's just not that simple with arq atm due to the 1 to 1 mapping of deployment to test class)
[13:27:19] <ge0ffrey> aslak: maybe true, but if you want to do integration testing, you really need all classes and all dependencies and all configuration loaded most of the time
[13:27:34] <stuartdouglas> I think a case will be an app with a lot of entities (100+), they are pretty much all going to have to be deployed if they have relationships with each other, and that is just going to blow test time out of the water
[13:27:57] <ge0ffrey> yep
[13:28:44] <ge0ffrey> on a project I worked on, we had 300 tests taking 3 hours, running 1 test took 30 seconds
[13:29:10] <ge0ffrey> I refactored that, so 1 test took 60 seconds (= 40 seconds boottime) and 300 tests took 120 seconds
[13:29:35] <ge0ffrey> just by sharing the spring context (= weld container) and test database
[13:29:43] <ge0ffrey> (but we'll discuss the test database another time)
[13:33:02] *** jose_freitas has joined #jbosstesting
[13:33:25] <ge0ffrey> aslak: I commmented on https://issues.jboss.org/browse/ARQ-197
[13:33:27] <jbossbot> jira [ARQ-197] Research support for @Deployment on multiple levels [Open (Unresolved) Feature Request, Minor, Unassigned] https://issues.jboss.org/browse/ARQ-197
[13:34:59] <ge0ffrey> aslak: http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/test/AbstractSingleSpringContextTests.html
[13:45:18] *** OndraZizka has quit IRC
[13:45:32] *** OndraZizka has joined #jbosstesting
[14:20:43] <aslak> ge0ffrey, hmm, yea using subclasses might not be a bad idea..
[14:21:22] <aslak> ge0ffrey, you would expect @Before/After of course be executed from superclass..
[14:21:45] <aslak> ge0ffrey, both super and sub can define @Deployments, but sub is only within the sub classes scope
[14:22:37] <ge0ffrey> aslak: that's how one does it in spring
[14:25:43] <aslak> ge0ffrey, my initial idea was to have some sort of @Suite annotation that you can define and include multiple tests within that suite.
[14:26:46] <aslak> ge0ffrey, been playing with the idea of turning it around as well, where it's the Deployment that defines which tests to run. but not really digged into that idea far enough
[14:27:41] <aslak> ge0ffrey, basically it would be a Deployment defines the environments, and you have X tests. each test says something about it's environmental conditions. if the deployment satisfies those the test will run
[14:28:19] <aslak> e.g. Add a EJB to the Deployment, and Tests involving that EJB will be ran
[14:29:09] <ge0ffrey> aslak: configuration by exception. Having to explicitly state each of our 1k tests to the @Deployment would be a good thing
[14:30:24] <aslak> ge0ffrey, true, but what defines a @Suite can be pluggable, e.g. Package, Module, Name, SuperClass etc
[14:31:49] <aslak> ge0ffrey, i
[14:32:09] <aslak> ge0ffrey, i'm sure you mean having to explicitly state each would be a bad thing  ?
[14:33:40] <ge0ffrey> yep
[14:34:15] <ge0ffrey> aslak: tbh, I find having to write @Deployment already too much boilerplate
[14:35:29] <ge0ffrey> I mean I use maven. So all the info is there: yes, it's war (no need to see WebArchive); yes, where do you think my web-inf resources are? That's right, in src/main/webapp as defined by my maven pom.xml and so on
[14:35:49] <aslak> ge0ffrey, you can do that..
[14:36:01] <ge0ffrey> something like @DeploymentFromMaven public String getDeploymentPom(){ return "pom.xml";} should suffice
[14:36:24] <ge0ffrey> no need for addAsWebInfResource or addAsLibraries or ...
[14:36:35] <ge0ffrey> aslak: how? that would be great if it's possible
[14:36:40] <aslak> bind surefire to the integration phase, and import the maven output
[14:37:16] <ge0ffrey> aslak: but I still need to define @Deployment, no?
[14:37:35] <aslak> ge0ffrey, sure, but that you define in one superclass
[14:37:58] <aslak> @Deployment ShrinkWrap.create(ZipImporter.class).importFrom(new FIle("my.war"))
[14:38:30] <ge0ffrey> aslak: can I work from an exploded directory?
[14:38:49] <ge0ffrey> so it works in intellij et all too?
[14:38:58] <aslak> sure
[14:39:12] <ge0ffrey> how do I get the version number in there?
[14:39:13] <aslak> either you can use war.add(new File("directory"))
[14:39:26] <ge0ffrey> new File("guvnor-webapp-5.3.0-SNAPSHOT")
[14:39:34] <aslak> or ShrinkWrap.create(ExplodedImporer.class).imortFrom(new File("directory"))
[14:40:11] <ge0ffrey> new File("guvnor-webapp" + version); // where to get version?
[14:40:21] <ge0ffrey> aslak: that's starting to make a lot more sense :)
[14:40:32] <ge0ffrey> why isn't that in the manual? :)
[14:40:58] <aslak> shrinkwrap doesn't have a manual.. :)
[14:41:33] <aslak> we do have some plans of writing a ShrinkWrap best preactices / tip and trix section, just haven't gotten around to it yet..
[14:41:58] <aslak> version number is well.. hmm.. not directly available..
[14:42:13] <aslak> but, you can either set finalName in your maven pom..
[14:44:44] <ge0ffrey> aslak: why not put in in the arquillian manual?
[14:44:54] <ge0ffrey> *put it in
[14:45:10] <ge0ffrey> aslak: it's already confusing to have to read 3 manuals in parallel (weld, seam and arquillian)
[14:47:35] <aslak> or add some simple logic to your deployment method, e.g.  http://pastebin.com/maeU29Kx
[14:48:12] <aslak> ge0ffrey, i was referring to the Arq manual about the tips and trix section..
[14:48:37] <aslak> ge0ffrey, docs.jboss.org/author/display/ARQ/Reference+Guide if you want to start one.. :)
[14:48:47] <ge0ffrey> aslak: tnx, I 'll check tips and trix
[14:50:30] <ge0ffrey> aslak: would love to, but realisticly it's not going to happen :( I am already in trouble because I underestimated the time to upgrade to seam3/arquillian (although a great part of that is directly related to our technical debt)
[14:51:26] <ge0ffrey> ExplodedImporter results in "RuntimeException: No property value found for key extension"
[14:52:21] *** kevinpollet has joined #jbosstesting
[14:53:16] <nickarls> aslak: is there way of disabling the Arquillian Noble crown from the community image, it's starting to be embarrassing ;-)
[14:53:35] <aslak> nickarls, embarrassing ?
[14:53:49] *** alesj has joined #jbosstesting
[14:54:12] <nickarls> aslak: someone might think I'm the king of the forum
[14:54:19] <nickarls> offering their virgin daughters etc
[14:54:23] <nickarls> the usual
[14:54:24] <ge0ffrey> aslak: no "tips" on http://docs.jboss.org/arquillian/reference/latest/en-US/html_single/
[14:54:44] <aslak> nickarls, hehe..  right, your married with kids.. ;)
[14:54:50] <aslak> nickarls, i can remove it if you like ?
[14:55:22] <nickarls> sure, you can put it back if I ever make some greet deed worthy of crowning ;-)
[14:55:28] <aslak> ge0ffrey, that's the Alpha5 docs
[14:55:36] <aslak> ge0ffrey, this is the updated ones: docs.jboss.org/author/display/ARQ/Reference+Guide
[14:55:50] <aslak> ge0ffrey, still no tips section tho.. as i said, it's thought of, not done
[14:56:21] <ge0ffrey> k tnx for the info
[14:56:43] <ge0ffrey> aslak: any idea why I am getting that "RuntimeException: No property value found for key extension" on ShrinkWrap.create(ExplodedImporter.class) ?
[14:57:32] <ge0ffrey> aslak: please update the magnolia website http://www.jboss.org/arquillian/docs
[14:58:02] <ge0ffrey> taht's where I got the wrong link to the manual
[14:58:15] <aslak> ge0ffrey, yea, if you specify the name in the import, it should goaway.. ShrinkWrap.create(ExplodedImproter.class, "name.war2)
[14:59:49] <aslak> ge0ffrey, yea i know..  a bit backed up on docs update in general..
[15:00:09] <aslak> or docs / site / announcments etc
[15:00:26] <ge0ffrey> aslak: tnx, that does the trick :) facing an issue in an invalid xml file, I 'll see if I can create a pull request so the xml file name is made visible in the exception message
[15:00:46] <aslak> ge0ffrey, ?
[15:02:12] <ge0ffrey> aslak: ignore for now ("DescriptorExportException: Could not export Node strcuture to XML" - "DOMException: INVALID_CHARACTER_ERR: An invalid or illegal XML character is specified."). The error is probably my side, but I 'll see for an issue so the offending file is made clear
[15:02:49] <aslak> ge0ffrey, probably related to a comment in the web.xml file
[15:03:09] <ge0ffrey> aslak: ah, its' full of them
[15:03:21] <ge0ffrey> according to intellij they are all valid though
[15:03:21] <aslak> ge0ffrey, descriptors has / had issues with that..  but we did fix that din't we
[15:03:37] <aslak> ge0ffrey, yea, it's just how Descriptors import and export it that goes wrong
[15:03:41] *** ldimaggi has joined #jbosstesting
[15:03:52] <ge0ffrey> Using arquillian-junit-container 1.0.0.CR2
[15:03:53] *** alesj has quit IRC
[15:04:07] <ge0ffrey> and shrinkwrap-resolver-impl-maven 1.0.0-beta-5
[15:05:15] <aslak> ge0ffrey, SHRINKDESC-31
[15:05:16] <jbossbot> jira [SHRINKDESC-31] Descriptors clobbers file markup and formatting [Resolved (Done) Feature Request, Major, Andrew Rubinger] https://issues.jboss.org/browse/SHRINKDESC-31
[15:05:31] <aslak> it's fixed, but doesn't look to be released yet
[15:06:19] <jose_freitas> where's kpwiko? I've been trying to catch him for a couple of days
[15:06:55] <aslak> ge0ffrey, no, it's out in alpha-2 of descriptors
[15:07:05] <aslak> jose_freitas, vacation i believe
[15:07:09] <aslak> jose_freitas, this week
[15:07:27] <ge0ffrey> aslak: tnx, I 'll override that dependency version
[15:07:34] <aslak> 1.1.0-alpha-2
[15:08:51] <aslak> ge0ffrey, oyu can use arq cr3
[15:09:24] <ge0ffrey> aslak: is CR4 also good?
[15:09:28] <aslak> ge0ffrey, sure
[15:09:30] <ge0ffrey> just noticed that out too
[15:09:33] <ge0ffrey> k, I was on CR2
[15:09:57] <aslak> cr3 and cr4 had a few changes for as7 7.0.1 that was released yesterday
[15:10:07] <ge0ffrey> ah nice
[15:10:57] <jose_freitas> aslak: hmmm nice! okay then, thanks aslak
[15:11:02] <ge0ffrey> What's the story with weld 1.x.y.Final and 1.x.y.AS7 anyway? Why not only .Final, so it works on any container?
[15:12:29] <aslak> ge0ffrey, not 100% sure, but i wonder if it was just a quick release for as7, and it's only tested with as7  or similar
[15:13:18] <ge0ffrey> it's definitly a version that is osgi-incompatible :/
[15:13:26] <aslak> ge0ffrey, basically some time constraint that made it a as7 specific release
[15:13:32] <ge0ffrey> ah good
[15:13:37] <ge0ffrey> so just wait and it will go away?
[15:13:55] <aslak> i would think so
[15:14:30] <aslak> that exact release won't change but, i'm sure there will be a release without .AS7 soon enough.. hehe
[15:16:45] *** ALR has joined #jbosstesting
[15:16:57] *** kevinpollet has quit IRC
[15:18:39] <ge0ffrey> All the latest releases togheter doesn't work: arquillian-tomcat-embedded-6:jar:1.0.0.CR1 isn't compatible with arquillian-junit-container:jar:1.0.0.CR4, because arquillian-protocol-servlet:jar:1.0.0.CR1 because of a NoClassDefFoundError on WebAppDescriptor.
[15:19:59] <ge0ffrey> I 'll CR3
[15:20:15] <ge0ffrey> I 'll try CR3
[15:23:23] <ge0ffrey> CR3 has the same problem
[15:36:35] <aslak> ge0ffrey, aa..
[15:37:09] <aslak> ge0ffrey, you need to specificly declare CR4 of the jboss.org.arquillian:arquillian-protocol-servlet:1.0.0.CR43
[15:37:39] <aslak> 43/4
[15:37:53] <ge0ffrey> k tnx, I 'll do that workaround
[15:38:18] <aslak> wondering if you add a dependencymanagment section and import the org.jboss.arquillian:arquillian-bom:1.0.0.CR4
[15:38:28] <ge0ffrey> just tried jetty7 instead of tomcat, but that gives yet another exception
[15:38:41] <aslak> the servlet protocol is defined there, not sure if maven then will upgrade the v. the tomcat-container depend on or not
[15:39:54] <ge0ffrey> aslak: that's the downside of having seperate release lifecycles for all those maven artifacts (as well as the confusion the different version numbers create) :/ (not saying that it's not worth it however)
[15:40:10] <ge0ffrey> if servlet changes, you kinda need to release tomcat and jetty
[15:40:27] <ge0ffrey> and also tell the world which combinations work
[15:41:09] <ge0ffrey> seam's idea of doing a "release of everything" every 6 months isn't a bad diea
[15:41:11] <ge0ffrey> idea
[15:41:19] <ge0ffrey> at least one knows that those versions are compatible
[15:41:28] <aslak> ge0ffrey, yea, i agree.. we need the seperate lifecycles, but not 100% happy with how maven resolves this..  or what to do to fix it
[15:42:18] <ge0ffrey> aslak: seperate lifecyles means seperate versions. Seperate versions means that you have to document which combination of version is compatible
[15:43:00] <ge0ffrey> don't think that maven is relevant
[15:43:17] <aslak> ge0ffrey, the container it self is competable.. the problem is that the container depend on a older v., which the arq-junit-contianer does not depend on.
[15:46:50] <ge0ffrey> ah yes
[15:47:03] <ge0ffrey> not sure how one could fix that
[15:47:44] <ge0ffrey> what's the point of splitting up arquillian-protoc-servlet into it's on jar?
[15:48:07] <ge0ffrey> why not just make that a package under the arquillian's main jar?
[15:48:17] <aslak> ge0ffrey, this works
[15:48:17] <aslak> https://gist.github.com/1154075
[15:49:05] <aslak> that seems to properly upgrade the arq-core related artifacts that the tomcat contianer is depending on to the arq core v defined
[15:51:05] <ge0ffrey> aslak: tnx, I 'll try that, although if I use a bom like that, I effectively overwrite my own versions of slf4j etc, no?
[15:51:16] <ge0ffrey> I tried this: https://gist.github.com/1154075#comments
[15:51:27] <aslak> ge0ffrey, we don't export sl4fj
[15:51:50] <aslak> ge0ffrey, arquillian-bom only export arq + shrinkwrap + shrinkwrap descriptor artifacts
[15:52:54] <aslak> eh?
[15:53:14] <aslak> not sure why you would get a xml parser issue there..
[15:53:44] <ge0ffrey> trying your way to verify I get the same xml parser issue
[15:54:03] <aslak> what's the complete stack trace there?
[15:56:02] <aslak> ge0ffrey, that sounds more like a tomcat + weld issue tho then a arq issue
[15:56:50] <ge0ffrey> aslak: complete stacktrace: https://gist.github.com/1154075#comments
[15:57:04] <ge0ffrey> aslak: I 've gotten it to work on tomcat 6 with weld/seam3
[16:00:34] <aslak> what's your complete dependency:tree ?
[16:01:02] <aslak> ge0ffrey, and have you ever had it working with a embedded tomcat using the same classpath ?
[16:02:06] <ge0ffrey> I have never had arquillian working yet
[16:03:23] <ge0ffrey> I've tried about a dozen maven configs and a dozen @Deployment configs so far (sorry for the sarcasm, your help is really appreciated, I am making a lot of progress now)
[16:03:41] <ge0ffrey> I wondering how that could be made simpler, less room to misconfigure
[16:03:55] <aslak> ge0ffrey, use a remote / managed container instead
[16:04:10] <aslak> embedded containers are painful in that sense, anything you put on your classpath might fuck it up
[16:04:38] <ge0ffrey> there's no tomcat managed yet? and remote is a maintance nightmare :/
[16:04:57] <ge0ffrey> I was using weld-ee-embedded to avoid that, but that can't handle war's apparently
[16:05:25] <aslak> https://github.com/arquillian/arquillian-container-tomcat/pull/6
[16:07:59] <ge0ffrey> ow, intresting :)
[16:08:40] <aslak> work in progress, but managed-6 there should work. just a few small changes before i pull it upstream
[16:09:54] <aslak> brb, lunch
[16:10:32] <ge0ffrey> aslak: tnx for your help, I 'll investigat the xml parser issue
[16:44:32] *** bdlink has joined #jbosstesting
[17:00:10] *** maeste has quit IRC
[17:21:34] *** ozizka has joined #jbosstesting
[17:25:08] *** ozizka is now known as ozizka-mtg
[17:36:40] *** jamezp_afk is now known as jamezp
[17:51:13] *** maschmid has quit IRC
[17:53:05] <ALR> aslak: Is there a way to use ARQ in TestNG that doesn't impose Class Hierarchy?  ie. extends Arquillian
[17:53:18] <aslak> ALR, not currently
[17:53:36] <ALR> aslak: Could there be?  This is currently a limitation of ARQ or TestNG?
[17:53:46] <aslak> ALR, i haven't looked in a while, but the testng listeners was just not 'powerful' enough to beable to what we needed
[17:55:28] *** ldimaggi has quit IRC
[17:57:31] <aslak> ALR, if i remember correctly, there were specifically a couple of issues. the IConfiguration interface that Cedrict created, for listeners to hook into @Before/After stuff is only called if the user actually defines Before/After. So it's not a phase listener like Arq needs, but a direct reflection on what is being executed
[17:58:18] <ALR> aslak: I've made a note to look into it thanks
[17:58:19] <aslak> and IConfiguration as well, is just a callback to this is happening now, now room for intercepting and disabling the calls(e.g. Before only for incontainer)
[17:58:21] <ALR> It came up in a meeting
[17:58:30] <aslak> now/no
[17:59:35] <aslak> and a Listener can implement multiple of the different interfaces to kinda get all the callbacks needed, but it was tricky to match them back togather.. between IConfigurable and IHookable etc
[18:00:32] <aslak> since you will have multiple Listener instances, one pr @Listener basically. matching up the order with arq became quite complex and at one point just impossible to do correctly
[18:15:00] *** pilhuhn is now known as pil-dinner
[18:17:10] 
[18:17:17] <ozizka-mtg> L
[18:18:43] <aslak> ozizka-mtg, good question.. :)
[18:18:56] <ozizka-mtg> :)
[18:20:46] *** dabloem has quit IRC
[18:28:43] *** ianbrandt has joined #jbosstesting
[18:44:07] *** bleathem has joined #jbosstesting
[19:01:50] *** rbattenfeld has joined #jbosstesting
[19:02:33] *** ozizka-mtg has quit IRC
[19:02:33] *** ge0ffrey has quit IRC
[19:21:25] *** jamezp has quit IRC
[19:27:19] *** jamezp has joined #jbosstesting
[19:28:46] <jose_freitas> aslak: ping
[19:30:28] <aslak> jose_freitas, hey
[19:31:02] <jose_freitas> jsfunit-arquillian work with tomcat now, but the jar has 7.9M ( ouch ). the dependencies added are bundled with jboss though, so I was thinking on adding them just when necessary.
[19:31:27] <jose_freitas> adding a systemproperty must not be a good way of doing because we would force the user to set it on maven
[19:31:45] <jose_freitas> wdyt that could be done?
[19:31:45] *** aslak has quit IRC
[19:32:22] <jose_freitas> forever alone
[19:34:54] *** aslak has joined #jbosstesting
[19:35:01] *** rbattenfeld has left #jbosstesting
[19:35:07] <aslak> jose_freitas, hmm.. ubuntu died on me
[19:35:47] <jose_freitas> (pasting)
[19:35:48] <jose_freitas> jsfunit-arquillian work with tomcat now, but the jar has 7.9M ( ouch ). the dependencies added are bundled with jboss though, so I was thinking on adding them just when necessary.
[19:35:58] <jose_freitas> adding a systemproperty must not be a good way of doing because we would force the user to set it on maven
[19:35:59] <jose_freitas> wdyt that could be done?
[19:36:11] *** alesj has joined #jbosstesting
[19:36:33] <aslak> jose_freitas, yea, hmm.. what does your jsfunit archive appender look like?
[19:37:54] *** alesj has quit IRC
[19:40:08] <jose_freitas> http://pastebin.com/k0UK2vPN
[19:40:22] <jose_freitas> look for org.apache.commons.logging
[19:40:33] <jose_freitas> it's the first package added in this situation
[19:41:37] <aslak> ai ai
[19:42:24] <jose_freitas> ?
[19:43:26] <aslak> jose_freitas, not sure what to do..
[19:46:42] <jose_freitas> aslak: it's a cool idea that arquillian is completelly modulated, and that besides the module that handle the container, everything else abstract that.
[19:47:16] <jose_freitas> but maybe, container module could provide that info
[19:48:30] <jose_freitas> well, that would not be very good actually, if everyone would start asking what container is to do specific tasks, it'd risk the cross-container feature
[19:53:08] *** Jaikiran has quit IRC
[19:54:32] <aslak> jose_freitas, yea, been trying to avoid that
[19:56:39] <aslak> jose_freitas, and in this case, what should the container provide ? it's lib folder content ?
[19:57:36] <aslak> jose_freitas, we do have a similar issue with the spock test runner..  it's fine for client side only testing, but with remote, it needs the Groovy runtime, which is about a 13 mb addon to the deployment
[19:58:01] <aslak> and takes about 12 sec to deploy  because everything is scanned for potensial EE anotations
[19:58:08] <jose_freitas> tss
[19:58:26] <jose_freitas> at least it should load for all the containers, right?
[19:59:14] <aslak> i was wondering about something similar there, having a option to specify it in arq.xml or something. could use the "extension" element, extension qualifier="spock-runner" property bundleGroovy=false
[19:59:19] <jose_freitas> in my case, those jars added for tomcat conflict with classes that jboss51 bundle
[19:59:57] <aslak> mm
[20:01:11] <aslak> jose_freitas, conflict how? make it not run or ?
[20:01:43] <jose_freitas> not run
[20:01:52] <jose_freitas> it doesn't load some xmls
[20:02:05] <aslak> hmm
[20:02:15] <jose_freitas> that's the trigger, but I was already thinking about that
[20:02:18] <aslak> what is the normal jsfunit way of handling it ?
[20:03:10] <jose_freitas> Hmm, good question
[20:03:55] <jose_freitas> I started using jsfunit after arquillian
[20:03:56] <jose_freitas> hehehe
[20:04:03] <jose_freitas> lemme check
[20:04:13] <aslak> :)
[20:15:19] <jose_freitas> aslak: it's not clear how it handle that. all those dependencies are compile scoped
[20:17:04] <jose_freitas> btw: if you want to see the error
[20:17:05] <jose_freitas> http://pastebin.com/AM8unRFj
[20:20:20] <ianbrandt> Hi aslak, Whenever you have a minute I'm working on a patch for ARQ-554, and want to discuss a possible change to the Container SPI.
[20:20:22] <jbossbot> jira [ARQ-554] Servlet creates invalid URIs for root context and default port [Open (Unresolved) Bug, Major, Ian Brandt] https://issues.jboss.org/browse/ARQ-554
[20:25:53] <aslak> ianbrandt, not quite following.. when is port missing ? you adding null ?
[20:27:37] <ianbrandt> aslak, I'm really in it for the root context (ROOT.war in Tomcat) // issue, I just added the port bit for the sake of thoroughness.  ;)
[20:28:06] <aslak> hehe
[20:28:15] <aslak> yea, the root i see can be a issue
[20:29:33] *** ldimaggi has joined #jbosstesting
[20:29:48] <aslak> ianbrandt, any solution you want to discuss, or just fix or not ?
[20:29:49] <aslak> :)
[20:30:52] <ianbrandt> In my debugging I noticed Tomcat's standardContext.findServletMappings() returned the JSP servlet twice for some reason.  Ignoring why and whether or not it should, it seems to make sense that org.jboss.arquillian.container.spi.client.protocol.metadata.HTTPContext keep a Set of org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet instead of a List.  That implies Servlet should have a proper equals method, an
[20:30:52] <ianbrandt> then that it's identifying fields be blank finals.  However HTTPContext back sets itself as the parent of Servlet on add(...) to initialize the host and port.  I'd like to decouple HTTPContext from Servlet, where the host and port are passed into the Servlet constructor, and hence all can be blank final.  This would break every container however being an SPI change.  So what better time than before 1.0.0.Final, but granted
[20:30:52] <ianbrandt> is a minor issue, so I wanted to get your approval first.
[20:32:37] *** lightguard_jp has joined #jbosstesting
[20:32:45] <aslak> ianbrandt, to late for breaking spi changes
[20:33:35] <ianbrandt> aslak, understood.
[20:33:51] *** bdlink has quit IRC
[20:33:55] <aslak> ianbrandt, but, changing to Set internally is ok, and fixing up the hash/equals and url creation parts
[20:36:19] <aslak> :)
[20:37:00] <ianbrandt> aslak, Can do.  I guess I'll just include the host and port as identifying fields with a comment to watch out that they're not final.
[20:37:58] <aslak> ianbrandt, add if == null throw IllegalArgumentException in the constructors
[20:38:57] <ianbrandt> aslak, ah yes, will do.
[20:44:32] <aslak> jose_freitas, with jsfunit normal it's up to the user to handle this..  http://www.jboss.org/jsfunit/gettingstarted.html
[20:45:11] <aslak> "Package these jars.."  the last part there.. don't include xercesImpl etc on jboss servers.. guess that goes for tomcat as well
[20:48:40] <jose_freitas> If not already included in your container, you will also need xerces and xalan.
[20:48:46] <jose_freitas> tomcat don't include them
[20:48:57] <aslak> but it still fails ?
[20:49:17] <ianbrandt> aslak, What's you're take on "assert" or "if condition throw Exception" or similar for Arq runtime implementation (as opposed to JUnit assertX(...) at test time)?
[20:50:15] <aslak> ianbrandt, ?
[20:50:19] <ianbrandt> (..."RuntimeException" I meant)
[20:51:16] <aslak> not following
[20:51:20] <ianbrandt> aslak, I.e. do you want see the Java "assert" keyword used?  Are assertions enabled for CloudBees builds?
[20:52:24] <aslak> ianbrandt, aa you mean to use assert keyword in the constructor args instead of if ?
[20:52:48] <aslak> or in the test cases
[20:53:34] <ianbrandt> aslak, Right, or anywhere, but I mean runtime code, not test cases.  Just wondering what the Arq coding convention is in this regard.
[20:53:46] <aslak> ianbrandt, aa right.. if
[20:54:05] <ianbrandt> aslak, got it, thanks.
[20:54:49] <aslak> ianbrandt, prefer IAE thrown at runtime without any special things added, instead of Nullpointer unless running in ea
[20:55:42] <ianbrandt> aslak, "ea"?
[20:56:23] <ianbrandt> ah
[20:58:54] <jose_freitas> aslak: so, following up jsfunit issue. tomcat don't bundle those jars (xerces and xalan). didn't understand your question on: "but it still fails", you mean jboss5 without those jars?
[20:59:16] <aslak> jose_freitas, the error was from tomcat wasn't it ?
[20:59:27] <jose_freitas> no, the error is in jboss51
[20:59:34] <jose_freitas> tomcat is working with those jars
[20:59:39] <aslak> aa ic
[20:59:41] <jose_freitas> with a 7.9M though
[20:59:47] <jose_freitas> with jboss6 there's no problem
[20:59:54] <jose_freitas> and with jboss51 there's a conflict
[21:00:12] <jose_freitas> removing those classes from the package it works with jboss51
[21:00:12] <aslak> jose_freitas, 7 works ?
[21:00:24] <jose_freitas> tomcat 6.
[21:00:32] <aslak> as 7 i mean
[21:00:56] <jose_freitas> didn't try yet, I'd like to finish with jboss51 first.
[21:00:57] <aslak> jose_freitas, oh yea. as 7.0.1 was released yesterday.. so the servlet protocol stuff should be fixed
[21:01:05] <jose_freitas> nice
[21:01:07] <jose_freitas> :)
[21:02:26] <jose_freitas> yesterday? I thought you mentioned that servlet protocol stuff some days ago.
[21:02:56] *** mgoldmann has quit IRC
[21:03:02] <aslak> jose_freitas, mentioned / pushed upstream sure.. but now released
[21:03:08] <jose_freitas> good
[21:03:12] <jose_freitas> :)
[21:03:29] <jose_freitas> thanks
[21:04:47] *** pil-dinner is now known as pilhuhn
[21:05:43] <jose_freitas> so, what if we instruct our users to add those dependencies themselves (as jsfunit alone does)? or we could bundle them with tomcat-arq-container?
[21:06:43] <jose_freitas> hm, second option wouldn't work with remote container
[21:08:26] <jose_freitas> we could make an extension in tomcat-arq-container that could trigger an archiveappender.
[21:14:29] <aslak> jose_freitas, yea, that's a option
[21:14:47] <aslak> if removing them, which will it work for ?
[21:15:23] <ianbrandt> aslak, Ahh, ha, I just noticed HTTPContext.port is an int not a String, so non-optional.  I'll amend the JIRA.  Though this means a container couldn't use the default port.  I guess no one is banging down the door on that one, or https:// either. ;)
[21:16:38] <jose_freitas> removing them work for jbosses. not sure if it works for jetty. let me try.
[21:17:41] *** nilian has joined #jbosstesting
[21:21:14] <aslak> ianbrandt, amend the jira? the contextRoot is still open for creating the wrong uri right ?
[21:22:25] *** jamezp is now known as jamezp_afk
[21:22:52] <aslak> ianbrandt, been wondering about https, but for now it's unsupported.. :)
[21:26:27] <ianbrandt> aslak, correct, I'm still fixing contextRoot.
[21:28:56] <ianbrandt> aslak, jose_freitas, Am I catching your conversation correctly that you're discussing dependencies to be included in container POMs?  I've been meaning to ask... The Tomcat embedded containers currently specify the Tomcat dependencies as <scope>provided</scope>.  The upside is user's can "bring their own container" version so long as it's binary compatible with the embedding.  But the downside is users that don't care abou
[21:28:56] <ianbrandt> version have to reference documentation or the container's POM and then specify all the right dependencies anyway.  The bring your own version can still be accomplished via <exclusions />.  Is provided really the way to go?
[21:30:09] <ianbrandt> (I notice Jetty is provided scoped as well.)
[21:30:23] <aslak> ianbrandt, there is another level here that we're not finished with yet, the Container-Boms, which will be the i don't care pull in what you need
[21:31:06] <ianbrandt> aslak, Ah, okay, best of both.
[21:32:23] <aslak> ianbrandt, we have them in the arq-showcase, but not pushed them to the containers.. https://github.com/arquillian/arquillian-showcase/tree/master/container-boms
[21:33:46] <aslak> i think we have 3 angels, "just the container adaptor", "container adaptor + other ar modules(enrichers,protocols) (what we have today)" and "container adaptor + container + what ever is needed to get a quick start"
[21:34:00] <aslak> the problem is just Maven makes it so hard to make Maven stuff.. hehe
[21:34:25] <ianbrandt> aslak, Haha, yep.
[21:35:02] <aslak> a lot easier in gradle
[21:37:09] <aslak> could use classifiers on the pom or similar. arquillian-tomcat-embedded:quickstart|stripped|normal or some more sensable names
[21:41:28] *** ALR has quit IRC
[21:42:19] *** ALR has joined #jbosstesting
[21:42:55] <ianbrandt> aslak, I had some exposure to gradle several months back when debugging a Hibernate issue.  It definitely looks interesting, but at the time I don't believe there was any Eclipse WTP integration.  I rely on WTP hot deploy a fair bit.
[21:44:21] <jose_freitas> aslak: jetty don't need to patch them
[21:45:17] <aslak> jose_freitas, jetty runs without the xml libs? so only tomcat ?
[21:45:22] <jose_freitas> yeah
[21:45:30] <aslak> jose_freitas, what about gf?
[21:45:32] <jose_freitas> well, we're not testing glassfish
[21:45:38] <aslak> :)
[21:45:40] <jose_freitas> need to made a profile for it
[21:46:00] <jose_freitas> but I believe that gf won't have that problem
[21:46:24] <aslak> ianbrandt, yea, ide integration is a bit low. I haven't really tested the eclipse plugin, but i guess we're back to good old mvn eclipse:eclipse, but
[21:51:14] *** pilhuhn has quit IRC
[22:04:26] *** jeand_ has quit IRC
[22:10:20] *** jamezp_afk is now known as jamezp
[22:19:05] *** jeand_ has joined #jbosstesting
[22:28:27] <jose_freitas> ahn... cool! just saw that I can edit confluence documentation :)
[22:37:48] *** rbattenfeld has joined #jbosstesting
[22:52:45] <aslak> :)
[23:03:57] *** rbattenfeld has left #jbosstesting
[23:09:45] *** jose_freitas has quit IRC
[23:23:59] *** ldimaggi has quit IRC
[23:26:27] <ianbrandt> aslak, Should we resolve issues once a pull request is made, or leave that up to you?
[23:26:43] <ianbrandt> (...JIRA issues I mean.)
[23:28:47] <aslak> ianbrandt, you progress the workflow to "link pull request", then i resolve when upstream and close when released
[23:30:56] <ianbrandt> aslak, Got it.  Didn't see that button.  Done.  Thanks.
[23:31:19] <aslak> ianbrandt, thank you! :)
[23:35:51] <aslak> ALR, fun... https://gist.github.com/1155271
[23:35:56] <aslak> :)
[23:36:54] <aslak> ALR, does not run at all from IDE since it's missing the container deps, but.. additionalClasspathArtifact could in theory be replaced by a profile ref
[23:37:15] <ALR> aslak: Lookin
[23:37:46] <aslak> ALR, in short.. multiple surefire runs in one mvn test with different classpaths
[23:37:47] <ALR> Tomcat and Jetty Embedded!
[23:37:57] <ALR> Yeah, that's hott
[23:41:11] *** jeand_ has quit IRC
[23:43:15] <aslak> ALR, updated and added a v. how it would look using profiles
[23:43:29] * ALR updating EJB3 Examples to use AS7
[23:43:36] <ALR> (Comlpetely updating 'em)





top