March 29, 2011 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 29, 2011 NOTICE: This channel is no longer actively logged.
[00:00:05] <opalka> dmlloyd, any stack trace?[00:00:15] <opalka> dmlloyd, it works for me (locally)[00:00:44] <jbossbot> git [jboss-as] push master a0f647b.. Richard Opalka refactoring + fixing bug in params processing method (if all 'export', 'services' & 'optional' were specified on manifest dependency, the last one in the param list have been improperly evaluated)[00:00:44] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/3640b21...a0f647b[00:01:47] *** sannegrinovero has joined #jboss-as7[00:01:47] *** sannegrinovero has quit IRC[00:01:48] *** sannegrinovero has joined #jboss-as7[00:01:48] *** ChanServ sets mode: +v sannegrinovero[00:02:01] <opalka> dmlloyd, bstansberry whoever pushed upstream, thanks[00:02:14] <bstansberry> your welcome[00:02:20] <bstansberry> you're[00:02:38] <dmlloyd> it's just hanging, opalka[00:02:55] <dmlloyd> oh[00:03:01] <dmlloyd> I still have my other AS instance running[00:03:01] <opalka> dmlloyd, listening ...[00:03:03] * dmlloyd sigh[00:03:12] <opalka> dmlloyd, that explains it[00:03:18] * opalka hopes so[00:03:28] <dmlloyd> I was wondering why my mem usage was so high[00:06:20] *** alesj has joined #jboss-as7[00:07:43] <dmlloyd> much better[00:08:01] <jbossbot> git [jboss-as] push master cbef46c.. John E. Bailey [JBAS-9168] - Add additional TXN services for RecoveryManager and UserTransactionRegistry[00:08:03] <jbossbot> jira [JBAS-9168] ArjunaTransactionManagerService should be splitted [Open (Unresolved) Task, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9168[00:08:03] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/a0f647b...cbef46c[00:09:56] *** aslak has quit IRC[00:13:20] *** rawbdor has quit IRC[00:19:04] <jamezp> Nihility: Did you see this earlier by chance? I think I have it correct now. https://github.com/jamezp/jboss-as/commit/d95de94a164c26acff5e4177e2b6090bbdc33219[00:19:05] <jbossbot> git [jboss-as] d95de94.. James Perkins JBAS-8991 Added woodstox modules for JAXP processing. This allowed older JDK's to launch the server.[00:19:06] <jbossbot> jira [JBAS-8991] Cannot start beta1 server on RHEL6 with OpenJDK 1.6 [Open (Unresolved) Bug, Critical, James Perkins] https://issues.jboss.org/browse/JBAS-8991[00:23:39] <baileyje> dmlloyd: THanks,[00:28:01] *** opalka has quit IRC[00:28:06] *** emuckenhuber has quit IRC[00:30:10] *** rawbdor has joined #jboss-as7[00:30:10] *** ChanServ sets mode: +v rawbdor[00:36:23] *** rawbdor has quit IRC[00:44:39] *** jpearlin has joined #jboss-as7[01:31:20] *** alesj has quit IRC[01:37:46] *** rawbdor has joined #jboss-as7[01:37:46] *** ChanServ sets mode: +v rawbdor[01:39:36] *** sannegrinovero has quit IRC[02:31:43] *** pferraro has quit IRC[02:33:00] *** jamezp has left #jboss-as7[02:41:31] <stuartdouglas> dmlloyd: I had another go at env-entry support, would you be able to take a look: https://github.com/stuartwdouglas/jboss-as/commit/803990d135e7a1d0eabcb94b6561c306851697d3[02:41:32] <jbossbot> git [jboss-as] 803990d.. Stuart Douglas Inital env-entry and ejb-ref support[02:50:18] *** rawbdor has quit IRC[02:50:25] <jpearlin> Nihility: I finished creating the smoke test for the deployment upload via http, but I have some questions as to where it should go, when you have a minute[02:55:14] <Nihility> jpearlin: hi there[02:57:29] <Nihility> jpearlin: was your email referring to smoke tests[03:00:46] <jpearlin> yes[03:01:00] <jpearlin> so, what I have mimics the class I referenced[03:01:14] <jpearlin> but I am thinking it may just make sense to move it in with the other tests, that assume the server is running[03:01:41] <jpearlin> as opposed to starting it up for my test[03:03:23] <Nihility> i thinkn its find to keep it a separate class we might want to relocate it at some point[03:03:44] <jpearlin> ok...I'll work on getting it pushed up to my github account and get you a commit hash[03:03:52] <Nihility> cool thanks![03:04:22] <jpearlin> should I get some more tests in there for this (i.e. some of the bad cases) or should I start looking at the base64 stuff again[03:04:26] <jpearlin> to improve the test coverage[03:04:45] <jpearlin> we also need to address some of the TODO's in the deployment upload code in the http server at some point[03:05:41] *** fnasser has quit IRC[03:19:23] *** jwulf has quit IRC[03:26:09] <Nihility> jpearlin: since this is in smoke tests it should just be something basic[03:26:35] <jpearlin> Nihility: ok...I'll keep it as the happy path/upload test[03:26:50] <jpearlin> I did have some questions about the issue with the base64 stream[03:26:54] <jpearlin> issue, that is[03:27:43] <Nihility> ok[03:27:55] <jpearlin> Nihility: I assume that you discovered the issue with a stream with underflow (i.e. there was less than 3 bytes available, but you were not at the end of the stream yet)[03:28:12] <Nihility> it was at the end of the stream[03:28:17] <jpearlin> because if the total is not a multiple of 3, it is not an issue (because it pads the remaining bytes)[03:28:25] <jpearlin> so do you think there is an issue with the logic that pads?[03:28:40] <Nihility> the problem is when decoding, it always writes out a multiple of 3[03:28:41] <jpearlin> when there is less than a full block remaining[03:28:50] <Nihility> even if the the source file isnt a multiple of 3[03:28:50] <jpearlin> oh...on the decoding side[03:29:04] <jpearlin> got ya...okay...that should be easy to write some test cases for[03:29:09] <jpearlin> in the dmr project[03:29:24] <jpearlin> I'll get those banged out after getting the smoke test for the upload posted[03:29:37] <jpearlin> so that we can feel more confident about the base64 stuff[03:29:47] <Nihility> yeah i was thinking you can do a throw away kind of thing[03:30:02] <Nihility> where you do something like grab a bunch of files on the filesystem[03:30:08] <Nihility> encode them and decode them[03:30:12] <jpearlin> even easier...[03:30:18] <jpearlin> I could just grab classes as a resource[03:30:19] <Nihility> and compare the results with some other decoder/encoder[03:30:20] <jpearlin> from the class path[03:30:22] <jpearlin> yeah[03:30:42] <Nihility> i have done things like writen something to take a directory[03:30:49] <Nihility> and then let it go[03:30:53] <Nihility> lots of random data[03:30:54] <Nihility> :)[03:30:57] *** jwulf has joined #jboss-as7[03:31:02] <jpearlin> yeah...I could also generate some...[03:31:10] <jpearlin> but would we want to include some other base64 library in the tests[03:31:15] <jpearlin> as a baseline for comparison?[03:31:18] <Nihility> then you could try and make a crapy stream[03:31:34] <jpearlin> maybe that jboss one we started with? do we trust that one?[03:31:53] <Nihility> well i was using for example the perl one[03:32:07] <Nihility> but yeah as far as correctness on the java side[03:32:19] <jpearlin> I would like to make this part of the unit tests[03:32:21] <Nihility> you could use the old one, that would at least verify we are no worse than before[03:32:26] <jpearlin> and not rely on external data/apps[03:32:45] <jpearlin> because I don't want to assume that perl is installed, etc in the tests[03:32:54] <jpearlin> if you want me to just do that for verification on the side, I can do it[03:33:00] <Nihility> ah yeah thats why i mentioned throw away tests[03:33:20] <Nihility> but you could do something as a anormal test if you like to[03:33:23] <jpearlin> yeah...certainly start there to make sure things are good[03:33:32] <jpearlin> but what do you think for the actual unit tests...[03:33:32] <Nihility> the difference is that we usually dont want things like large file[03:33:34] <Nihility> s[03:33:45] <Nihility> etc in a testsuite[03:33:50] <jpearlin> yup[03:34:04] <jpearlin> ok...well, I can come up with something and let you decide ;)[03:34:12] <jpearlin> give you options[03:34:14] <Nihility> well for unit tests i would just test an unreliable stream[03:34:32] <Nihility> well no actually[03:34:39] <Nihility> we want tests to be deterministic[03:34:44] <jpearlin> yeah...[03:34:47] <jpearlin> I was just going to say that[03:34:50] <Nihility> so maybe a 2 byte stream or something like that[03:34:53] <jpearlin> you want to do something where you know the outcome[03:34:54] <jpearlin> yup[03:34:58] <jpearlin> otherwise, how do you assert[03:35:04] <jpearlin> with confidence[03:35:15] <jpearlin> the unreliable stream is really only good if it causes exceptions that you expect[03:35:23] <jpearlin> or at least a repeatable result[03:35:49] <jpearlin> so the last issue is the deployment upload code...[03:36:08] <jpearlin> there are currently some TODO's in there regarding how to return the result[03:36:18] <jpearlin> I believe it doesn't honor the base64 encoding request yet[03:36:23] <jpearlin> on the deploy file side[03:36:25] <Nihility> other than that you could just test a few sets of data of different sizes with the streams in both directions and so on[03:36:29] <jpearlin> it does honor it for other requests[03:36:32] <jpearlin> yeah[03:36:36] <jpearlin> ok...will do on the tests[03:36:55] <Nihility> we dont need a huge number of unit tests so dont feel you have to make an exhaustive suite or anything[03:37:09] <jpearlin> well...I'd like to make sure it works ;)[03:37:34] <jpearlin> especially considering you already found a fairly big issue with it[03:37:39] <jpearlin> that a unit test could have caught[03:37:51] <Nihility> i think stressing it with a bunch of files of different sizes and comparing to some other encoder would catch 99% of the issues[03:38:17] <jpearlin> Im more concerned about being able to make sure we have not regressed when someone else makes a change[03:38:24] <jpearlin> we can certainly test it on the side to make sure it is good[03:38:32] <jpearlin> and then put the tests in place to ensure it stays good[03:39:06] <Nihility> yeah thats fine just make sure that any unit tests are lightweight, but yeah using the jars contents is one way to cheat[03:39:11] <jpearlin> yup[03:39:28] <jpearlin> hopefully, the stress test will show us the scenarios[03:39:33] <jpearlin> then I can pre-can those in the unit tests[03:39:42] <jpearlin> i.e. this string generates a decoded string that causes an issue[03:39:47] <jpearlin> fix the issue, then use that string in the unit test[03:40:28] <Nihility> right its a good way to find things to look for[03:41:12] <jpearlin> ok...thanks for the help[03:45:05] *** jpearlin has left #jboss-as7[03:46:40] *** jamezp has joined #jboss-as7[03:51:39] *** rawbdor has joined #jboss-as7[03:55:08] <jbossbot> git [jboss-as] push master dcae2ab.. James Perkins JBAS-8991 Added woodstox modules for JAXP processing. This allowed older JDK's to launch the server.[03:55:09] <jbossbot> jira [JBAS-8991] Cannot start beta1 server on RHEL6 with OpenJDK 1.6 [Open (Unresolved) Bug, Critical, James Perkins] https://issues.jboss.org/browse/JBAS-8991[03:55:10] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/cbef46c...dcae2ab[03:55:15] <Nihility> jamezp: ^[03:55:30] <jamezp> Thank you! Do I close the JIRA now?[03:55:39] <Nihility> yes pleas[03:55:45] *** pgier has quit IRC[03:56:40] <jamezp> One more question do you prefer the "Resolve Issue"?[03:57:17] <Nihility> we dont do reporter closing[03:57:41] <Nihility> but if you resolve instead of close no big deal i fix them later[03:58:05] <jamezp> Okay. I'm still learning JIRA :-) We don't even use a bug tracker at my work.[03:58:20] <Nihility> doh[03:58:25] <Nihility> they are hard to leave without[03:58:30] <Nihility> live[03:58:53] <jamezp> Yeah. We use a crappy CRM kind of, but works on IE only and runs on domino.[04:02:33] *** JimMa has joined #jboss-as7[04:03:36] <Nihility> bstansberry: where do you think is a good spot to stick the shutdown operation i am going to write[04:03:45] <Nihility> on the "server" runtime node[04:03:46] <Nihility> ?[04:16:19] <bstansberry> this should only be on standalone[04:16:31] <bstansberry> so it would go on the root resource[04:16:51] <bstansberry> Nihility: ^^^[04:16:52] <Nihility> ok thats where i was putting it after i saw "reload" was there[04:17:14] <bstansberry> there's already ops for that on the host controller for domain mode[04:18:09] *** lgao has joined #jboss-as7[04:27:22] *** rawbdor has quit IRC[04:28:22] *** irooskov_ has joined #jboss-as7[04:28:30] *** irooskov_ has quit IRC[04:28:47] *** rawbdor has joined #jboss-as7[04:29:00] *** irooskov_ has joined #jboss-as7[04:29:27] *** irooskov_ has quit IRC[04:29:45] *** irooskov_ has joined #jboss-as7[04:30:35] *** irooskov_ has quit IRC[04:37:17] *** miclorb_ has quit IRC[04:49:49] *** miclorb has joined #jboss-as7[05:06:25] *** miclorb has quit IRC[05:06:25] *** stalep has quit IRC[05:06:28] *** jamezp has quit IRC[05:06:28] *** jhalliday has quit IRC[05:06:29] *** nickarls has quit IRC[05:06:31] *** lgao has quit IRC[05:06:32] *** bstansberry has quit IRC[05:06:32] *** baileyje has quit IRC[05:06:33] *** odin_ has quit IRC[05:06:36] *** rawbdor has quit IRC[05:06:37] *** jwulf has quit IRC[05:06:39] *** smarlow has quit IRC[05:06:42] *** ChanServ has quit IRC[05:06:42] *** irooskov has quit IRC[05:06:43] *** cs02rm0 has quit IRC[05:06:43] *** stuartdouglas has quit IRC[05:06:44] *** JimMa has quit IRC[05:06:44] *** ccrouch has quit IRC[05:06:44] *** Nihility has quit IRC[05:06:45] *** jbossbot has quit IRC[05:06:45] *** dmlloyd has quit IRC[05:06:46] *** bobmcw has quit IRC[05:18:02] *** ChanServ has joined #jboss-as7[05:18:02] *** smarlow has joined #jboss-as7[05:18:02] *** jwulf has joined #jboss-as7[05:18:02] *** rawbdor has joined #jboss-as7[05:18:02] *** pferraro has joined #jboss-as7[05:18:02] *** barjavel.freenode.net sets mode: +ovv ChanServ smarlow pferraro[05:18:22] *** lgao has joined #jboss-as7[05:18:22] *** bstansberry has joined #jboss-as7[05:18:22] *** baileyje has joined #jboss-as7[05:18:22] *** odin_ has joined #jboss-as7[05:18:22] *** barjavel.freenode.net sets mode: +vv bstansberry baileyje[05:18:33] *** JimMa has joined #jboss-as7[05:18:33] *** ccrouch has joined #jboss-as7[05:18:33] *** Nihility has joined #jboss-as7[05:18:33] *** jbossbot has joined #jboss-as7[05:18:33] *** dmlloyd has joined #jboss-as7[05:18:33] *** barjavel.freenode.net sets mode: +vvvv ccrouch Nihility jbossbot dmlloyd[05:18:44] *** irooskov has joined #jboss-as7[05:18:44] *** cs02rm0 has joined #jboss-as7[05:18:44] *** stuartdouglas has joined #jboss-as7[05:18:44] *** barjavel.freenode.net sets mode: +v stuartdouglas[05:19:51] *** stalep has joined #jboss-as7[05:20:03] *** miclorb has joined #jboss-as7[05:20:03] *** jamezp has joined #jboss-as7[05:20:03] *** jhalliday has joined #jboss-as7[05:20:03] *** nickarls has joined #jboss-as7[05:20:08] *** bobmcw has joined #jboss-as7[05:20:08] *** ChanServ sets mode: +v bobmcw[05:25:03] *** Nihility has quit IRC[05:26:17] *** Nihility has joined #jboss-as7[05:26:18] *** ChanServ sets mode: +v Nihility[05:28:12] *** pferraro has quit IRC[05:30:22] *** Nihility has quit IRC[05:39:07] *** miclorb has quit IRC[06:11:30] *** miclorb has joined #jboss-as7[06:25:47] *** maeste has joined #jboss-as7[06:25:47] *** ChanServ sets mode: +v maeste[06:34:52] *** smarlow has quit IRC[06:41:18] *** lgao has quit IRC[06:45:28] *** jamezp has quit IRC[07:03:34] *** bstansberry has quit IRC[07:34:48] *** miclorb has quit IRC[07:35:54] *** pferraro has joined #jboss-as7[07:35:54] *** ChanServ sets mode: +v pferraro[07:51:13] *** miclorb has joined #jboss-as7[08:14:06] *** pferraro has quit IRC[08:15:01] *** pil-dinner has joined #jboss-as7[08:21:37] *** jfclere has joined #jboss-as7[08:21:37] *** ChanServ sets mode: +v jfclere[08:23:29] *** pil-dinner has quit IRC[08:23:29] *** irooskov has quit IRC[08:24:34] *** rmaucher has joined #jboss-as7[08:24:42] *** rmaucher has left #jboss-as7[08:24:49] *** rmaucher has joined #jboss-as7[08:27:02] *** tdiesler has joined #jboss-as7[08:27:02] *** ChanServ sets mode: +v tdiesler[08:31:29] <jfclere> rmaucher: salut ?[08:32:26] *** rmaucher has left #jboss-as7[08:33:00] *** rmaucher has joined #jboss-as7[08:40:34] *** miclorb has quit IRC[08:42:58] *** mgoldmann has joined #jboss-as7[08:42:58] *** ChanServ sets mode: +v mgoldmann[08:53:19] *** rawbdor has quit IRC[08:56:30] *** adietisheim has joined #jboss-as7[09:05:31] *** opalka has joined #jboss-as7[09:05:31] *** ChanServ sets mode: +v opalka[09:06:39] *** jwulf has quit IRC[09:19:47] *** jwulf has joined #jboss-as7[09:24:04] *** torben has joined #jboss-as7[09:24:05] *** torben has joined #jboss-as7[09:24:05] *** ChanServ sets mode: +v torben[09:28:14] *** emuckenhuber has joined #jboss-as7[09:28:15] *** emuckenhuber has joined #jboss-as7[09:28:15] *** ChanServ sets mode: +v emuckenhuber[09:30:56] *** aslak has joined #jboss-as7[09:30:56] *** aslak has joined #jboss-as7[09:30:56] *** ChanServ sets mode: +v aslak[09:31:12] *** wolfc has joined #jboss-as7[09:31:13] *** ChanServ sets mode: +v wolfc[09:35:57] *** epbernard has joined #jboss-as7[09:35:57] *** epbernard is now known as emmanuel[09:35:57] *** ChanServ sets mode: +v emmanuel[09:40:04] *** Jaikiran has joined #jboss-as7[09:40:05] *** ChanServ sets mode: +v Jaikiran[09:48:01] <Jaikiran> wolfc: you around?[09:48:22] <wolfc> Jaikiran, I need to step out the door. I've just pushed another default-local-view.[09:48:31] <Jaikiran> wolfc: sure, np[09:48:44] <Jaikiran> my branch is stable enough and has code for merging ejb-jar.xml and annotations[09:48:59] <Jaikiran> i had asked dmlloyd to pull it upstream, but i think it might have to be done today[09:49:03] <wolfc> I picked that on top of default-local-view, but that branch is behind on upstream.[09:49:21] <Jaikiran> i'll bring in the latest from upstream now[09:49:38] <Jaikiran> let's sync when you are back[09:51:30] *** maximilienw has joined #jboss-as7[09:51:34] <wolfc> we need to have tests for @Remote and overrides. Those couple of lines in BVAP that determine the default local are wrong.[09:51:43] * wolfc is away[09:52:23] *** anguenot has joined #jboss-as7[09:55:03] *** lgao has joined #jboss-as7[10:05:20] *** maximilienw has left #jboss-as7[10:07:06] *** miclorb_ has joined #jboss-as7[10:09:48] *** slaboure has joined #jboss-as7[10:10:27] *** maxandersen has joined #jboss-as7[10:10:28] *** ChanServ sets mode: +v maxandersen[10:11:56] *** maxandersen has left #jboss-as7[10:15:00] *** aslak has quit IRC[10:15:48] *** aslak has joined #jboss-as7[10:15:49] *** ChanServ sets mode: +v aslak[10:31:10] *** pmuir has joined #jboss-as7[10:31:10] *** ChanServ sets mode: +v pmuir[10:32:24] * nickarls peeks in to see if there is any hat-eating to be expected in June ;-)[10:39:19] <wolfc> Jaikiran, I'm back[10:39:41] <wolfc> the main difference between our branches right now is @Remote processing. I got BVAP.[10:39:42] <Jaikiran> wolfc: i rebased with upstream and have pushed it to my remote branch[10:39:51] <Jaikiran> yep[10:39:57] <wolfc> I'll rebase so comparing is easier :-)[10:39:59] *** asoldano has joined #jboss-as7[10:39:59] *** ChanServ sets mode: +v asoldano[10:40:11] <Jaikiran> ok[10:40:49] <wolfc> we @Remote processing as temporary work-around for WS tests.[10:41:16] <Jaikiran> out of curiosity why does WS need @Remote?[10:41:27] <wolfc> TCK[10:41:54] <Jaikiran> i see. it doesn't test the @Remote semantics right?[10:42:22] <wolfc> Because the calls comes in via the WS Servlet it is more or less already pass-by-value[10:42:33] <Jaikiran> ok[10:43:05] <wolfc> hmm, why has this regressed...[10:43:37] <Jaikiran> looks like one of those Arquillian/module cl issues?[10:43:45] <Jaikiran> a CNFE for the testclass itself[10:44:51] <wolfc> the only commit which comes close to CL is https://github.com/jbossas/jboss-as/commit/a0f647bdd19ceec0aca70a50f71e2f52b1968fd6[10:44:52] <jbossbot> git [jboss-as] a0f647b.. Richard Opalka refactoring + fixing bug in params processing method (if all 'export', 'services' & 'optional' were specified on manifest dependency, the last one in the param list have been improperly evaluated)[10:46:10] <wolfc> I pushed a new default-local-view branch on top of upstream with all our commits in[10:50:41] <Jaikiran> wolfc: so we now want a testcase to prove that BVAP picks up a wrong default view, right?[10:51:12] <wolfc> Jaikiran, yes.[10:51:21] <Jaikiran> wolfc: ok. i'll start working on it now.[10:59:06] *** tdiesler has quit IRC[11:04:39] *** alesj has joined #jboss-as7[11:17:27] *** tdiesler has joined #jboss-as7[11:17:27] *** ChanServ sets mode: +v tdiesler[11:18:00] *** sannegrinovero has joined #jboss-as7[11:18:01] *** sannegrinovero has quit IRC[11:18:01] *** sannegrinovero has joined #jboss-as7[11:18:01] *** ChanServ sets mode: +v sannegrinovero[11:18:02] *** tdiesler has quit IRC[11:18:25] *** tdiesler has joined #jboss-as7[11:18:26] *** ChanServ sets mode: +v tdiesler[11:32:03] *** pil-dinner has joined #jboss-as7[11:40:44] *** pmuir has quit IRC[11:45:09] *** miclorb_ has quit IRC[11:56:30] *** pmuir has joined #jboss-as7[11:56:30] *** ChanServ sets mode: +v pmuir[12:06:08] *** aloubyansky has joined #jboss-as7[12:08:28] *** aslak has quit IRC[12:12:09] *** aslak has joined #jboss-as7[12:12:09] *** ChanServ sets mode: +v aslak[12:19:27] *** darranl has joined #jboss-as7[12:19:28] *** darranl has joined #jboss-as7[12:19:28] *** ChanServ sets mode: +v darranl[12:28:38] *** tdiesler has quit IRC[12:34:58] *** tdiesler has joined #jboss-as7[12:34:58] *** ChanServ sets mode: +v tdiesler[12:35:00] *** emmanuel has quit IRC[12:41:01] *** pil-dinner has quit IRC[12:43:13] <darranl> hi emuckenhuber - did Brian push all his changes from model-controller to master?[12:46:54] <emuckenhuber> darranl: afaik, not all of them[12:47:10] <darranl> emuckenhuber, ok thanks, will double check them[12:48:33] <darranl> emuckenhuber, yes it looks like this one isn't in https://github.com/bstansberry/jboss-as/commit/71b20c8eedc67e05826f61f1e58f07cb8bffef06 - just wanted to check he hadn't gone back to working on master[12:48:34] <jbossbot> git [jboss-as] 71b20c8.. bstansberry at jboss dot com Disentangle ModelController class hierarchy a bit[13:10:20] *** pferraro has joined #jboss-as7[13:10:20] *** ChanServ sets mode: +v pferraro[13:11:34] *** JimMa has quit IRC[13:14:44] *** pferraro has quit IRC[13:20:56] *** opalka has quit IRC[13:21:53] *** miclorb_ has joined #jboss-as7[13:22:08] *** asoldano is now known as asoldano_lunch[13:27:45] *** anguenot_ has joined #jboss-as7[13:30:30] *** anguenot has quit IRC[13:30:31] *** anguenot_ is now known as anguenot[13:35:03] *** sannegrinovero is now known as sanne[13:42:56] *** torben has quit IRC[13:44:35] *** torben has joined #jboss-as7[13:44:35] *** ChanServ sets mode: +v torben[13:54:24] *** miclorb_ has quit IRC[14:10:28] *** asoldano_lunch is now known as asoldano[14:16:20] *** pil-dinner has joined #jboss-as7[14:19:26] *** pil-dinner is now known as pilhuhn[14:19:26] *** pilhuhn has joined #jboss-as7[14:25:07] *** stansilvert has joined #jboss-as7[14:36:53] *** mbg has joined #jboss-as7[14:36:53] *** ChanServ sets mode: +v mbg[14:36:58] *** fnasser has joined #jboss-as7[14:39:12] *** mmoyses has joined #jboss-as7[14:39:12] *** ChanServ sets mode: +v mmoyses[14:42:44] *** bobmcw has quit IRC[14:44:58] *** bstansberry has joined #jboss-as7[14:44:58] *** ChanServ sets mode: +v bstansberry[14:46:21] *** Jaikiran has quit IRC[14:47:39] *** bobmcw has joined #jboss-as7[14:47:40] *** ChanServ sets mode: +v bobmcw[14:49:52] *** jpederse has joined #jboss-as7[14:50:03] *** jpederse has quit IRC[14:50:03] *** jpederse has joined #jboss-as7[14:58:20] *** fnasser has quit IRC[15:00:59] *** jwulf has quit IRC[15:02:06] *** smarlow has joined #jboss-as7[15:02:06] *** ChanServ sets mode: +v smarlow[15:05:22] *** Jaikiran has joined #jboss-as7[15:05:22] *** ChanServ sets mode: +v Jaikiran[15:08:15] *** balunasj has joined #jboss-as7[15:08:15] *** ChanServ sets mode: +v balunasj[15:08:48] *** AndyTaylor has joined #jboss-as7[15:08:56] *** ChanServ sets mode: +v AndyTaylor[15:11:12] *** fnasser has joined #jboss-as7[15:13:39] *** jwulf has joined #jboss-as7[15:14:34] *** jwulf has quit IRC[15:14:36] *** balunasj is now known as balunasj_busy[15:15:10] *** Jaikiran has quit IRC[15:23:12] <wolfc> bstansberry, baileyje, ping[15:23:24] <bstansberry> yo[15:23:36] <wolfc> I'm digging through JBAS-9077[15:23:37] <jbossbot> jira [JBAS-9077] Deployment failure leads to a server hang [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9077[15:23:53] <wolfc> In relation to JBAS-9082: https://issues.jboss.org/browse/JBAS-9077?focusedCommentId=12592377&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12592377[15:23:54] <jbossbot> jira [JBAS-9082] Incorrect handling of runtime failures in composite operations if rollback is not enabled [Resolved (Done) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9082[15:24:47] <bstansberry> how related?[15:24:57] <wolfc> I see the ServerCompositeOperationHandlerUnitTestCase has also been modified. So I'm curious what is now the expected behavior of rollback-on-runtime-failure[15:25:35] <wolfc> before 9082 we would get the failure client side[15:25:58] <wolfc> now it responds success and somewhere Arq goes completely wacko on that[15:26:12] <bstansberry> ok, that means Arq needs to be fixed[15:26:25] <bstansberry> 1 se[15:26:27] <bstansberry> sec[15:26:37] <wolfc> right, but I don't see the proper use case in ServerCompositeOperationHandlerUnitTestCase[15:27:17] <bstansberry> if 9082 is Arq's behavior they aren't setting a flag on the plan[15:27:39] <bstansberry> me or baileyje will have to look at the test case[15:27:43] <wolfc> the default flag is false[15:28:33] <wolfc> https://github.com/jbossas/jboss-as/commit/97652baeb4c46bc092fc009a420442602878d807#L2L153[15:28:34] <jbossbot> git [jboss-as] 97652ba.. John E. Bailey [JBAS-9082] - Correctly handle composite operation failures when rollback is not enabled[15:28:35] <jbossbot> jira [JBAS-9082] Incorrect handling of runtime failures in composite operations if rollback is not enabled [Resolved (Done) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9082[15:28:44] <wolfc> previously it was FAILED, now it has become SUCCESS[15:29:11] <wolfc> so what exactly is the meaning of the rollback flag?[15:29:40] <wolfc> no rollback == always success (regardless of start failures?)[15:29:43] <wolfc> ?[15:30:12] <bstansberry> yes[15:30:35] <bstansberry> if it applies to the model, it succeeds, no matter what happens to the runtime[15:30:37] <wolfc> wicked :-) I'll tell Arq to do a plan with rollback then[15:30:45] <wolfc> ah[15:30:46] <bstansberry> i'll do that in a sec[15:31:00] <bstansberry> the plan code is old[15:31:08] <bstansberry> like last summer[15:31:16] <wolfc> :-)[15:31:17] <bstansberry> and has rollback == false by default[15:31:21] <wolfc> yup[15:31:40] <wolfc> I think it'll improve user experience a lot[15:31:43] <bstansberry> there's a JIRA to fix that, but the arq code should just set that[15:31:57] <bstansberry> thanks for looking at that; i thought this was more complex[15:32:13] <bstansberry> i.e. JBAS-9010 resulting in the client never getting a response[15:32:14] <jbossbot> jira [JBAS-9010] Provide more comprehensive error messages for missing dependencies [Open (Unresolved) Task, Blocker, David Lloyd] https://issues.jboss.org/browse/JBAS-9010[15:32:30] <wolfc> well there is still a spot of wickedness why Arq doesn't move forward on success[15:32:55] <wolfc> this is not JBAS-9010[15:32:56] <jbossbot> jira [JBAS-9010] Provide more comprehensive error messages for missing dependencies [Open (Unresolved) Task, Blocker, David Lloyd] https://issues.jboss.org/browse/JBAS-9010[15:33:00] <wolfc> this is JBAS-9077[15:33:01] <jbossbot> jira [JBAS-9077] Deployment failure leads to a server hang [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9077[15:34:01] <bstansberry> sure, but I thought 9077 was another manifestation of 9010, just with Arq as the client[15:34:05] <wolfc> Hmm, could even be neither[15:34:16] <wolfc> 9010 == missing dependency[15:34:21] <wolfc> 9077 == start exception[15:35:21] <bstansberry> true[15:36:06] <bstansberry> anyway, it should set the flag which should help[15:36:33] <wolfc> right, I think if we have rollback = true by default we can close some of those issues[15:37:57] *** frainone has joined #jboss-as7[15:37:57] *** ChanServ sets mode: +v frainone[15:38:06] <bstansberry> I'll look at ServerCompositeOperationHandlerUnitTestCase later[15:39:33] <wolfc> with the explanation that the operation succeeds in the model I think the test case is correct. It's just not intuitive.[15:41:41] *** lgao has quit IRC[15:43:19] <wolfc> bstansberry, how about a fail-on-runtime-failures?[15:44:06] *** pgier has joined #jboss-as7[15:44:06] *** ChanServ sets mode: +v pgier[15:44:19] <wolfc> Hmm, I'm probably silly. rollback-on-runtime-failures makes enough sense.[15:44:23] <bstansberry> just to get a different "outcome"[15:44:24] <bstansberry> ?[15:44:37] <wolfc> we don't want a corrupt model, do we?[15:44:44] <wolfc> or is the model still valid?[15:46:27] <bstansberry> the model reflects what the user wanted to happen, which is probably not fully reflected in the runtime[15:47:36] <wolfc> but the composite model update must be atomic, not?[15:47:48] <bstansberry> yes[15:48:08] <bstansberry> ops are handled in 2 phases -- apply to model and apply to runtime[15:48:31] <wolfc> right, so fail-on-runtime-failures is a bogus mind-warp :-)[15:49:21] <bstansberry> it basically would mean "don't roll back but set "outcome"=>"failure" on the response[15:50:24] <wolfc> but it leaves an invalid model[15:51:11] <wolfc> anyway, this https://github.com/wolfc/jboss-as/commit/366bb57c7bbedb8f88a86dac106218f26f986cc6 works for me[15:51:11] <jbossbot> git [jboss-as] 366bb57.. Carlo de Wolf JBAS-9077: have Arquillian execute deployment with rollback[15:51:13] <jbossbot> jira [JBAS-9077] Deployment failure leads to a server hang [Open (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9077[15:52:48] <bstansberry> wolfc: how about this: https://github.com/bstansberry/jboss-as/commit/5431043cc0a7d9f1e6b18bdd6a001233d0c64822[15:52:49] <jbossbot> git [jboss-as] 5431043.. bstansberry at jboss dot com [JBAS-9077] ServerDeploymentManager clients should set withRollback() on the plan[15:52:50] <jbossbot> jira [JBAS-9077] Deployment failure leads to a server hang [Open (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9077[15:53:15] <bstansberry> yours has the advantage of no spurious import reorder, mine has a bonus fix ;)[15:53:59] <wolfc> :-)[15:54:25] <wolfc> I'm already happy that we found this nagging thing[15:55:24] *** stansilvert has quit IRC[15:56:29] <bstansberry> i thought i'd fixed that before but it must have gotten lost in the shuffle :([15:56:53] *** fnasser has quit IRC[15:57:25] <jbossbot> git [jboss-as] push master 5431043.. bstansberry at jboss dot com [JBAS-9077] ServerDeploymentManager clients should set withRollback() on the plan[15:57:26] <jbossbot> jira [JBAS-9077] Deployment failure leads to a server hang [Open (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9077[15:57:26] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/dcae2ab...5431043[15:58:02] *** dimitris_ has joined #jboss-as7[15:58:02] *** dimitris_ has joined #jboss-as7[15:58:02] *** ChanServ sets mode: +v dimitris_[15:59:05] <baileyje> wolfc: Pong[15:59:18] <wolfc> baileyje, you missed all the fun ;-)[15:59:29] <baileyje> ok. I am reading through it now[16:01:43] *** smcgowan has joined #jboss-as7[16:01:43] *** ChanServ sets mode: +v smcgowan[16:03:17] <baileyje> sweet. SO how many issues did it fix anyway?[16:03:58] <wolfc> I think we can do away with the issues that deal with an exception during runtime and ending up in a client side hang.[16:05:00] <baileyje> Nice and easy[16:05:42] <wolfc> Ah, there is still the thing that a client receives SUCCESS but doesn't do anything sensible.[16:06:12] <wolfc> It's likely that this is caused by side effects of lookups or waiting on service/mbean states.[16:07:04] <wolfc> Which is probably more like a 'I think I hatched the egg, but where is the chicken.'[16:08:43] *** fnasser has joined #jboss-as7[16:08:53] *** darranl is now known as darranl_afk[16:16:12] *** Nihility has joined #jboss-as7[16:16:12] *** Nihility has joined #jboss-as7[16:16:12] *** ChanServ sets mode: +v Nihility[16:16:43] *** pferraro has joined #jboss-as7[16:16:43] *** ChanServ sets mode: +v pferraro[16:25:41] *** bobmcw has quit IRC[16:27:14] <aloubyansky> bstansberry: i committed deploy/undeploy JBAS-9071 https://github.com/aloubyansky/jboss-as/commit/a6143984146b8b9ff3b8db290bfd5e728511ac80[16:27:15] <jbossbot> jira [JBAS-9071] Deployment via the CLI [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9071[16:27:16] <jbossbot> git [jboss-as] a614398.. Alexey Loubyansky JBAS-9071[16:27:27] <bstansberry> :-)[16:27:34] <aloubyansky> i wanted to talk a bit about the deploy[16:27:41] <aloubyansky> the way i do it, at least...[16:27:55] <bstansberry> sure[16:28:02] <aloubyansky> i execute upload url first, then add and then deploy[16:28:23] <aloubyansky> shouldn't upload do add as well?[16:29:30] <bstansberry> no, but add can do upload (of a stream)[16:30:07] <bstansberry> there's a JIRA let add do the upload part via a URL[16:30:17] <bstansberry> but probably won't be done for beta2[16:30:27] <bstansberry> but TBH, using a stream is better[16:30:36] <aloubyansky> yes... is there an example how to associate a stream with the op request?[16:31:15] <bstansberry> sure, 1 sec[16:32:30] <bstansberry> in controller-client AbstractServerDeploymentManager.getCompositeOperation()[16:32:39] *** asaldhan has joined #jboss-as7[16:32:40] *** ChanServ sets mode: +v asaldhan[16:32:59] <bstansberry> that's kind of convoluted because it's processing an entire plan[16:33:03] *** jcosta has joined #jboss-as7[16:33:04] <aloubyansky> yes, i saw that, actually... but that's on the server side, right?[16:33:18] <bstansberry> no[16:33:23] <bstansberry> that executes on the client[16:33:42] <aloubyansky> ok, then i misunderstood...[16:34:08] <wolfc> Nihility, ping[16:34:08] <bstansberry> it's basically the transation between the ServerDeploymentManager convenience API and the raw management API[16:34:49] <aloubyansky> ok, let me briefly describe what i have at the moment to see whether i should improve something before the pull...[16:35:01] <bstansberry> k[16:35:05] *** pilhuhn has quit IRC[16:35:23] <aloubyansky> a new deploy command accepts a file path (tab completion is supported for the argument)[16:35:52] <aloubyansky> and undeploy accepts a deployment name as an argument (which is not a file path of course)[16:36:05] <smarlow> wolfc: I'd like to merge in some JPA test changes and XPC fixes today. Once I merge my test changes in, the EPCPropagationTestCase.testNoTxEPCRemoveOperation test will hang until we fix the issue we semaphore (permit not being release) issue we discussed. I'll wait to hear from you before merging my test changes in.[16:36:24] <aloubyansky> deploy takes the file name (the last part from the argument) and uses it as the name and runtime name[16:36:58] <aloubyansky> there is no way currently for the user to provide his/her own name/runtime name[16:36:58] <wolfc> smarlow, I have https://github.com/wolfc/jboss-as/commits/fix-pool for merging[16:37:08] <aloubyansky> that's basically it[16:37:13] * smarlow funny, just got your email. :) Thanks[16:37:14] <wolfc> smarlow, but we have regression on EPCPTC[16:37:20] <wolfc> because of woodstox[16:37:37] <bstansberry> can it accept params for the unique name and runtime name?[16:37:41] *** pilhuhn has joined #jboss-as7[16:37:41] *** ChanServ sets mode: +v pilhuhn[16:37:47] *** bobmcw has joined #jboss-as7[16:37:47] *** ChanServ sets mode: +v bobmcw[16:37:49] <wolfc> smarlow, the version parsing doesn't work anymore[16:38:01] <aloubyansky> that's what i meant, it can't[16:38:11] <aloubyansky> ok, so that's the first thing to add[16:38:26] <smarlow> wolfc: is this on your branch only or on as7 master/upstream[16:38:56] <wolfc> don't look at the CNFE, look at the server itself[16:39:03] <aloubyansky> name/runtime name, anything else?..[16:39:07] <bstansberry> aloubyansky: yeah, it needs to accept those params, although using streams is more important[16:39:09] <asaldhan> mmoyses says that https not yet fully functional on AS7. is this true? Just asking.[16:39:34] <mmoyses> asaldhan: remy committed ssl support a few days ago[16:39:37] <aloubyansky> ok, i'll switch to streams as well[16:39:38] <asaldhan> mmoyses: thanks.[16:39:51] *** jhalliday has quit IRC[16:39:51] *** jhalliday1 has joined #jboss-as7[16:39:57] <bstansberry> streams let remote clients upload :)[16:40:12] <mmoyses> asaldhan: we still need to figure out a way to have global ssl configuration[16:40:22] <asaldhan> mmoyses: ok[16:40:30] <asaldhan> mmoyses: those settings can come off the security blocks[16:40:52] <bstansberry> aloubyansky: just FYI, there is a JIRA that jamezp is working that will eliminate the need for a separate "deploy" operation[16:40:53] <aloubyansky> yes, i just for some reason thought that code was on the server side...[16:41:00] <asaldhan> mmoyses: sec domains + user/role/groups + ssl settings. Then each app can override these settings.[16:41:21] <aloubyansky> ok, thanks[16:41:34] *** jhalliday1 has quit IRC[16:41:51] <bstansberry> you want me to pull what you have?[16:41:54] <mmoyses> asaldhan: i thought we agreed that apps couldn't override security domains set on domain/standalone.xml[16:42:42] <asaldhan> mmoyses: I meant the ssl settings - more like JSDs at app level[16:42:47] <mmoyses> ok[16:43:39] <aloubyansky> bstansberry: it's not critical to me personally... if you want to then sure. i'll commit the new changes today/tomorrow[16:44:15] <bstansberry> aloubyansky: ok, i'll wait[16:44:26] <rmaucher> bstansberry, can you pull https://github.com/rmaucher/jboss-as/commit/c559debcc3e9b76145b8e00d39adbed7d9d77375 for me ? thanks[16:44:27] <jbossbot> git [jboss-as] c559deb.. Rémy Maucherat Add tag classes to the list of injectable classes.[16:44:28] <bstansberry> but will try and play some :-)[16:44:39] *** maeste has quit IRC[16:45:03] <bstansberry> rmaucher: ok, will do in about 20 mins[16:45:08] <bstansberry> bbiab[16:45:11] <rmaucher> thanks[16:45:15] *** bstansberry is now known as bstans_afk[16:48:00] *** pferraro has quit IRC[16:48:24] *** pferraro has joined #jboss-as7[16:48:24] *** ChanServ sets mode: +v pferraro[16:50:09] *** darranl_afk is now known as darranl[16:57:12] *** jfd has joined #jboss-as7[16:57:12] *** jfd has quit IRC[16:57:13] *** jfd has joined #jboss-as7[16:57:13] *** ChanServ sets mode: +v jfd[17:03:53] *** maeste has joined #jboss-as7[17:03:59] *** maeste has quit IRC[17:03:59] *** maeste has joined #jboss-as7[17:03:59] *** ChanServ sets mode: +v maeste[17:04:37] *** asoldano is now known as asoldano_away[17:07:22] *** frainone has quit IRC[17:08:08] *** bstans_afk is now known as bstansberry[17:12:12] *** balunasj_busy is now known as balunasj_mtg[17:12:37] <Nihility> wolfc: whats up[17:14:12] <Nihility> wolfc: i take it you are messaging me about hudson[17:14:12] <Nihility> ?[17:16:21] *** ALR has joined #jboss-as7[17:16:21] *** ChanServ sets mode: +v ALR[17:16:44] <smarlow> wolfc: I'll try to run locally with the woodstox removed (or did you already do that?)[17:23:02] *** Jaikiran has joined #jboss-as7[17:23:02] *** ChanServ sets mode: +v Jaikiran[17:24:34] <jbossbot> git [jboss-as] push master c559deb.. Rémy Maucherat Add tag classes to the list of injectable classes.[17:24:35] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/5431043...c559deb[17:24:42] <rmaucher> thanks[17:24:59] <bstansberry> you're welcome[17:25:10] <bstansberry> rmaucher: some day I have to actually meet you![17:25:21] * bstansberry proposes trip to paris[17:27:02] <rmaucher> I don't live in Paris, but you can meet Emmanuel there ;)[17:27:17] <bstansberry> did you use to?[17:27:22] <rmaucher> nope[17:27:26] <wolfc> Nihility, smarlow, yes, the woodstox commit brought regression on EPC test[17:28:04] <bstansberry> anyway, if I get to France, I should find you :)[17:29:05] <bstansberry> aloubyansky: I realize we didn't talk about deployment replacement[17:29:27] <bstansberry> an "add" will fail if there is already a deployment with that name[17:29:27] *** emuckenhuber has quit IRC[17:29:33] <aloubyansky> bstansberry: yes...[17:29:46] <rmaucher> ok[17:30:18] <aloubyansky> should i write a separate command for redeployment?[17:30:45] <bstansberry> DeploymentFullReplaceHandler deals with that cmd == "full-replace-deployment"[17:31:15] <bstansberry> hmm, but from a convenience point of view I'm not sure what's better[17:31:38] <bstansberry> require different command or just detect the deployment exists and use the right command internally[17:31:47] *** jamezp has joined #jboss-as7[17:31:51] *** jfclere has quit IRC[17:32:13] <aloubyansky> from the convenience point of view, i think, one command would be better[17:32:38] <bstansberry> yes, me too[17:33:08] <bstansberry> we need to support other workflows though, but it doesn't have to be via high level methods[17:33:27] <aloubyansky> if the content hasn't changed will it detect it?..[17:33:35] <bstansberry> to do it via low level methods, there needs to be a way to associate a stream with the CLI context[17:34:06] <bstansberry> no, it won't[17:35:08] <Nihility> wolfc: thats very very odd[17:37:27] <wolfc> Parsing goes a bit haywire. I haven't dug too deep yet.[17:37:37] <aloubyansky> bstansberry: btw, i've been thinking about shortening the prompt as well, i.e. instead of full node path in the prompt, display only the last node[17:38:15] <bstansberry> sounds good[17:38:23] <bstansberry> people are used to that[17:39:11] <bstansberry> another thought I had was accepting the connect params from the cmd line[17:39:49] <aloubyansky> ok, noted[17:39:52] <bstansberry> not a priority, just a thought[17:41:54] *** mmoyses is now known as mmoyses_[17:43:41] <aloubyansky> bstansberry: what if i want to connect using the defaults automatically... should connect be executed at launch time?[17:43:49] *** emmanuel has joined #jboss-as7[17:43:58] *** ChanServ sets mode: +v emmanuel[17:44:10] *** asoldano_away is now known as asoldano[17:44:11] *** jamezp has quit IRC[17:44:17] <Jaikiran> wolfc: dmlloyd: this branch has been rebased on latest upstream and has latest ejb-jar.xml related code https://github.com/jaikiran/jboss-as/commits/default-local-view[17:44:24] <Jaikiran> could you please pull it to upstream[17:45:04] <Jaikiran> wolfc: that current branch has tests for dd + annotation stuff[17:45:10] <Jaikiran> and they are passing[17:45:11] <wolfc> neat[17:45:35] <Jaikiran> i'll come up with a wiki to explain what we are doing with this merging thing[17:45:45] <Jaikiran> i had to redo a bit due to the way the annotation DUPs work currently[17:45:49] *** jamezp has joined #jboss-as7[17:46:47] *** fnasser has quit IRC[17:47:48] *** maeste has quit IRC[17:48:27] <wolfc> Jaikiran, do you have a list that maybe we should put up that shows missing bits and pieces?[17:48:52] <Jaikiran> wolfc: not yet. but i can come up with one[17:48:55] *** fnasser has joined #jboss-as7[17:49:11] <Jaikiran> my plan is to have the same amount of support for ejb-jar.xml that we currently have for annotations[17:49:59] <wolfc> does that include interceptors?[17:51:00] *** fnasser has quit IRC[17:51:04] <Jaikiran> yes, i plan to have ejb-jar.xml interceptor support ready for Beta2.[17:51:24] <Jaikiran> otherwise the current ejb-jar.xml support is just basic[17:51:45] <Jaikiran> the only thing i am not sure about is MDBs[17:51:54] <Jaikiran> i guess it's WIP right now[17:53:06] <wolfc> MDBs don't need much more than SLSB[17:54:33] <Jaikiran> i mean, i currently don't see a way to setup the queue/destination related info in the MDB component description[17:55:02] <baileyje> dmlloyd: you around today?[17:55:34] <dmlloyd> baileyje: for a while, I"ll be out in the afternoon[17:55:42] <dmlloyd> Jaikiran: have you looked at stuart's https://github.com/stuartwdouglas/jboss-as/commit/803990d135e7a1d0eabcb94b6561c306851697d3 ?[17:55:43] <jbossbot> git [jboss-as] 803990d.. Stuart Douglas Inital env-entry and ejb-ref support[17:55:50] * Jaikiran checks[17:56:06] <bstansberry> aloubyansky: use a switch to connect?[17:56:18] <bstansberry> ./jboss-admin.sh --connect[17:56:38] <bstansberry> ./jboss-admin.sh --connect xyz.com:9999[17:56:39] <baileyje> dmlloyd: ok. Just curious. You mention last week you were going to do something to help move async forward. Just trying to remember what it was[17:56:43] <wolfc> Jaikiran, an MDB only needs a ResourceAdapter. The rest is all activation properties.[17:57:13] <Jaikiran> oh right! had forgotten those things are part of activation config[17:57:27] <dmlloyd> baileyje: well it's all turned into a muddy mess between my interceptor chain changes and stuart's proposed rework of component bindings.[17:57:40] <aloubyansky> bstansberry: yes, that would work. does the default not connecting on the launch make sense?[17:57:42] <dmlloyd> so I'm still thinking it over.[17:57:59] <baileyje> dmlloyd: Ok. Anything I can help with, or should I let the mud settle?[17:58:34] *** balunasj_mtg has quit IRC[17:59:06] *** smcgowan has quit IRC[17:59:12] <wolfc> Nihility, smarlow, http://fpaste.org/k4bJ/ I still need to write a proper test up. First I'm going to eat something.[17:59:25] <bstansberry> aloubyansky: I think not connecting by default makes sense. Connecting by default seems like launching a browser that tries to read localhost:80[18:00:00] <Nihility> wolfc: yes that would explain it[18:00:00] <aloubyansky> ok[18:00:09] <Jaikiran> dmlloyd: looks like a large change. will take a complete look later tonight to understand better[18:04:10] <dmlloyd> yeah I'm not really sure how I feel abotu the whole thing.[18:04:38] <dmlloyd> I see the necessity for the change but I really am thinking that the end result is too complex. I have to spend more time reading it over[18:05:21] <dmlloyd> it's the same thing all over again: just like how we ended up with 3 different approaches to define lifecycle callbacks.[18:05:49] *** dimitris_ has quit IRC[18:09:40] *** emuckenhuber has joined #jboss-as7[18:09:40] *** emuckenhuber has joined #jboss-as7[18:09:40] *** ChanServ sets mode: +v emuckenhuber[18:13:16] *** alesj has quit IRC[18:14:41] *** slaboure has quit IRC[18:14:48] *** bobmcw has quit IRC[18:18:18] <smarlow> wolfc: I tried your patch with the current integration tests and get http://fpaste.org/gs3D[18:19:13] <smarlow> wolfc: the pattern that you changed, occurs again in the same source file. Should they all be changed? I'll try that[18:22:14] *** bobmcw has joined #jboss-as7[18:22:14] *** ChanServ sets mode: +v bobmcw[18:24:35] *** asaldhan has left #jboss-as7[18:24:45] *** Jaikiran is now known as Jaikiran|Dinner[18:27:14] *** Jaikiran|Dinner has quit IRC[18:27:21] <smarlow> wolfc: I had better luck with http://fpaste.org/UrIe/[18:28:29] *** pilhuhn is now known as pil-dinner[18:29:59] <smarlow> wolfc: but still failures in other tests http://fpaste.org/6VbU/[18:31:38] *** asaldhan has joined #jboss-as7[18:31:38] *** ChanServ sets mode: +v asaldhan[18:32:26] *** bobmcw has quit IRC[18:32:45] *** bobmcw has joined #jboss-as7[18:32:45] *** ChanServ sets mode: +v bobmcw[18:42:35] <baileyje> Ok. So what can I tackle? Anyone need help getting things in for beta2?[18:43:17] <baileyje> bstansberry: You have a lot of Jiras assigned to you. Any you want help on?[18:44:08] <bstansberry> can you look at the pull request I sent to the pull request list last night?[18:45:02] <bstansberry> baileyje: that plus JBAS-9051[18:45:04] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9051[18:45:18] <baileyje> Sure[18:45:24] <bstansberry> I was going to do that by 8:30 but here it is 11:45 :-)[18:45:31] <bstansberry> wanna chat about that a bit?[18:52:20] *** mmoyses_ is now known as mmoyses[18:55:46] *** mgoldmann has quit IRC[18:56:11] *** mgoldmann has joined #jboss-as7[18:56:12] *** ChanServ sets mode: +v mgoldmann[19:10:14] *** aloubyansky has quit IRC[19:12:57] *** frainone has joined #jboss-as7[19:12:57] *** ChanServ sets mode: +v frainone[19:14:42] *** torben has quit IRC[19:18:06] *** alesj has joined #jboss-as7[19:19:44] *** anguenot has quit IRC[19:32:01] <baileyje> bstansberry: SOrry.. Had a phone call.[19:32:34] <bstansberry> np; i was otherwise engaged[19:33:29] <bstansberry> got time now for JBAS-9051 ?[19:33:30] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9051[19:33:42] <baileyje> bstansberry: The pull request was JBAS-9154 correct:[19:33:44] <jbossbot> jira [JBAS-9154] Fill in DescriptionProviders for deployment-scanner subsystem [Open (Unresolved) Task, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9154[19:33:56] <bstansberry> yeah[19:34:15] <baileyje> Looking at that. Then I will start looking at JBAS-9051[19:34:16] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9051[19:34:31] <bstansberry> baileyje: https://github.com/bstansberry/jboss-as/commit/d67405aaadea5a0b9218d76dced3fdfe7fedee09[19:34:32] <jbossbot> git [jboss-as] d67405a.. bstansberry at jboss dot com [JBAS-9154] Add mgmt descriptions for deployment scanner module...[19:34:33] <jbossbot> jira [JBAS-9154] Fill in DescriptionProviders for deployment-scanner subsystem [Open (Unresolved) Task, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9154[19:34:54] <bstansberry> ok, ping me when you get to 9051[19:36:25] <asoldano> dmlloyd, hi, sorry for bothering, but really, isn't moving as7 to jboss-modules-1.0.0.Beta17-SNAPSHOT acceptable for few days, given you're busy and can't release it?[19:39:05] <asoldano> Nihility, ^[19:39:12] <baileyje> bstansberry: The change looks good.[19:39:20] <bstansberry> thanks[19:41:12] <baileyje> bstansberry: ok. I am going to grab a sandwich. I will ping you in 10 minutes about the other issue[19:41:28] <bstansberry> make it 20; i need to eat too![19:44:25] *** bstansberry is now known as bstans_food[19:45:50] <smarlow> wolfc: hehe, the testWebInfLibNotAccessible CNFE is expected by the test[19:46:04] *** bobmcw has quit IRC[19:46:37] <jbossbot> git [jboss-as] push master 69d33bf.. bstansberry at jboss dot com [JBAS-9154] Add mgmt descriptions for deployment scanner module...[19:46:37] <jbossbot> jira [JBAS-9154] Fill in DescriptionProviders for deployment-scanner subsystem [Open (Unresolved) Task, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9154[19:46:38] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c559deb...69d33bf[19:47:21] *** jpederse has quit IRC[19:47:29] *** asoldano is now known as asoldano_dinner[19:47:54] <smarlow> wolfc: looks like the problem is resolved with your patch (applied to each of the calls to reader.getAttributeNamespace(i))[19:51:58] *** bobmcw has joined #jboss-as7[19:51:58] *** ChanServ sets mode: +v bobmcw[19:58:26] *** tdiesler has quit IRC[20:01:37] <smarlow> wolfc, Nihility: The test app also works with Carlo's suggested fix. :-) I'll submit a merge soon with that and other changes.[20:02:11] *** darranl has quit IRC[20:07:21] <wolfc> smarlow, cool I didn't look too deep. So yes every getAttributeNamespace is likely affected.[20:08:28] *** jamezp has quit IRC[20:08:28] *** jamezp1 has joined #jboss-as7[20:09:43] *** jamezp1 is now known as jamezp[20:10:32] *** anguenot has joined #jboss-as7[20:15:59] *** asaldhan has quit IRC[20:18:00] *** aslak has quit IRC[20:18:51] *** bstans_food is now known as bstansberry[20:19:42] <bstansberry> smarlow, wolfc: when I hear getAttributeNamespace() causing problems, I suspect woodstox is now being used somewhere it wasn't before?[20:19:54] <wolfc> correct[20:21:25] *** darranl has joined #jboss-as7[20:21:26] *** darranl has joined #jboss-as7[20:21:26] *** ChanServ sets mode: +v darranl[20:26:28] <Nihility> yes its the default provider now[20:26:43] <Nihility> we are no longer using the jdk stax impl because it is completely broken on some jdks[20:26:54] <bstansberry> smarlow, wolfc: in case it's helpful to anyone: https://issues.jboss.org/browse/STXM-8[20:26:56] <jbossbot> jira [STXM-8] Use "" instead of null for namespaces and prefixes [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/STXM-8[20:27:04] <bstansberry> WSTX-127[20:27:18] <bstansberry> boo jbossbot![20:27:28] <bstansberry> doesn't give codehaus any love[20:27:37] <bstansberry> http://jira.codehaus.org/browse/WSTX-127[20:27:59] * bstansberry doesn't know if all this is already understood; just trying to be helpful in case not :)[20:28:22] * smarlow only understands what he understands, doesn't know what he doesn't :-)[20:28:36] <smarlow> bstansberry: thanks Brian :)[20:29:44] <jamezp> I know with OpenJDK the issue was the the namespace for the attribute was null, but the namespace passed in as the parameter was an empty string.[20:30:17] <jamezp> This must have been fixed in new version of OpenJDK, because it worked on 1.6.0_20.[20:30:32] <wolfc> bstansberry, it looks unrelated, but something that made an impact[20:31:04] <wolfc> bstansberry, getNamespaceURI is not allowed to return null, while getNamespaceAttribute is[20:31:09] *** asaldhan has joined #jboss-as7[20:31:10] *** ChanServ sets mode: +v asaldhan[20:31:18] <wolfc> smarlow: ^[20:32:35] <jamezp> wolfc: That's where the issue I had was. The namespace passed in as the parameter for the attribute was an empty string. The namespace on the QName attribute was null which caused it not to match.[20:32:57] *** mbg is now known as mbg|away[20:35:18] <wolfc> jamezp, ? I lost the context[20:35:45] <jamezp> wolfc: Probably because I just realized I didn't give the context :-)[20:35:52] <Nihility> wolfc: it was actually unclear in the stax spec, they changed it to match DOM and SAX afterwords[20:35:53] *** alesj has quit IRC[20:35:54] *** alesj1 has joined #jboss-as7[20:35:56] <wolfc> smarlow, bstansberry, anyway we're not the only ones, https://issues.apache.org/jira/browse/PIVOT-717 :-)[20:36:31] <wolfc> Nihility, yeah, it's not worth something making a real issue out of. We can live with this.[20:36:41] *** ALR has quit IRC[20:37:09] <Nihility> wolfc: anything that uses staxmapper should be ok if we change staxmapper to translate[20:37:11] <jamezp> wolfc: There was an issue with AS7 not starting on OpenJDK 1.6.0_17. I dug into it and found it was an issue with an empty string for namespace and the QName attribute being null.[20:37:41] <jamezp> We added woodstox to the JAXP provider and it seemed to fix it.[20:37:47] <Nihility> but switching to woodstox across the board means we dont have to worry about different behavior on different VMs[20:37:50] <Nihility> and its faster anyway[20:37:50] <wolfc> jamezp, ah yes it was your contribution that made the regression ;-)[20:38:22] <jamezp> Oops, I should check the logs. I must have missed something myself when I lost my connection.[20:38:30] <smarlow> wolfc: is your https://github.com/wolfc/jboss-as/commits/fix-pool fix coming in soon. I want to commit my test changes but will cause the testsuite to pause. I can probably hold off on the testsuite changes.[20:39:38] * smarlow is wondering if his database load will complete today[20:40:09] <wolfc> Sent the pull request[20:40:27] <smarlow> thanks, I'll queue mine up too :)[20:40:46] <wolfc> jamezp, the regression was caught by the integration-tests, not a regular build.[20:41:08] <wolfc> jamezp, if you want you run it with -Pintegration-tests[20:41:21] <jamezp> wolfc: Ah, probably why I didn't notice it.[20:41:23] <jamezp> Will do.[20:43:34] <jamezp> wolfc: I did remove some excludes in the main pom for JBAS-8874.[20:43:36] <jbossbot> jira [JBAS-8874] Woodstox dependency causes smoke test failures [Closed (Out of Date) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/JBAS-8874[20:45:22] <wolfc> jamezp, yeah, that was some related issue. Nihility, did you not fix that properly?[20:45:57] *** alesj1 has quit IRC[20:46:38] <Nihility> wolfc: that issue should no longer be relevant[20:46:58] <wolfc> I know, I'm surprised it is not set to fixed.[20:47:06] *** mgoldmann has quit IRC[20:47:15] <Nihility> wolfc: yeah it fell into my unassigned issues list[20:47:25] <Nihility> so it was mistakenly closed as out of date[20:47:40] <Nihility> which is technically true i aguess[20:48:20] *** anguenot has quit IRC[20:50:10] <bstansberry> baileyje: I added my thoughts on JBAS-9051 as a comment on the issue[20:50:11] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9051[20:50:21] <baileyje> bstansberry: Ok. I will take a look now[20:50:34] *** JimMa has joined #jboss-as7[20:55:40] *** mbg|away is now known as mbg[20:56:41] <wolfc> bstansberry, it's not suffering by chance from the 'rollback false' issue?[20:58:53] <bstansberry> wolfc: no. it doesn't use ServerDeploymentManager, and it gets default behavior (i.e. rollback)[20:59:52] <bstansberry> if the server doesn't respond, the FS scanner thread will block forever waiting[21:00:03] *** adietisheim has quit IRC[21:02:58] *** rawbdor has joined #jboss-as7[21:02:58] *** ChanServ sets mode: +v rawbdor[21:07:01] *** bjornna has joined #jboss-as7[21:14:33] <jbossbot> git [jboss-as] push master 98048b6.. Scott M Stark JBAS-9151, add support for criteria specifying the bind address and add a new LoopbackAddressInterfaceCriteria[21:14:34] <jbossbot> jira [JBAS-9151] Need the ability to specify the bind address on interface criteria [Open (Unresolved) Feature Request, Major, Scott Stark] https://issues.jboss.org/browse/JBAS-9151[21:14:34] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/69d33bf...98048b6[21:15:14] *** fnasser has joined #jboss-as7[21:20:30] <baileyje> bstansberry: There?[21:20:41] <bstansberry> yep[21:21:06] <baileyje> Do we have a deployment we can use to test the scanner issue?[21:21:45] <bstansberry> not that i know of[21:21:56] <bstansberry> maybe there's something for 9010[21:22:11] <bstansberry> i think dmlloyd isn't around[21:23:23] <bstansberry> wolfc: do you have any deployment around that you know causes JBAS -9010 ?[21:23:27] *** asoldano_dinner is now known as asoldano[21:24:18] *** jcosta has quit IRC[21:24:41] *** jcosta has joined #jboss-as7[21:25:09] <asoldano> Nihility, ping[21:25:41] *** maeste has joined #jboss-as7[21:25:42] *** ChanServ sets mode: +v maeste[21:26:05] <Nihility> yo[21:26:21] <asoldano> hi, did you see my message above (sorry had dinner in the mean time) ?[21:26:37] *** anguenot has joined #jboss-as7[21:28:03] <Nihility> asoldano: ill take to david about it[21:29:33] <asoldano> Nihility, I'm sorry to insist on that, but I need a couple of days to prepare and release jbossws once that jboss-module update is done, and if it does not happen *soon*, we won't have the jbossws update in time for next as7 beta[21:30:24] <Nihility> asoldano: cant you just do that now, do you have a dep on jboss-modules directly in jbossws?[21:30:30] *** pmuir has quit IRC[21:31:09] *** anguenot has quit IRC[21:31:10] <asoldano> Nihility, the server does not boot without the new modules and with the new jbossws and I'd like to have full hudson runs before releasing[21:31:11] *** opalka has joined #jboss-as7[21:31:11] *** ChanServ sets mode: +v opalka[21:31:57] <Nihility> asoldano: cant you just have the hudson run against your tree which has the module snapshot?[21:33:31] <asoldano> Nihility, well, everything is possible, I can duplicate the hudson jobs, for running everything against both AS7 trees... thought simply releasing another beta of modules would be much easier (I would have already done it if I was allowed ;-) ), given the current snapshot does not break anything[21:33:38] *** alesj has joined #jboss-as7[21:35:09] <Nihility> asoldano: im just trying to remove blockers here, there is no reason to wait on a modules release to cut a ws release[21:35:43] <asoldano> Nihility, ok..[21:35:59] <Nihility> asoldano: i can rush the modules release[21:36:10] <Nihility> asoldano: but david is out, and im not sure why it wasnt done yet[21:36:17] <Nihility> asoldano: hell be back later tonight[21:36:29] <opalka> dmlloyd, baileyje Do we want /plant to support .sar archives with nested EJB & WAR archives?[21:36:36] <opalka> s/plant/plan/[21:36:41] <asoldano> Nihility, ok, I see, thanks anyway :-)[21:37:02] <Nihility> asoldano: so the best we can probably do is get it to you be tommorow morning our time[21:37:09] <baileyje> opalka: I don't think we should..[21:37:27] <opalka> baileyje, any reason for that? I'm asking because we used to prior AS7 ;)[21:38:05] <baileyje> opalka: I guess it just doesn't seem necessary.. but I don't know the historical reasons it was[21:38:18] <opalka> baileyje, neither I[21:39:11] <opalka> baileyje, We have some tests using this feature so I thought it might be helpful for our customers to simplify their migration to AS7[21:41:01] <opalka> baileyje, and AFAIK e.g. transaction team is using this feature too to integrate with JBossWS. I.e. they provide .sar archives with JSE ws. endpoints in it[21:41:01] *** bjornna has quit IRC[21:42:20] <opalka> baileyje, I already have this nested EJBs & WARs in .sar archives support implemented locally[21:42:33] *** anguenot has joined #jboss-as7[21:42:35] <opalka> baileyje, but I have some failing .sar archives tests[21:42:52] <opalka> baileyje, and I'm wondering whether to continue for bringing it to life, or I can stop this effort[21:48:30] <baileyje> I think I would need some others to chime in.[21:49:27] *** sanne has quit IRC[21:50:09] <opalka> baileyje, this is what I found about sars from public sources - http://en.wikipedia.org/wiki/Service_Archive[21:50:58] *** alesj has quit IRC[21:56:40] <jbossbot> git [jboss-as] push master da176c6.. Stefano Maestri JBAS-9079 Port connector subsystems to IronJacamar Beta5...[21:56:41] <jbossbot> jira [JBAS-9079] Port connector subsystems to IronJacamar Beta5 [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9079[21:56:42] <jbossbot> git [jboss-as] push master dac58c9.. bstansberry at jboss dot com [JBAS-9061] Update the LocalDescriptions.properties[21:56:42] <jbossbot> jira [JBAS-9061] DataSouce schema uses incorrect name for JDBC driver [Open (Unresolved) Bug, Critical, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9061[21:56:43] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/98048b6...dac58c9[21:57:11] <maeste> bstansberry: thanks[21:58:10] <bstansberry> maeste: np. please have a look at that 2nd commit (mine) in case you want other wording. the old module=xxx caused a smoke test failure[21:58:41] <maeste> bstansberry: oh sure right[22:00:41] *** emuckenhuber has quit IRC[22:01:46] *** anguenot has quit IRC[22:12:10] *** pil-dinner has quit IRC[22:15:37] *** emuckenhuber has joined #jboss-as7[22:15:37] *** emuckenhuber has joined #jboss-as7[22:15:37] *** ChanServ sets mode: +v emuckenhuber[22:16:26] *** AndyTaylor has quit IRC[22:26:10] *** bstansberry is now known as bstans_afk[22:28:52] *** baileyje has quit IRC[22:29:34] *** jcosta has quit IRC[22:31:01] *** baileyje has joined #jboss-as7[22:31:01] *** ChanServ sets mode: +v baileyje[22:31:55] <Nihility> smarlow: wolfc was carlos fixed merged?[22:32:31] <smarlow> Nihility: I don't think so, he sent email before me but it wasn't applied yet[22:32:33] *** stalep has quit IRC[22:32:41] * smarlow double checking...[22:33:34] <smarlow> Nihility: wolfc fix wasn't merged yet.[22:38:38] <Nihility> thanks[22:38:40] <Nihility> ill get on that[22:38:44] *** asoldano is now known as asoldano_away[22:38:46] <Nihility> where did this day go?[22:38:52] *** alesj has joined #jboss-as7[22:39:39] <jamezp> It's only 1:40 on the west coast if that helps :-)[22:39:58] <Nihility> hahaha[22:40:09] <Nihility> unfortunately my daughter's day care is on CST[22:40:22] <Nihility> otherwise i would love to pretend its only 1:40[22:40:23] <Nihility> haha[22:41:18] <jamezp> Ha, I'd rather be on CST. I'm looking at code that was written in the late 80's/early 90's :-([22:42:41] <Nihility> nice[22:42:47] <Nihility> is it your code?[22:43:07] <jamezp> No, I was in middle school then.[22:43:16] <wolfc> we did fix one nasty hang from Arq[22:43:40] <Nihility> smarlow: whos patches should i merge first[22:43:59] *** aloubyansky has joined #jboss-as7[22:44:38] <smarlow> Nihility: best to start with wolfc but it won't matter if you don't run the testsuite/integration[22:44:39] *** alesj has left #jboss-as7[22:44:43] *** alesj has quit IRC[22:44:46] <wolfc> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-testSuite-sun16/20/testReport/history/[22:46:12] *** jfd has quit IRC[22:46:43] <Nihility> ok so in that case[22:47:04] <Nihility> smarlow: can you rebase your patches on top of wolfc's[22:47:38] *** bstans_afk is now known as bstansberry[22:47:42] <baileyje> bstans_afk: Ping me when you are available.[22:49:00] <baileyje> bstansberry: I think there is an issue with autodeployments being attempted everyscan if they are failed.[22:49:14] <aloubyansky> bstansberry: about JBAS-9140, have you seen my patches?[22:49:16] <jbossbot> jira [JBAS-9140] Incorrect value for boolean parameter [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9140[22:49:17] *** rmaucher has quit IRC[22:49:36] <baileyje> So I have a deployment that is marked as failed, the autodeployment is not checking to verify the deployment is not in a failed state[22:49:59] <bstansberry> aloubyansky: I saw your comment; but haven't gotten to the patches :([22:50:28] <aloubyansky> ok, would be nice if somebody could review them...[22:50:35] <bstansberry> will do[22:50:42] <aloubyansky> thanks[22:51:07] *** aloubyansky has quit IRC[22:51:35] <smarlow> Nihility: I added "https://github.com/wolfc/jboss-as.git" and git fetched. Should I do a git merge from wolfc's fix-pool next?[22:52:06] <smarlow> or some kind of "git pull --rebase ..."[22:52:08] <Nihility> you want rebase[22:52:09] <wolfc> smarlow, from your checkout, git rebase wolfc/fix-pool[22:52:25] <wolfc> that puts your work on top of that branch[22:52:31] <bstansberry> baileyje: hmm[22:52:32] <smarlow> conflicts to fix, fixing... :)[22:52:41] <bstansberry> let me look[22:52:56] *** aslak has joined #jboss-as7[22:52:56] *** ChanServ sets mode: +v aslak[22:52:59] <wolfc> hmm, there shouldn't be any[22:53:08] <baileyje> Easiest thing to do is to add a bad deployment and debug the scanner. It will add a task for the failed deployment every time[22:53:24] <baileyje> and cause all subsequent deployments to refail[22:54:36] <bstansberry> baileyje: the idea was to catch it here:[22:54:40] <bstansberry> DeploymentMarker marker = deployed.get(fileName);[22:54:40] <bstansberry> long timestamp = getDeploymentTimestamp(child);[22:54:40] <bstansberry> if (marker == null || marker.lastModified != timestamp)[22:54:43] *** mmoyses has quit IRC[22:55:12] <bstansberry> that was the vague idea :-)[22:55:13] <baileyje> bstansberry: Let me see..[22:55:36] <baileyje> bstansberry: Is it actually added to deployed if it is failed?[22:55:53] <bstansberry> that's the "vague" part ;)[22:56:00] <wolfc> ah, you still have that 'discard' commit in there[22:56:45] <baileyje> bstansberry: ANyway, my change works. I have a service with a bad dep. The scanner times it out, fails it, and continues.[22:56:59] <baileyje> It just happens to retry the failed deployment everytime..[22:57:25] <smarlow> Nihility: I rebased, just doing a clean build currently[22:59:48] <bstansberry> baileyje: a simple fix is to just not auto-deploy any more if there is a .failed[22:59:49] *** miclorb has joined #jboss-as7[22:59:58] <baileyje> I have that fix in. Testing now[23:00:29] <bstansberry> a bit harder is to put the correct timestamp on the .failed file[23:00:44] <bstansberry> and check for changes that way[23:01:44] * smarlow doing an "integration test"[23:02:25] <smarlow> Nihility: I'm rebased against Carlo's fixes and test results look good.[23:03:03] <Nihility> smarlow: excellent so ill now merge carlos and then yours[23:03:25] <smarlow> Nihility: thanks! :)[23:05:10] *** pferraro has quit IRC[23:09:29] * smarlow cool, I have a mysql DS setup (thanks Jesper), got some test data, will try the app later and see what happens with a better schema.[23:10:33] <bstansberry> this time i really am AFK[23:10:38] *** bstansberry is now known as bstans_afk[23:10:49] <bstans_afk> for a 1/2 hour or so[23:12:41] * smarlow commuting home[23:12:47] <Nihility> smarlow: i told andy to pop on here if he gets stuck[23:13:31] <smarlow> Nihility: cool, I'll be in traffic for a while but back on later. I just gave it a quick try and need to create some more user accounts it looks like.[23:14:13] <smarlow> I want to be setup to debug if needed this week[23:16:18] <jbossbot> git [jboss-as] push master d625b77.. Jason T. Greene Implement shutdown operation. Fix client EOF handling[23:16:19] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/dac58c9...d625b77[23:17:39] *** wolfc has quit IRC[23:18:33] *** irooskov has joined #jboss-as7[23:18:46] *** smarlow has quit IRC[23:19:51] *** maeste has quit IRC[23:24:03] *** irooskov_ has joined #jboss-as7[23:25:29] *** irooskov has quit IRC[23:27:32] *** emmanuel has quit IRC[23:28:44] <jbossbot> git [jboss-as] push master 8bd31aa.. Scott Marlow should be component.getPool().release(instance)....[23:28:44] <jbossbot> git [jboss-as] push master 9c965ba.. Carlo de Wolf Add test for PooledInstanceInterceptor[23:28:45] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/d625b77...9c965ba[23:32:32] <jbossbot> git [jboss-as] push master f98e1a4.. Scott Marlow improve SFSBXPCMap performance[23:32:32] <jbossbot> git [jboss-as] push master 9512363.. Scott Marlow also test that the persistence provider can discover the entities[23:32:32] <jbossbot> git [jboss-as] push master 346045c.. Scott Marlow log warning if multiple persistence.xml with the same name are found within the same deployment (as per JPA 8.2)[23:32:32] <jbossbot> git [jboss-as] push master 189df98.. Scott Marlow JBAS-8962 Found this bug with a new EPCPropagationTestCase.testNoTxEPCRemoveOperation that I'm adding[23:32:33] <jbossbot> jira [JBAS-8962] add XPC support [Coding In Progress (Unresolved) Sub-task, Major, Scott Marlow] https://issues.jboss.org/browse/JBAS-8962[23:32:33] <jbossbot> git [jboss-as] push master 7bfad4d.. Scott Marlow add EPCPropagationTestCase.testNoTxEPCRemoveOperation test for inheritance and Destroy[23:32:33] <jbossbot> git [jboss-as] push master fb25165.. Scott Marlow EPCPropagationTestCase.testNoTxEPCRemoveOperation add another SFSB[23:32:33] <jbossbot> git [jboss-as] push master 0a63813.. Scott Marlow fix compile error[23:32:33] <jbossbot> git [jboss-as] push master 27dd065.. Scott Marlow fix for getAttributeNamespace() problem caused by recent switch to using woodstox. Thanks Carlo for the fix[23:32:34] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/9c965ba...27dd065[23:35:20] *** epbernard has joined #jboss-as7[23:35:20] *** epbernard is now known as emmanuel[23:35:20] *** ChanServ sets mode: +v emmanuel[23:45:28] <stuartdouglas> dmlloyd: Do you have a chance to look at my env-entry stuff?[23:48:10] <opalka> dmlloyd, baileyje please take a look to this topic branch folks - https://github.com/ropalka/jboss-as/tree/sar-nested-archives-support[23:48:36] *** emuckenhuber has quit IRC[23:48:59] <opalka> dmlloyd, baileyje if there will be no objections about it, please pull upstream ;)[23:55:08] *** sannegrinovero has joined #jboss-as7[23:55:08] *** sannegrinovero has quit IRC[23:55:08] *** sannegrinovero has joined #jboss-as7[23:55:08] *** ChanServ sets mode: +v sannegrinovero[23:57:04] *** opalka has quit IRC[23:57:09] *** mbg is now known as mbg|away