[00:03:30] *** mhuniewicz has quit IRC
[00:08:22] *** pgmjsd has left #jbosstesting
[00:18:43] *** maeste has joined #jbosstesting
[00:26:44] *** maeste has quit IRC
[00:51:01] *** PeteRoyle has quit IRC
[00:52:25] *** maeste has joined #jbosstesting
[00:59:22] *** jamezp has quit IRC
[00:59:51] *** jamezp has joined #jbosstesting
[01:01:24] *** maeste has quit IRC
[01:13:48] *** maeste has joined #jbosstesting
[01:20:15] *** maeste has quit IRC
[01:23:40] *** mbg has quit IRC
[01:25:45] *** maeste has joined #jbosstesting
[01:47:10] *** lfryc has quit IRC
[01:51:16] *** bleathem has quit IRC
[01:51:20] *** maeste has quit IRC
[02:48:32] *** ianbrandt has quit IRC
[02:51:58] *** jamezp is now known as jamezp_afk
[03:00:30] *** rruss has quit IRC
[03:03:39] *** jgenoese has joined #jbosstesting
[03:05:07] <jgenoese> greetings to all; anyone know where I can find doc for setting up maven seam 3 embedded jboss as7 arquillian test config ?
[03:13:55] *** jamezp_afk is now known as jamezp
[04:49:44] *** jamezp is now known as jamezp_afk
[05:21:34] *** rruss has joined #jbosstesting
[05:29:38] *** ldimaggi has quit IRC
[06:05:56] *** maeste has joined #jbosstesting
[06:12:41] *** maeste has quit IRC
[06:15:38] *** bgeorges has joined #jbosstesting
[06:26:11] *** jgenoese has left #jbosstesting
[06:33:08] *** maeste has joined #jbosstesting
[07:22:03] *** mbg has joined #jbosstesting
[07:22:12] *** jamezp_afk is now known as jamezp
[07:31:17] *** maschmid has joined #jbosstesting
[07:40:21] *** timte has joined #jbosstesting
[07:54:42] *** mgoldmann has joined #jbosstesting
[08:04:18] *** oskutka has joined #jbosstesting
[08:31:36] *** jamezp is now known as jamezp_afl
[08:31:39] *** jamezp_afl is now known as jamezp_afk
[08:34:49] *** kpiwko has joined #jbosstesting
[08:41:30] *** rruss has quit IRC
[08:42:06] *** rruss has joined #jbosstesting
[08:52:14] *** kevinpollet has joined #jbosstesting
[09:10:24] *** ge0ffrey has joined #jbosstesting
[09:19:41] *** vnvarsete has joined #jbosstesting
[09:21:21] *** lightguard_jp has quit IRC
[09:26:20] <vnvarsete> aslak: Hi, I wasn't able to debug an embedded JBoss container, even with your description here http://community.jboss.org/message/627621#627621
[09:31:20] <aslak> vnvarsete, when you run in debug mode, does your debugger kick in when you have a break point inside the @Deployment ?
[09:33:10] <vnvarsete> aslak: let me try to put a breakpoint in the @deployment, haven't tested that:(
[09:36:37] *** mgoldmann has quit IRC
[09:36:58] *** mgoldmann has joined #jbosstesting
[09:37:50] <vnvarsete> aslak: No I didn't get into the @Deployment either. I get a stacktrace, see here: http://pastebin.com/MTG5Hsd7
[09:38:46] <aslak> vnvarsete, your maven configuration e..g arg line / env variables are not being used by eclipse.
[09:38:54] <aslak> missing JBOSS_HOME i nthis case
[09:40:15] <vnvarsete> aslak: Here is my argline: <argLine>-Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Djava.endorsed.dirs=${tt.user.jboss6.home}/lib/endorsed -Djboss.home=${tt.user.jboss6.home} -Djboss.boot.server.log.dir=${tt.user.jboss6.home}</argLine>
[09:40:42] <aslak> how are you running this in eclipse?
[09:41:18] <vnvarsete> aslak: right-click a test an select debug-as
[09:41:24] <aslak> right..
[09:41:36] <vnvarsete> aslak:...or wrong?:)
[09:41:38] <aslak> arqLine is what Maven uses, Eclipse does not
[09:41:56] <vnvarsete> aslak: so..what do I do:)
[09:42:01] <aslak> but Eclipse would need the same info, so yo uneed to configure the Run/Debug Launch configuration
[09:42:54] *** jeand has joined #jbosstesting
[09:46:49] <vnvarsete> aslak: You're my man:) I will update the discussion about the findings (settings JBOSS_HOME for _each test_  you want to debug in Eclipse)
[09:48:27] <aslak> yea, it's a bit painful having to set it for each, possible there are some 'global project' environments variables somewhere in eclipse but..
[09:53:02] <vnvarsete> aslak: Hmm, I went out of memory:) Not sure how hungry JBoss is, but I should probably give it more when testing..
[09:53:35] <aslak> :)
[10:05:10] *** jharting has joined #jbosstesting
[10:07:38] *** jharting has quit IRC
[10:09:47] *** jharting has joined #jbosstesting
[10:19:27] *** bgeorges has quit IRC
[10:36:27] *** jeand_ has joined #jbosstesting
[10:37:13] *** alesj has joined #jbosstesting
[10:40:36] *** jeand has quit IRC
[10:41:31] *** stuartdouglas has quit IRC
[10:41:50] *** stuartdouglas has joined #jbosstesting
[10:44:46] *** lfryc has joined #jbosstesting
[10:59:27] *** kevinpollet has quit IRC
[12:02:39] *** vnvarsete has left #jbosstesting
[12:17:12] *** tdiesler has joined #jbosstesting
[12:17:24] <tdiesler> aslak, ping
[12:18:57] <aslak> tdiesler, hey
[12:19:36] <tdiesler> aslak, using CR4 I see that the dependency on shrinkwrap is gone. Are clients now expected to define that explicitly?
[12:20:40] <aslak> tdiesler, dep on shrinkwrap resolver is gone from transitive dep yes, but it is defined in arquillian-bom
[12:21:32] <tdiesler> its probably documented somewhere - what arq deps are clients supposed to put in their pom?
[12:21:59] <aslak> tdiesler, https://gist.github.com/1154075
[12:22:06] <aslak> that's the new recommended setup
[12:22:33] <aslak> import arq-bom to define the arq-core version + shrinkwrap versions, that also forces maven to update the containers deps on arq core
[12:23:19] <aslak> if you want to use the shrinkwrap maven integration, you add a dep to org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-maven-impl
[12:23:51] <aslak> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven to be precise
[12:24:59] <tdiesler> this looks fishy, right? http://fpaste.org/Tgyq/
[12:26:14] <aslak> yea, you get a mix of CR3 and CR4 from Arq-core
[12:26:23] <aslak> this is where the Arq-Bom import comes in
[12:26:38] <aslak> the Container depends on Core X and expose them trasitivly
[12:26:44] <aslak> but the user wants to use Core Y
[12:27:01] <aslak> not all of Core is imported by using the junit-container dep
[12:27:06] <aslak> e.g. the Protocols
[12:27:32] <aslak> so default, maven will mix and match versions, unless it's defined by junt-container, it will get the version defined b ythe container
[12:27:45] <aslak> it has no idea it's 'the same' parent
[12:28:28] <aslak> so, import arq-bom, forces maven to use the versions of the  artifacts defined in the bom
[12:28:40] <tdiesler> The osgi container CR4 defines core CR3. This is not right, is it?
[12:29:09] <aslak> arq-bom expose all of Core + Shrinkwrap, so any dep the container has oin those will be 'upgraded' to the bom version
[12:29:45] <tdiesler> Could you perhaps fix that osgi container CR4?
[12:29:58] <aslak> it's not wrong
[12:30:14] <tdiesler> I think you missed the update to core CR4, no?
[12:30:25] <tdiesler> or the to use the bom as you say
[12:30:47] <aslak> they have their own release cycles..  but share artifacts.. being they are on different release cycles they will always depend on different versions
[12:31:15] *** alesj has quit IRC
[12:31:25] <aslak> but stable SPI / API should make it possible for the user to define the Arq Core v.(by import) and the Container just follows
[12:31:31] <tdiesler> sure, but osgi CR4 should not have been released without an update to core CR4, no?
[12:32:02] <aslak> tdiesler, there was no Core CR4 at the time
[12:32:13] <tdiesler> ah, ok
[12:33:13] *** ldimaggi has joined #jbosstesting
[12:35:52] <tdiesler> I added an exclusion of sw to the artifact that had a shorter path to it. that would be the right fix, would it?
[12:36:14] <tdiesler> At least that gives me the right sw version.
[12:37:04] <aslak> tdiesler, the resolver?
[12:37:24] <tdiesler> the resolver is still missing
[12:37:48] <aslak> the container expose sw right ? that's the one you excluded?
[12:38:30] <tdiesler> yes, I had a shorter path to it. so an old version was shadowing the dep of the container
[12:39:02] <tdiesler> maven prefers the short path, even if it is an older version
[12:39:08] <aslak> yea
[12:39:55] <aslak> you should be able to not have to do exclusions if you use the import option
[12:41:07] *** jhuska has joined #jbosstesting
[12:41:34] <kpiwko> aslak: I haven't read the whole discussion but it reminds me that arq-core CR4 is not compatible with CR5 in runtime
[12:42:34] <kpiwko> aslak: because of changed versions between shrinkwrap-descriptors-* (1.1.0-alpha-2 in CR4 vs. 1.1.0-beta-1 in CR5), which have different api
[12:43:11] <aslak> kpiwko, sure, descriptor is a special case
[12:43:26] <aslak> that was moved from unstable SPI to stable between CR4 and CR5
[12:43:55] <kpiwko> aslak: great to know
[12:44:42] <aslak> kpiwko, but non of the containers use Descriptors in their integration, so they _should_ not be effected
[12:45:18] <kpiwko> aslak: somehow not true for tomcat containers
[12:45:56] <aslak> kpiwko, test?
[12:46:28] <aslak> i mean, when running the tomcat container tests, or consuming the tomcat container ?
[12:46:41] <kpiwko> aslak: the latter
[12:47:00] <aslak> kpiwko, i would think the problem there is what we are discussing :)
[12:47:28] <kpiwko> aslak: Jura was trying to use tomcats CR2 (core CR5) with drone CR2 (core CR4) add it has brought different shrinkwrap-descriptors version together via arq-bom
[12:48:09] <aslak> core junit-container does not transitivly pull in e.g. the Servlet Protocol(which use the Descriptor SPI), but hte Tomcat Contianer does. so unless you import Arq-Bom, the Servlet Protocol and it's deps will be in what ever v. the Contianer has defined. which can conflict with what Core pulls in
[12:49:14] <kpiwko> aslak: that's exactly the workaround we used :)
[12:49:42] <aslak> kpiwko, it's not a workaround. it's _the_ wya
[12:49:44] <aslak> way
[12:49:44] <aslak> :)
[12:50:05] <kpiwko> aslak: well the solution would be to update drone to depend on cr5 as well
[12:50:30] <aslak> kpiwko, i don't agree..
[12:50:45] <aslak> kpiwko, yes it will fix it
[12:51:17] <aslak> but they have their own release cycles
[12:51:33] <kpiwko> aslak: correct
[12:52:01] <aslak> the are communicating with each other via stable SPIs..  but Maven does not know what Arq Core is
[12:52:37] <kpiwko> aslak: did I got right that from CR5 this should not happen at all since SPI is now stable?
[12:52:57] <aslak> to maven all deps are just single artifacts in some version, which is why it pulls in different versions of what we know should be the same
[12:53:14] <aslak> Arq-Bom in a sense forces Maven to see Arq Core as one version
[12:53:19] <kpiwko> aslak: I got that
[12:53:53] <aslak> kpiwko, it will still happen
[12:54:10] <aslak> kpiwko, it might not fail, but your still using a older version of some of the libs
[12:54:44] <aslak> https://gist.github.com/1154075
[12:54:57] <aslak> line 30-33
[12:55:23] <aslak> all of those would follow 'what ever the Container' was compiled against unless you do import
[12:55:24] <kpiwko> aslak: how do we ensure that new versions in arq-bom does not disable some functionality in an extension depending on an older arq-bom?
[12:55:46] <aslak> kpiwko, ?
[12:56:31] *** alesj has joined #jbosstesting
[12:56:43] <aslak> disable, how do you mean?
[12:57:03] <kpiwko> aslak: say I use some specific stuff of shrinkwrap-descriptors in 1.1.0-alpha-1 in my extension, however in newer bom there is 1.1.0-beta-2 and it does not have that specific stuff at all
[12:57:46] <aslak> we're not a modular classloader system
[12:58:06] <aslak> that will break at some point how ever you configure it
[12:58:32] <aslak> but that specific stuff should be defined by stable API/SPIs
[12:59:32] <kpiwko> aslak: ok
[12:59:35] <aslak> in your case, you are writing code against a API in Alpha stage, which is pr definition up for change at any point
[12:59:45] <kpiwko> aslak: correct, it's my fault :)
[13:00:44] <aslak> it's just the nature of development.. :)
[13:01:21] <kpiwko> actually, I'm using arq-bom in dependencyManagament for a long time so I haven't notice this problem yet
[13:01:58] <aslak> we have been finalizing 4-5 different apis/spis up to beta/final stage at the same time here, so we're bound to run into conflicts along the way.. but moving forward after 1.0 we can rely on some stabillity
[13:02:44] <kpiwko> and used this pattern in the blog entry as well, so drone users should not fall into that case neither :)
[13:03:04] <kpiwko> aslak: do you still plan to release arq final this or next week?
[13:06:33] <aslak> kpiwko, yea, wo're working on a new set of guides etc that also will display this as the pattern.
[13:06:42] <aslak> kpiwko, javaOne is the target
[13:07:57] <kpiwko> aslak: let me know if you want me to update some of the doc I've written
[13:08:34] <aslak> kpiwko, yea good point
[13:08:57] <aslak> we're working on a whole new set of guides for a new site
[13:09:13] <aslak> Drone should of course be a part of that as well
[13:11:43] <kpiwko> aslak: hope you keep confluence plugin on the new site
[13:12:10] <kpiwko> aslak: because its wiki syntax is so much better than any other thing I used to create a content
[13:12:27] <aslak> kpiwko, we'll make it ever better..:)I
[13:12:32] <aslak> even
[13:15:27] <aslak> kpiwko, speaking of Drone
[13:15:45] <kpiwko> aslak: shoot
[13:15:53] <aslak> kpiwko, i was wondering how we could make the MultiContainer showcase even more awesome
[13:16:19] <aslak> kpiwko, currently it _only_ runs 3 managed nodes and deploys etc etc
[13:16:26] <aslak> but you only see text scroll by
[13:17:28] <aslak> ppl were really impressed with seeing Selenium run from IDE so easly as it's done in the UI showcase
[13:17:33] <aslak> so hey.. why not combine them
[13:17:39] <aslak> :)
[13:18:10] <aslak> so question.. Drone starts up Selenium Server and inject the Driver
[13:18:26] <aslak> can that Driver be used for different URLs ?
[13:18:36] <kpiwko> aslak: it depends
[13:18:42] <aslak> (including host:ip)
[13:18:56] <kpiwko> aslak: generally, it can be used to do so, but there will be some warnings emitted
[13:19:11] <aslak> kpiwko, right, that was the cross scripting thinggy
[13:19:32] <kpiwko> aslak: the thing is it will emit the warning even if properly configured
[13:19:49] <kpiwko> aslak: maybe we should rather use FirefoxDriver or ChromeDriver in ui test, these should be safer
[13:20:02] <kpiwko> aslak: however, this way we cannot promote Ajocado
[13:20:03] <aslak> the Default ?
[13:20:10] <aslak> then
[13:20:31] <kpiwko> yep, it is the question which should be the default
[13:21:04] <kpiwko> actually, I don't know what is the penetration of DefaultSelenium/WebDrivers between testers
[13:21:58] <aslak> FireFoxDriver is WebDriver based right, selenium 2 ? so no selenium server and windows poping up ?
[13:23:48] <alesj> aslak: how is DeploymableContainer::deploye(Descriptor) meant to be used?
[13:24:39] <aslak> alesj, initially via @Deployment Descriptor
[13:25:19] <aslak> alesj, but it will probably be deprecated in the form it is in, the container support is leaking
[13:25:37] <aslak> it works with JBoss 5 and 6, but that's about it
[13:26:55] <aslak> alesj, the idea was, @Deployment Descriptor create() { return Descriptors.create(JMS.class).addQueue("myqueue")...; }
[13:27:55] *** rruss has quit IRC
[13:28:23] *** jeand_ has quit IRC
[13:28:24] <aslak> ee7 eg is talking about 'FINALLY' standarizing resource deployment/creation/descriptors, so jmx/datasources etc can be deployed along side the app
[13:28:33] <aslak> jmx/jms
[13:29:54] <kpiwko> aslak: only one window will pop up, that is Firefox window
[13:30:46] <aslak> kpiwko, can we mix them in the same test ?
[13:31:09] <aslak> kpiwko, @Test one(@ArquillianResource ChromeDriver)  @Test one(@ArquillianResource FireFoxDriver)
[13:31:10] <aslak> ?
[13:31:25] <aslak> second "one" should be "two"..  :)
[13:31:38] <kpiwko> aslak: you should be able to do so
[13:31:59] <kpiwko> aslak: I've tried mixing only with mock instance
[13:32:13] <aslak> then we have 3 servers and two browsers
[13:32:15] <aslak> :)
[13:32:16] <kpiwko> *mock instance
[13:32:25] <kpiwko> aslak: yep, that would be awesome
[13:32:35] <kpiwko> but do the app have a web UI?
[13:32:45] <aslak> not yet
[13:32:47] <aslak> :)
[13:33:09] <aslak> it has a Servlet that returns the current Cache count, but.. not much of a UI
[13:33:31] <kpiwko> three AS, firefox and chrome...that would be great!
[13:33:36] <aslak> figured it could return some html that shows which server it is on etc pluss the count
[13:33:54] <aslak> then the assertion is for the count, but it's being displayed in the browser more nicly..
[13:34:19] <kpiwko> aslak: I have to check it it is possible to slow down a webdriver based test
[13:34:43] <kpiwko> with selenium legacy, you can add a timeout between each command and check the progress
[13:35:12] <kpiwko> aslak: actually you can use breakpoints if it is running to fast :)
[13:36:31] <aslak> yea, that's what i was thinking.. :)
[13:44:20] *** jeand_ has joined #jbosstesting
[13:52:39] <kpiwko> aslak: had you time to look at MavenImporter?
[13:53:23] <kpiwko> aslak: I'm still wondering how to enable it in eclipse?
[13:53:32] <kpiwko> (no question mark...)
[13:55:45] <kpiwko> aslak: only thing I've found so far is to run Run As/Maven Build.../-set package phase && Run As/JUnit test
[13:56:43] <aslak> kpiwko, regs.getConfiguratorFor(type) == null ?
[13:57:04] <aslak> org.openqa.selenium.firefox.FirefoxDriver
[13:57:33] <aslak> kpiwko, only briefly..
[13:57:43] <aslak> kpiwko, only briefly look at MavenImporter.. :)
[14:01:23] <kpiwko> aslak: you mean there's no non null check?
[14:02:48] <aslak> kpiwko, no i get a nullpointer
[14:02:56] <aslak> public void callActive2(@Drone FirefoxDriver driver, @ArquillianResource URL baseURL) throws Exception
[14:03:04] <kpiwko> aslak: right
[14:03:16] <aslak> Null at org.jboss.arquillian.drone.impl.DroneTestEnricher.constructDrone(DroneTestEnricher.java:134)
[14:03:24] <kpiwko> you're missing drone-webdriver on claspath, right?
[14:03:54] <kpiwko> aslak: the problem is I'm checking for null in field enrichment but I forgot to do so for method enrichement
[14:04:29] <kpiwko> <artifactId>arquillian-drone-webdriver</artifactId> should be on cp if you want webdriver support
[14:04:38] <kpiwko> instead of arquillian-drone-selenium
[14:04:53] <aslak> aa
[14:04:57] <aslak> right
[14:05:13] <aslak> fix that for final ?
[14:05:20] <kpiwko> aslak: I'll create a jira to fix that NPE check
[14:05:37] <aslak> and add some message alla, could not find configuraiton for bla, make sure you classpath is ..
[14:07:44] <kpiwko> aslak: https://issues.jboss.org/browse/ARQ-610
[14:07:45] <jbossbot> jira [ARQ-610] Method enrichment does not check for a validity of driver [Open (Unresolved) Bug, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-610
[14:07:54] *** timte has quit IRC
[14:11:16] <aslak> kpiwko, things like The path to the chromedriver executable must be set by the webdriver.chrome.driver system property;
[14:11:24] <aslak> is that set via arq.xml, or ?
[14:11:48] <kpiwko> aslak: you should be able to set anything via arq.xml
[14:13:09] <kpiwko> https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-webdriver/src/test/resources/arquillian.xml
[14:15:17] <kpiwko> aslak: chrome is a beast, it requires two binaries
[14:15:34] <kpiwko> chromium (browser) and chromedriver (webdriver control binary)
[14:16:12] <kpiwko> btw, ajocado is know to work with chrome as well
[14:16:17] <kpiwko> *is known
[14:17:18] <aslak> cool.. success
[14:17:32] <aslak> except.. the browsers are kept open
[14:19:31] <kpiwko> aslak: from IDE or cmdline?
[14:19:37] <aslak> cmd
[14:19:44] <kpiwko> can you try from IDE?
[14:20:07] <kpiwko> if the behavior is the same...
[14:20:56] <aslak> same
[14:22:07] *** Jaikiran has joined #jbosstesting
[14:22:33] <kpiwko> aslak: hmm, I do remember https://issues.jboss.org/browse/ARQ-444
[14:22:34] <jbossbot> jira [ARQ-444] MethodContext is not correctly free'd [Open (Unresolved) Bug, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-444
[14:25:40] <aslak> DroneDeconstruct Object instance = context.get(parameterTypes[i], qualifier);
[14:25:43] <aslak> instance is null
[14:26:03] <aslak> the cache is empty
[14:30:24] <aslak> DroneContext context = methodContext.get().get(method); i snull
[14:30:59] <aslak> but i see them in the underlaying Map, but they are not resolved on get(Method)
[14:31:56] <aslak> no, sorry
[14:32:12] <aslak> the MethodContext finds a DroneContext, but the content is empty
[14:32:20] <aslak> DroneContext that is
[14:32:30] <aslak> bb in a bit
[14:37:04] *** jamezp_afk has quit IRC
[14:37:28] *** timte has joined #jbosstesting
[14:37:33] *** jamezp_afk has joined #jbosstesting
[15:12:26] *** tdiesler has quit IRC
[15:13:35] *** vtunka has joined #jbosstesting
[15:14:37] *** pilhuhn has joined #jbosstesting
[15:28:49] *** mbg has quit IRC
[15:31:13] *** rachmatowicz has joined #jbosstesting
[15:31:23] *** vtunka has quit IRC
[15:31:52] *** jeand_ has quit IRC
[15:32:45] *** jeand has joined #jbosstesting
[15:39:39] *** mgoldmann has quit IRC
[15:40:05] *** mgoldmann has joined #jbosstesting
[15:46:08] *** ALR has quit IRC
[15:46:17] *** ALR has joined #jbosstesting
[15:50:01] *** maeste has quit IRC
[15:59:19] *** aLBa^ has joined #jbosstesting
[16:01:01] <aLBa^> Hi, im creating an implementation of an arquillian container for weblogic-remote, I succeeded in deploying and am not at the part were I need to supply a ProtocolMetaData. What am I supposed to put into this?
[16:01:51] *** maeste has joined #jbosstesting
[16:02:06] <aLBa^> not = now
[16:02:18] <aslak> aLBa^, heya
[16:02:23] <aLBa^> hi
[16:02:58] <aslak> aLBa^, ProtocolMetaData should contain a HttpContext that contain Servlet's, which all contain data about the deployment
[16:03:46] <aslak> so in the basic form, what is the ip and port of the Servers HTTP interface, which ContextRoot did the application deploy to and which Servlets were deployed in that context
[16:04:36] <aslak> this is used by Arquillian ServletProtocol to dynamically figure out the URL to the TestRunner
[16:04:51] <aslak> and by the @ArquillianResource URL injection, for injecting URLs to the deployed application
[16:05:20] <aLBa^> so arquillian includes a servlet in the deployment?
[16:05:31] <aslak> aLBa^, it might
[16:05:41] <aslak> :)
[16:05:59] <aLBa^> at this stage im only interested in ejb jars, but I notice it deploying a war?
[16:06:38] <aLBa^> so I should be fine without specifying servlets into the metadata or .. ?
[16:06:43] <aslak> for incontainer testing, Arquillian use a SPI called Protocol. It's up to the Protocol to prepare the deployment somehow so Arquillian can call the deployed test. one of the implementations is Servlet 3.0, which bundles a web-fragment along side the defined @Deployment
[16:07:34] <aslak> aLBa^, that's the Servlet Protocol at work, to bundle a Servlet with your deployment, it needs to be a War involved somewhere..
[16:08:32] <aLBa^> it gets that info from 'public ProtocolDescription getDefaultProtocol()' ?
[16:09:11] <aslak> aLBa^, that defines the Type of Protocol that is default for this container, the one that will be used if not specified by the user
[16:10:05] <aslak> kpiwko, ha! found the issue.. :)
[16:10:07] <aslak> kpiwko, https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/MethodContext.java#L51
[16:10:31] <aslak> it should be: DroneContext dc = cache.putIfAbsent(key, newContext);
[16:11:20] <aLBa^> what if the container doesn't yet support servlet 3.0?
[16:11:27] <aslak> as is, it's placing the Driver instance in a different context instance then the one cached
[16:11:34] <kpiwko> aslak: isn't that an overkill? what about TestContext?
[16:11:36] <aslak> aLBa^, then we have Servlet 2.5
[16:11:37] <aslak> :)
[16:11:59] *** pgmjsd has joined #jbosstesting
[16:12:16] <aslak> kpiwko, overkill?
[16:12:21] <kpiwko> aslak: I guess it wasn't present before, so I'm using ClassContext and method key in hashmap
[16:12:23] <aLBa^> ok, guess I'll scan my deployment for servlets then
[16:13:04] <aslak> aLBa^, a 'proper' impl should query with the servers management api
[16:13:11] <aslak> with/the
[16:13:21] <aslak> only the server knows where it really ended up
[16:14:49] *** rachmatowicz_ has joined #jbosstesting
[16:15:53] <aLBa^> yes, Ive seen the jboss and glassfish implementations, but I dont really see a similar api in weblogic
[16:16:58] <aLBa^> I'll work it out eventually
[16:17:11] <aslak> kpiwko, in Before is creates a new DroneContext for this Method, the MethodContext stores Instance X and returns Instance Y. The Driver is added to DroneContext Y. in After, the DroneContext for this method is retrived, but the stored context is Instance X which is empty(the correct one is Instance Y)
[16:17:46] *** rruss has joined #jbosstesting
[16:18:09] *** rruss has quit IRC
[16:18:31] <aslak> create DroneContext X, return Y: https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneTestEnricher.java#L132
[16:19:05] <kpiwko> aslak: I got that, but my question is if this can be simplified by using TestContext object instead of these ConcurrentHashMap thingy
[16:19:08] <aslak> https://github.com/arquillian/arquillian-extension-drone/blob/master/drone-impl/src/main/java/org/jboss/arquillian/drone/impl/DroneDestructor.java#L104
[16:19:23] <aslak> ohh, that's what you ment
[16:19:50] <kpiwko> that is observe Before, create method instance in TestContext, inject in TestEnricher, destroy in After method retrieved from TestContext
[16:20:09] <aslak> yea
[16:20:36] <aslak> we didn't do that earlier, because we had to work around when the context was created/destoryed right?
[16:20:58] <aslak> since it all once big Extension, and you where loaded after and had no way of sneaking in between?
[16:21:04] <aslak> was there any other reason?
[16:21:26] <aslak> once/was
[16:21:46] <aslak> my head and fingers are not in the same place today..
[16:23:09] <aslak> previously Arq Core was one Extension and it controlled the order of Context creation on the same level as @Observes Before|After. This ment Drone had no way of sneaking in a Observer between some of Cores observers
[16:23:38] <kpiwko> aslak: I got that fixed with JUnit test using TestContext
[16:23:53] <aslak> now on the other hand, Context Creation is done AroundInvoke of the Event, so this should now be possible. unless we had some other reasons for doing it as well
[16:24:13] <kpiwko> aslak: I haven't activated DroneCreator and I was wondering why no instance was created :)
[16:26:37] <aslak> kpiwko, you can even do: destroyMethodScopedDrone(@Observes After event, MethodContext context)
[16:26:59] <aslak> inject the MethodContext directly into the Observer method.
[16:27:25] <aslak> kpiwko, it then functions like a filter as well, so if no MethodContext found in active context, the Observer is not invoked
[16:28:11] <kpiwko> aslak: seems neat, I'll modify the code to use it
[16:32:54] *** maschmid has quit IRC
[16:40:27] *** timte has quit IRC
[16:52:07] <kpiwko> aslak: can you try to build https://github.com/kpiwko/arquillian-extension-drone/tree/ARQ-610 and validate that browsers are now closing correctly?
[16:52:07] <jbossbot> jira [ARQ-610] Method enrichment does not check for a validity of driver [Open (Unresolved) Bug, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-610
[16:52:31] <kpiwko> branch contains fixes for ARQ-444, ARQ-577 and ARQ-610
[16:52:32] <jbossbot> jira [ARQ-444] MethodContext is not correctly free'd [Open (Unresolved) Bug, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-444
[16:52:33] <jbossbot> jira [ARQ-577] Enhance exception messages for cases where Drone instances cannot be destroyed because no context was created [Open (Unresolved) Enhancement, Minor, Unassigned] https://issues.jboss.org/browse/ARQ-577
[16:52:34] <jbossbot> jira [ARQ-610] Method enrichment does not check for a validity of driver [Open (Unresolved) Bug, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-610
[16:52:54] <aslak> kpiwko, sure, 2 sec
[16:53:12] *** oskutka has quit IRC
[16:53:57] <kpiwko> there's an unit test, to check instances are free'd so it should work, but just to be sure :)
[16:54:31] *** jharting has quit IRC
[16:57:53] <aslak> kpiwko, yea, works
[16:58:01] <aslak> kpiwko, now i hvae to find a way to keep them open.. heh
[16:58:09] <kpiwko> aslak: :D
[17:00:11] *** bleathem has joined #jbosstesting
[17:01:17] *** aLBa^ has quit IRC
[17:03:51] *** rachmatowicz_ has quit IRC
[17:04:11] *** rachmatowicz has quit IRC
[17:12:02] *** jose_freitas_aw has joined #jbosstesting
[17:13:13] *** jose_freitas has quit IRC
[17:13:20] *** rachmatowicz has joined #jbosstesting
[17:13:35] *** jose_freitas has joined #jbosstesting
[17:15:48] <kpiwko> aslak: btw, you already did that openshift video?
[17:16:41] *** jose_freitas_aw has quit IRC
[17:21:19] <aslak> kpiwko, yes and no.. it's not done yet
[17:21:21] *** rruss has joined #jbosstesting
[17:21:33] *** jamezp_afk is now known as jamezp
[17:22:03] <aslak> kpiwko, bought a new mic to get decent sound, but it broke.. heeh
[17:22:25] <aslak> kpiwko, video is done, just need the voice over. and been to busy last weeks to get it done..
[17:32:20] *** maeste has quit IRC
[17:36:25] *** ldimaggi has quit IRC
[17:40:07] *** jhuska has quit IRC
[17:43:05] <kpiwko> aslak: hehe...what sw/tools have you used?
[17:43:33] <aslak> OpenShot
[17:43:58] <aslak> and used recorddesktop i believe for the recording it self
[17:44:02] <aslak> openshot for clipping etc
[17:45:29] <kpiwko> aslak: that would be a busy weekend, to get all these tools working :)
[17:46:41] *** maeste has joined #jbosstesting
[17:48:09] *** jamezp has quit IRC
[17:48:46] *** jamezp has joined #jbosstesting
[17:56:15] *** maeste has quit IRC
[17:56:22] *** jose_freitas has quit IRC
[18:02:44] *** maeste has joined #jbosstesting
[18:06:19] *** mbg has joined #jbosstesting
[18:07:55] <aslak> kpiwko, http://pastebin.com/vaQanmFQ
[18:08:12] <aslak> kpiwko, if Drone is one cp but not used in this Class
[18:08:47] <ALR> aslak: How can I get at the DeployableContainer via a TestEnricher?
[18:09:02] <ALR> Tell me I can inject it :)
[18:09:22] <aslak> kpiwko, you can do the same there as well,  destroyClassScopedDrone(@Observes AfterClass event, DroneContext context).. filter it so it's only called if created
[18:09:51] <kpiwko> aslak: ok
[18:09:58] <aslak> ALR, @Inject Instance<Container> container; container.get().getDeployableContainer()
[18:10:12] <aslak> ALR, thats on client side
[18:10:19] <aslak> ALR, in container there is no DeployableContainer
[18:10:35] <ALR> aslak: Hmm, that's an issue.  OK, thanks.
[18:10:46] <aslak> ALR, what are you trying to do ?
[18:11:08] <ALR> aslak:  AS7-1337
[18:11:10] <jbossbot> jira [AS7-1337] Expose Management API for tests [Open (Unresolved) Feature Request, Critical, Andrew Rubinger] https://issues.jboss.org/browse/AS7-1337
[18:11:10] <aslak> ALR, lazy deploy the service ?
[18:11:14] <aslak> aa
[18:11:31] <ALR> aslak: No, that lazy deploy of the ARQ service isn't what we though.
[18:11:34] <ALR> *thought
[18:11:45] <ALR> OSGi is getting init'd before that
[18:11:51] <ALR> So I need to look into what's triggering it.
[18:11:56] <aslak> aa ok
[18:12:08] <ALR> But it's not the registration we do in the FrameworkServiceProcessor or whatever
[18:12:22] <aslak> manifest then i guess
[18:12:28] <kpiwko> aslak: method param injection works with InstanceProducer as well, correct?
[18:12:42] <ALR> aslak: Now I just need to get at the ModelControllerClient in AS7 for kpiwko\
[18:12:47] <ALR> To inject it
[18:13:24] <kpiwko> aslak: thinking about it I would say it won't work...how I would I pass created instance?
[18:13:27] <aslak> ALR, use @Inject @ContainerScoped InstanceProducer<ModelcontrollerClient> client; client.set(mgmgclient) in the container
[18:13:56] <ALR> aslak: That'll work in the container?
[18:14:02] <ALR> @ContainerScoped does that?
[18:14:16] <aslak> and create a Extension that has a Observer that listens to beforeSuite or similar that does the same but fetches it from the Service somehow
[18:14:30] <aslak> for in container
[18:14:33] <ALR> Yeah, fetches from AS7
[18:14:36] <ALR> I'm figuring that now.
[18:14:43] *** ianbrandt has joined #jbosstesting
[18:15:38] <aslak> ALR, did similar for the OpenShift container
[18:15:45] <aslak> fetching the ModelClient that is in container
[18:15:45] <aslak> https://github.com/arquillian/arquillian-container-openshift/blob/master/openshift-express/src/main/java/org/jboss/arquillian/container/openshift/express/ping/OpenShiftService.java
[18:16:02] <ALR> Superdooper
[18:17:28] <aslak> kpiwko, not sure what you mean?
[18:18:37] <aslak> kpiwko, oh, you mean when you are going to produce it.. no correct, that won't work
[18:18:40] <aslak> it's only on read
[18:19:06] <aslak> kpiwko, so you can do it on the cleanup methods, but not on the create
[18:20:40] <kpiwko> aslak: that's what I tought
[18:20:56] <aslak> kpiwko, could of course have added support for using the Instance/InstanceProducer wrapper there as well. in that case they would work as optional injections
[18:21:43] <aslak> do(@Observes Before, Type mustExist, Instance<Type2> optional, @ClassScoped InstanceProducer<Type3>)
[18:26:52] *** pilhuhn has quit IRC
[18:37:42] <kpiwko> aslak: fixed and included junit test, https://github.com/kpiwko/arquillian-extension-drone/commit/95a42dcba356d77a56d74da08b1fe5012f883132
[18:37:42] <jbossbot> git [arquillian-extension-drone] 95a42dc.. Karel Piwko ARQ-444 Fixed descructor behavior + improved test coverage for Destructors
[18:37:43] <jbossbot> jira [ARQ-444] MethodContext is not correctly free'd [Resolved (Done) Bug, Major, Karel Piwko] https://issues.jboss.org/browse/ARQ-444
[18:38:06] <kpiwko> aslak: you already resolved these jiras? wow...
[18:39:22] <kpiwko> aslak: and even it is upstream...k, I'll create new jira and push request
[18:40:28] *** alesj has quit IRC
[18:46:09] <kpiwko> aslak: ok, fixed here https://github.com/arquillian/arquillian-extension-drone/pull/10
[18:48:41] *** dblevins has quit IRC
[18:55:18] <kpiwko> aslak: tested and pushed upstream
[18:59:29] *** pilhuhn has joined #jbosstesting
[18:59:29] *** pilhuhn has joined #jbosstesting
[18:59:37] *** kpiwko has quit IRC
[18:59:50] *** maeste has quit IRC
[19:00:23] *** maeste has joined #jbosstesting
[19:04:10] *** mgoldmann has quit IRC
[19:06:11] *** Jaikiran has quit IRC
[19:10:58] *** jamezp has quit IRC
[19:11:21] *** jamezp has joined #jbosstesting
[19:12:11] *** ldimaggi has joined #jbosstesting
[19:13:08] <aslak> ALR, lol.. is the proper response to Miller: Look it up in the Calendar ? ;)
[19:13:15] *** pilhuhn has quit IRC
[19:18:04] <ALR> Hehe
[19:18:25] <ALR> Is he asking me if October is soon
[19:18:25] <ALR> ?
[19:18:27] <ALR> aslak: ^
[19:23:58] *** jose_freitas has joined #jbosstesting
[19:24:41] <aslak> ALR, that seems to be the case
[19:25:05] <jose_freitas> good afternoon guys
[19:25:09] <aslak> jose_freitas, heya
[19:26:35] <ALR> jose_freitas: Yo
[19:33:27] *** jose_freitas_aw has joined #jbosstesting
[19:34:39] *** jose_freitas_aw is now known as jose_freitas_
[19:35:13] *** jose_freitas has quit IRC
[19:40:09] *** jose_freitas has joined #jbosstesting
[19:42:18] *** jose_freitas_ has quit IRC
[19:49:12] *** jose_freitas_ has joined #jbosstesting
[19:49:14] *** jose_freitas has quit IRC
[19:50:20] *** jose_freitas has joined #jbosstesting
[19:52:31] *** lightguard_jp has joined #jbosstesting
[19:53:58] *** jose_freitas_ has quit IRC
[20:05:45] *** jose_freitas_ has joined #jbosstesting
[20:08:05] *** jose_freitas has quit IRC
[20:20:38] *** lfryc has quit IRC
[20:39:23] *** ALR has quit IRC
[20:51:34] *** dblevins has joined #jbosstesting
[20:55:01] *** jamezp has quit IRC
[20:55:29] *** jamezp has joined #jbosstesting
[21:12:12] *** ge0ffrey has quit IRC
[21:21:42] *** jamezp is now known as jamezp_afk
[21:34:30] *** ALR has joined #jbosstesting
[21:37:35] *** mbg has quit IRC
[21:41:06] *** michalhuniewicz has joined #jbosstesting
[21:41:11] <michalhuniewicz> aslak, hi
[21:56:54] *** jeand has quit IRC
[22:05:09] *** jamezp_afk is now known as jamezp
[22:28:47] *** pgmjsd has quit IRC
[22:42:17] *** bobmcw has quit IRC
[23:13:59] *** ldimaggi has quit IRC
[23:15:40] *** michalhuniewicz has left #jbosstesting
[23:27:08] *** bobmcw has joined #jbosstesting





top