[00:03:47] *** alexsmirnov has joined #jboss-as7
[00:08:13] *** smcgowan has quit IRC
[00:10:41] *** lanceball has quit IRC
[00:17:30] <emuckenhuber> bstansberry: hmm, ok looks like i just messed up the addressing...
[00:17:41] <bstansberry> :)
[00:21:34] *** tcrawley_ has joined #jboss-as7
[00:21:35] *** ChanServ sets mode: +v tcrawley_
[00:22:30] *** clebert has quit IRC
[00:23:08] *** aslak has quit IRC
[00:23:50] *** tcrawley has quit IRC
[00:23:56] <dmlloyd> what I was going to say was, it doesn't have to be an op
[00:24:11] <dmlloyd> if you could register a getter on the model node
[00:30:03] <emuckenhuber> dmlloyd: do you mean - register a getter on the model node registry?
[00:30:23] <dmlloyd> take attributes for example - they're registered with step handlers now, but there's no reason for that really
[00:30:48] <dmlloyd> in fact you could synthesize a read just by pulling all the read attributes, couldn't you?
[00:32:51] *** kevinpollet has quit IRC
[00:33:06] <emuckenhuber> yeah i would say so
[00:33:55] *** tcrawley_ has quit IRC
[00:33:57] <emuckenhuber> i mean beside the fact that we don't register many attributes so far
[00:35:43] *** adietisheim has quit IRC
[00:35:47] <dmlloyd> that's interesting
[00:35:55] <dmlloyd> I wonder, what is it we're reading, if not attributes? :)
[00:37:21] *** tcrawley has joined #jboss-as7
[00:37:21] *** ChanServ sets mode: +v tcrawley
[00:37:36] *** tcrawley has quit IRC
[00:41:25] <emuckenhuber> well we basically just set the children to undefined
[00:42:06] *** tcrawley has joined #jboss-as7
[00:42:09] *** tcrawley has quit IRC
[00:42:09] *** tcrawley has joined #jboss-as7
[00:42:09] *** ChanServ sets mode: +v tcrawley
[00:42:11] <emuckenhuber> that's why i actually would like to introduce this stricter concept of resources, so that this is getting clearer
[00:42:23] <dmlloyd> yeah that covers recursion of resources for sure
[00:42:51] <dmlloyd> just saying that if we define a resource as a collection of attributes, yet a read of a resource returns more than you can get via read-attribute, we have a problem
[00:43:24] *** clebert has joined #jboss-as7
[00:43:24] *** ChanServ sets mode: +v clebert
[00:43:24] *** clebert has quit IRC
[00:44:40] *** stuartdouglas has joined #jboss-as7
[00:44:46] <stuartdouglas> morning
[00:44:51] <emuckenhuber> oh i see - so you're referring to the fact that a recursive query would also contain the children?
[00:47:12] *** miclorb has joined #jboss-as7
[00:47:33] <dmlloyd> I thought that's what you were referring to! :)
[00:48:38] <dmlloyd> I'm just saying that it's redundant to have a specialized read operation for a resource (as opposed to a single, global one) when we already have read-attribute, since we could implement read-resource by reading each attribute in turn (and then recursing, if recursion is turned on)
[00:50:31] *** misty has joined #jboss-as7
[00:55:02] *** jamezp is now known as jamezp_
[00:55:12] *** misty has quit IRC
[00:55:24] *** jamezp_ is now known as jamezp
[00:56:05] *** jamezp has left #jboss-as7
[00:56:26] *** misty has joined #jboss-as7
[00:57:41] *** jamezp has joined #jboss-as7
[00:58:41] *** tcrawley_ has joined #jboss-as7
[00:58:41] *** ChanServ sets mode: +v tcrawley_
[01:01:13] *** tcrawley has quit IRC
[01:03:16] *** tcrawley has joined #jboss-as7
[01:03:16] *** ChanServ sets mode: +v tcrawley
[01:05:46] *** tcrawley_ has quit IRC
[01:06:24] <bstansberry> dmlloyd: attributes are not all registered
[01:06:45] <emuckenhuber> dmlloyd: yes, true it should certainly use the read-attribute (since it also contains the runtime/metric stuff)
[01:06:59] <emuckenhuber> although i'm less concerned about the attributes stuff rather than dynamic/virtual children
[01:08:57] <bstansberry> never mind my comment about attributes not all being registered. i was misunderstanding the conversation
[01:09:25] <emuckenhuber> hmm, well maybe we are all talking about different things :)
[01:10:05] <bstansberry> ok, re-read the start of the conversation again; that's what prompted my comment
[01:10:30] <bstansberry> emuckenhuber: i mean beside the fact that we don't register many attributes so far[5:38pm] dmlloyd: that's interesting
[01:10:30] <bstansberry> [5:38pm] dmlloyd: I wonder, what is it we're reading, if not attributes?
[01:10:51] *** tcrawley_ has joined #jboss-as7
[01:10:51] *** ChanServ sets mode: +v tcrawley_
[01:10:54] *** misty has quit IRC
[01:11:49] <bstansberry> just pointing out we're not requiring a mnr.register(R|RW)Attribute call for all attributes; we're determining what the attributes are from the model
[01:13:28] *** tcrawley has quit IRC
[01:14:10] *** jc3 has quit IRC
[01:15:39] <bstansberry> dmlloyd: semantics of rollback...
[01:15:51] <bstansberry> now we rollback if:
[01:15:59] <bstansberry> 1) any failure in Stage.MODEL
[01:16:33] <bstansberry> 2) any later failure if ROLLBACK_ON_FAIL
[01:16:49] <bstansberry> 3) handler throws any exception
[01:17:00] <bstansberry> 4) txcontrol calls rollback
[01:17:59] <bstansberry> but I believe we want to relax 3) to only auto-rollback on a RuntimeException, not OFE
[01:18:24] *** smarlow has joined #jboss-as7
[01:18:24] *** ChanServ sets mode: +v smarlow
[01:18:29] <bstansberry> oh, and 5) if persistence fails
[01:20:29] <bstansberry> haha, and 6) cancelled
[01:23:10] *** tcrawley has joined #jboss-as7
[01:23:10] *** ChanServ sets mode: +v tcrawley
[01:24:47] *** miclorb has quit IRC
[01:25:01] *** tcrawley_ has quit IRC
[01:27:48] *** tcrawley_ has joined #jboss-as7
[01:27:48] *** ChanServ sets mode: +v tcrawley_
[01:30:20] *** tcrawley has quit IRC
[01:31:26] *** misty has joined #jboss-as7
[01:31:45] *** tcrawley has joined #jboss-as7
[01:31:45] *** ChanServ sets mode: +v tcrawley
[01:32:33] *** miclorb_ has joined #jboss-as7
[01:33:02] *** tcrawley_ has quit IRC
[01:35:33] *** tcrawley_ has joined #jboss-as7
[01:35:34] *** ChanServ sets mode: +v tcrawley_
[01:35:58] *** sannegrinovero has joined #jboss-as7
[01:35:58] *** ChanServ sets mode: +v sannegrinovero
[01:36:55] *** tcrawley has quit IRC
[01:37:07] *** emuckenhuber has quit IRC
[01:40:29] *** jhalliday has joined #jboss-as7
[01:42:45] *** jwulf has joined #jboss-as7
[01:43:23] *** tcrawley has joined #jboss-as7
[01:43:23] *** ChanServ sets mode: +v tcrawley
[01:44:16] *** tcrawley_ has quit IRC
[01:47:51] <jhalliday> is master sorted out now or should I still avoid pulling from it?
[01:48:22] <smarlow> jhalliday: it got sorted out
[01:48:35] <jhalliday> k, thanks
[01:49:17] *** tcrawley_ has joined #jboss-as7
[01:49:17] *** ChanServ sets mode: +v tcrawley_
[01:51:28] *** alexsmirnov has quit IRC
[01:51:37] *** tcrawley has quit IRC
[01:53:18] *** tcrawley has joined #jboss-as7
[01:53:19] *** ChanServ sets mode: +v tcrawley
[01:54:16] *** dimitris_jboss has quit IRC
[01:55:17] *** tcrawley_ has quit IRC
[01:56:04] *** jpearlin has joined #jboss-as7
[02:03:31] *** tcrawley has quit IRC
[02:05:16] *** misty has quit IRC
[02:05:49] *** tcrawley has joined #jboss-as7
[02:05:50] *** ChanServ sets mode: +v tcrawley
[02:14:22] *** liweinan has joined #jboss-as7
[02:15:26] *** tcrawley_ has joined #jboss-as7
[02:15:27] *** ChanServ sets mode: +v tcrawley_
[02:17:07] *** tcrawley has quit IRC
[02:18:39] *** tcrawley_ has quit IRC
[02:19:26] *** tcrawley has joined #jboss-as7
[02:19:27] *** ChanServ sets mode: +v tcrawley
[02:23:24] *** sannegrinovero has quit IRC
[02:24:01] *** misty has joined #jboss-as7
[02:28:20] <bstansberry> dmlloyd: i'm off for dinner. I just pushed a temp "new-composites" branch with a commit that gets all the tests passing
[02:28:55] <bstansberry> i'll check back later; we'll see about merging that into new-controllers
[02:28:58] *** bstansberry is now known as bstans_afk
[02:30:04] *** tcrawley_ has joined #jboss-as7
[02:30:04] *** ChanServ sets mode: +v tcrawley_
[02:31:31] *** tcrawley has quit IRC
[02:31:54] *** tcrawley has joined #jboss-as7
[02:31:55] *** ChanServ sets mode: +v tcrawley
[02:34:40] *** tcrawley_ has quit IRC
[02:34:43] *** lgao has joined #jboss-as7
[02:35:57] *** h[a]gb4rd has joined #jboss-as7
[02:36:18] *** h[a]gb4rd has left #jboss-as7
[02:43:40] *** kcbabo has joined #jboss-as7
[02:43:40] *** ChanServ sets mode: +v kcbabo
[02:54:55] *** jamezp is now known as jamezp_afk
[03:04:35] *** asaldhan has left #jboss-as7
[03:04:44] *** tcrawley_ has joined #jboss-as7
[03:04:44] *** ChanServ sets mode: +v tcrawley_
[03:06:10] *** tcrawley has quit IRC
[03:09:01] *** sgilda has quit IRC
[03:14:19] *** tcrawley has joined #jboss-as7
[03:14:19] *** ChanServ sets mode: +v tcrawley
[03:17:01] *** tcrawley_ has quit IRC
[03:25:10] *** pferraro has joined #jboss-as7
[03:25:10] *** ChanServ sets mode: +v pferraro
[03:25:31] <dmlloyd> seems reasonable, bstans_afk
[03:28:38] *** jc3 has joined #jboss-as7
[03:28:38] *** ChanServ sets mode: +v jc3
[03:30:19] *** pferraro has quit IRC
[03:33:33] *** jamezp_afk has quit IRC
[03:33:42] *** jpearlin has left #jboss-as7
[03:39:57] <stuartdouglas> can someone merge my master? It fixes some JSF issues
[03:49:32] <misty> do you know where you are giving the preso?
[03:50:04] <misty> oops lol
[03:50:08] <misty> that was supposed to be in PM
[03:51:25] <dmlloyd> sure I can grab it
[03:54:58] *** smarlow has quit IRC
[04:00:38] *** stuartdouglas has quit IRC
[04:07:51] *** bstans_afk is now known as bstansberry
[04:08:26] <bstansberry> dmlloyd: that new-composites stuff is in new-controllers now.
[04:08:34] <bstansberry> time for expense reports :(
[04:16:55] *** stuartdouglas has joined #jboss-as7
[04:17:04] *** JimMaq has joined #jboss-as7
[04:17:31] <bobmcw> bstansberry: ah, crap, it is the end of the quarter, isn't it
[04:17:37] <bstansberry> yep
[04:40:27] *** lazarotti has quit IRC
[05:01:15] *** jamezp has joined #jboss-as7
[05:01:28] *** jamezp is now known as jamezp_afk
[05:01:55] <baileyje> bstansberry/dmlloyd:  Updated https://github.com/baileyje/jboss-as/commit/b45cf485913475ab3489e4f0899425b047e82693
[05:02:00] <jbossbot> git [jboss-as] b45cf48.. John E. Bailey Migrate update operation handlers to NewStepHandler.
[05:02:22] *** jamezp_afk is now known as jamezp
[05:02:51] *** jamezp is now known as jamezp_afk
[05:05:18] *** magesh has joined #jboss-as7
[05:09:22] *** jc3 has quit IRC
[05:27:59] *** frainone has quit IRC
[05:31:58] *** stuartdouglas has quit IRC
[06:07:11] *** stuartdouglas has joined #jboss-as7
[06:29:17] *** stuartdouglas has quit IRC
[06:33:22] *** magesh has quit IRC
[06:35:45] *** mlinhard has joined #jboss-as7
[06:43:16] <bstansberry> baileyje: ^^^ is merged into new-controllers, and I just rebased n-c to master and pushed it out
[06:44:01] *** bstansberry is now known as bstans_zzz
[06:45:28] *** stuartdouglas has joined #jboss-as7
[06:46:15] *** kcbabo has quit IRC
[07:06:43] *** magesh has joined #jboss-as7
[07:14:55] * nickarls is checking out the morning build to see if you have done anything else than messed up the repo in the last day or so ;-)
[07:17:40] <nickarls> ServerModelControllerImplUnitTestCase fails, is this a known issue?
[07:25:17] *** magesh1 has joined #jboss-as7
[07:28:09] *** magesh has quit IRC
[07:28:22] *** jwulf has quit IRC
[07:38:28] *** magesh1 has quit IRC
[07:38:45] *** magesh has joined #jboss-as7
[07:41:41] *** aslak has joined #jboss-as7
[07:41:41] *** ChanServ sets mode: +v aslak
[07:48:21] *** stuartdouglas has quit IRC
[07:55:01] *** mgoldmann has joined #jboss-as7
[07:55:02] *** ChanServ sets mode: +v mgoldmann
[07:56:53] *** misty has quit IRC
[07:58:05] *** jfclere has joined #jboss-as7
[07:58:05] *** ChanServ sets mode: +v jfclere
[08:07:14] *** emuckenhuber has joined #jboss-as7
[08:07:15] *** emuckenhuber has joined #jboss-as7
[08:07:15] *** ChanServ sets mode: +v emuckenhuber
[08:12:40] *** tdiesler has joined #jboss-as7
[08:12:40] *** ChanServ sets mode: +v tdiesler
[08:12:57] <ALR> Morning, tdiesler.  Just sent ya some stuff for review
[08:24:44] *** torben has joined #jboss-as7
[08:24:44] *** torben has quit IRC
[08:24:44] *** torben has joined #jboss-as7
[08:24:44] *** ChanServ sets mode: +v torben
[08:30:32] *** opalka has joined #jboss-as7
[08:30:32] *** ChanServ sets mode: +v opalka
[08:30:32] *** alesj has joined #jboss-as7
[08:30:51] <opalka> morning
[08:42:10] *** davidbos has joined #jboss-as7
[08:48:22] *** jhalliday has quit IRC
[08:48:44] *** dimitris_ has joined #jboss-as7
[08:48:45] *** dimitris_ has joined #jboss-as7
[08:48:45] *** ChanServ sets mode: +v dimitris_
[08:50:19] *** kevinpollet has joined #jboss-as7
[09:07:14] *** pilhuhn has joined #jboss-as7
[09:07:14] *** ChanServ sets mode: +v pilhuhn
[09:08:14] *** ALR has quit IRC
[09:08:20] *** maxandersen_food has quit IRC
[09:10:37] *** asoldano has joined #jboss-as7
[09:10:37] *** ChanServ sets mode: +v asoldano
[09:17:08] *** rmaucher has joined #jboss-as7
[09:20:48] *** miclorb_ has quit IRC
[09:22:14] *** wolfc has joined #jboss-as7
[09:22:15] *** ChanServ sets mode: +v wolfc
[09:24:16] *** adietisheim has joined #jboss-as7
[09:26:45] *** magesh1 has joined #jboss-as7
[09:28:07] *** magesh has quit IRC
[09:30:46] *** Jaikiran has joined #jboss-as7
[09:30:47] *** ChanServ sets mode: +v Jaikiran
[09:31:51] *** tcrawley_ has joined #jboss-as7
[09:31:51] *** ChanServ sets mode: +v tcrawley_
[09:34:38] *** tcrawley has quit IRC
[09:41:35] *** emuckenhuber has quit IRC
[09:42:52] *** maxandersen has joined #jboss-as7
[09:42:52] *** ChanServ sets mode: +v maxandersen
[09:47:05] *** jbosslog has quit IRC
[09:48:54] *** jbosslog has joined #jboss-as7
[09:53:01] *** jbosslog has quit IRC
[09:53:23] *** jbosslog has joined #jboss-as7
[09:53:58] *** emuckenhuber has joined #jboss-as7
[09:53:59] *** emuckenhuber has joined #jboss-as7
[09:53:59] *** ChanServ sets mode: +v emuckenhuber
[10:00:25] <liweinan> dmlloyd: ping
[10:11:29] *** jfclere has quit IRC
[10:14:54] *** jhalliday has joined #jboss-as7
[10:20:54] <asoldano> liweinan, David's likely sleeping at this time, mid of the night there
[10:29:59] <liweinan> asoldano: Thank you for telling me about it :-)
[10:37:46] <opalka> liweinan, yep, he's Wisconsin US time
[10:45:04] *** maeste has joined #jboss-as7
[10:45:04] *** ChanServ sets mode: +v maeste
[10:52:19] <tdiesler> ALR, moin. thanks I'll take a look
[11:10:14] *** vtunka has joined #jboss-as7
[11:10:14] *** ChanServ sets mode: +v vtunka
[11:41:44] *** magesh1 is now known as magesh
[11:42:58] *** jfclere has joined #jboss-as7
[11:42:58] *** ChanServ sets mode: +v jfclere
[11:46:54] *** galderz has joined #jboss-as7
[11:46:54] *** ChanServ sets mode: +v galderz
[12:06:08] *** miclorb_ has joined #jboss-as7
[12:12:42] *** AndyTaylor has joined #jboss-as7
[12:12:42] *** ChanServ sets mode: +v AndyTaylor
[12:15:37] *** kevinpollet has quit IRC
[12:29:26] *** JimMaq has quit IRC
[12:34:53] *** miclorb_ has quit IRC
[12:37:33] *** hbraun has joined #jboss-as7
[12:41:00] <davidbos> hbraun: in the following API I sometimes get an ArrayIndexOutOfBounds exception in the client:
[12:41:01] <davidbos>   public void onSuccess(DMRResponse result) {
[12:41:01] <davidbos>     ModelNode response = ModelNode.fromBase64(result.getResponseText());
[12:41:01] <davidbos> have you seen this before?
[12:41:31] <hbraun> you mean in "ModelNode response = ModelNode.fromBase64(result.getResponseText());"
[12:41:38] <davidbos> yes
[12:41:41] *** sannegrinovero has joined #jboss-as7
[12:41:41] *** ChanServ sets mode: +v sannegrinovero
[12:41:48] <hbraun> no, havn't seen it at all
[12:41:56] <davidbos> ok - then it must be me ;)
[12:42:01] <hbraun> do you have a stack strace?
[12:42:12] <hbraun> well, at that point you cannot do much wrong
[12:42:41] <hbraun> except sending wrong encoded base64 data
[12:42:45] <davidbos> hbraun: I've lost the trace, but will dig a little more
[12:42:51] *** maxandersen has quit IRC
[12:42:55] <davidbos> yeah, and I haven't modified that at all
[12:42:56] <hbraun> ah, you know what
[12:43:03] <hbraun> i guess I have seen it
[12:43:13] <hbraun> let me check
[12:43:24] *** kcbabo has joined #jboss-as7
[12:43:24] *** ChanServ sets mode: +v kcbabo
[12:43:34] <davidbos> it seems intermittent and I'm just trying to figure out what causes it...
[12:45:02] <davidbos> hbraun: actually I do have the trace, let me pastie it...
[12:45:53] <davidbos> hbraun: http://pastie.org/1980306
[12:46:44] <hbraun> yes, I remember it
[12:46:56] <hbraun> i need to dig alittle
[12:47:03] <hbraun> that error should have been fixed already
[12:47:11] <hbraun> >2months
[12:47:25] <davidbos> Could it be a browser issue - I'm currently using FF 3
[12:47:27] <hbraun> can you send me the base64 string ?
[12:47:36] <davidbos> Sure, will do
[12:47:37] <hbraun> no, i don't think so
[12:48:44] <davidbos> hbraun: let me file a JIRA and collect all the info there.
[12:48:50] <hbraun> +1
[12:49:09] <hbraun> we used to have a bug with the Base64 rotuine on the vclient side
[12:49:29] <davidbos> It's not always the same
[12:49:40] <davidbos> retrying gives you different errors
[12:49:48] <davidbos> like I now get:
[12:49:48] <davidbos> [ERROR] java.lang.RuntimeException: Illegal character 222
[12:49:48] <davidbos> [ERROR]     at org.jboss.dmr.client.DataInput.readUtfChar(DataInput.java:124)
[12:50:06] <davidbos> but it might be something I have done, although I don't see where yet
[12:50:42] <davidbos> I wonder why a base64 string contains character 222
[12:50:52] <davidbos> but anyway, I'll look a bit further
[12:51:11] <hbraun> interesting
[12:51:45] <hbraun> but if you add the base64 string to the issue, i might be able to reproduce and fix the problem
[12:51:52] <davidbos> yeah
[12:51:53] <davidbos> will do
[13:00:01] <hbraun> emuckenhuber: ping
[13:00:06] <hbraun> emuckenhuber: any update on this: https://issues.jboss.org/browse/AS7-748
[13:00:08] <jbossbot> jira [AS7-748] Subsystem "web": Expose effective configuration through domain management API [Open (Unresolved) Feature Request, Major, Emanuel Muckenhuber] https://issues.jboss.org/browse/AS7-748
[13:00:26] <hbraun> emuckenhuber: or is it on hold until the major refactoring os through
[13:00:30] <hbraun> ?
[13:09:48] *** asoldano is now known as asoldano_lunch
[13:13:58] *** kevinpollet has joined #jboss-as7
[13:14:02] *** sannegrinovero has quit IRC
[13:14:36] *** sannegrinovero has joined #jboss-as7
[13:14:36] *** sannegrinovero has quit IRC
[13:14:36] *** sannegrinovero has joined #jboss-as7
[13:14:36] *** ChanServ sets mode: +v sannegrinovero
[13:16:03] <davidbos> hbraun: https://issues.jboss.org/browse/AS7-912
[13:16:04] <jbossbot> jira [AS7-912] org.jboss.dmr.client.ModelNode.fromBase64() fails [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/AS7-912
[13:16:08] <hbraun> tnx
[13:18:00] *** davidbos has quit IRC
[13:19:40] *** torben has quit IRC
[13:19:57] *** torben has joined #jboss-as7
[13:19:57] *** ChanServ sets mode: +v torben
[13:20:47] *** davidbos has joined #jboss-as7
[13:21:55] *** tdiesler has quit IRC
[13:21:59] *** sgilda has joined #jboss-as7
[13:23:07] *** vtunka is now known as vtunka_
[13:23:22] *** vtunka_ is now known as vtunka
[13:23:39] *** emuckenhuber has quit IRC
[13:28:00] *** emuckenhuber has joined #jboss-as7
[13:28:00] *** emuckenhuber has joined #jboss-as7
[13:28:00] *** ChanServ sets mode: +v emuckenhuber
[13:28:15] <emuckenhuber> hbraun: pong
[13:28:35] <hbraun> emuckenhuber: yes
[13:28:42] <emuckenhuber> hmm, not really on this one - you want us to initialize all properties?
[13:29:50] <hbraun> yes, becaucse like this it looks liek an empty resource
[13:29:55] <hbraun> pretty much useless for a client
[13:30:01] <hbraun> unless it know all the defaults
[13:30:18] <hbraun> but I merely wanted to know the status and if it wil be doine at all
[13:33:48] <emuckenhuber> well there quite some attributes - actually i would like to remove some of them if possible ;)
[13:34:02] <emuckenhuber> but sure shouldn't be a big deal to initialize at least some of them for now
[13:34:13] <emuckenhuber> is that critical for you right now?
[13:34:25] <hbraun> critical no
[13:34:43] <hbraun> but if you want to get an idea of the props I would be interested in, take a look at current console
[13:34:51] <hbraun> subsystem web
[13:34:56] <hbraun> you'll see the form
[13:36:24] *** maxandersen has joined #jboss-as7
[13:36:25] *** ChanServ sets mode: +v maxandersen
[13:36:26] <emuckenhuber> i briefly looked at it yesterday after you sent the email - but i will look again ;)
[13:36:38] *** tdiesler has joined #jboss-as7
[13:36:38] *** ChanServ sets mode: +v tdiesler
[13:39:27] <emuckenhuber> hbraun: and i assume that this jira would also contain to make them read-write attributes right?
[13:39:35] <hbraun> +1
[13:43:07] *** jpederse has joined #jboss-as7
[13:43:08] *** ChanServ sets mode: +v jpederse
[13:43:45] *** sannegrinovero has quit IRC
[13:45:23] *** sannegrinovero has joined #jboss-as7
[13:45:23] *** ChanServ sets mode: +v sannegrinovero
[13:52:35] *** smarlow has joined #jboss-as7
[13:52:35] *** ChanServ sets mode: +v smarlow
[13:55:15] *** asoldano_lunch is now known as asoldano
[13:56:38] *** stansilvert has quit IRC
[14:07:09] *** jc3 has joined #jboss-as7
[14:07:09] *** ChanServ sets mode: +v jc3
[14:10:24] *** asaldhan has joined #jboss-as7
[14:10:25] *** ChanServ sets mode: +v asaldhan
[14:17:57] <dmlloyd> liweinan: pong
[14:18:01] <dmlloyd> good morning all
[14:18:47] <pilhuhn> hbraun, emuckenhuber  I am fighting to get more defaults in for most of the stuff. But initializied values are yoummy
[14:18:53] <pilhuhn> s/ou/u/
[14:19:43] <jbossbot> git [jboss-as] push master 9359a54.. Stuart Douglas Resource ref changes
[14:19:44] <jbossbot> git [jboss-as] push master c893706.. Stuart Douglas JSF fixes
[14:19:44] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/36cf522...c893706
[14:19:49] *** maxandersen has quit IRC
[14:20:10] <dmlloyd> meant to push that last night but forgot...
[14:22:50] <bobmcw> push -f it, for good measure
[14:25:38] <Jaikiran> dmlloyd: there's one more here https://github.com/jaikiran/jboss-as/tree/singleton-concurrency
[14:26:19] *** emuckenhuber has quit IRC
[14:26:50] <dmlloyd> looks like this patch includes a lot of whitespace reformatting
[14:28:41] <dmlloyd> looks fine, testing now
[14:28:57] *** tcrawley_ is now known as tcrawley
[14:33:28] *** emuckenhuber has joined #jboss-as7
[14:33:29] *** emuckenhuber has joined #jboss-as7
[14:33:29] *** ChanServ sets mode: +v emuckenhuber
[14:41:44] *** mmoyses has joined #jboss-as7
[14:41:44] *** ChanServ sets mode: +v mmoyses
[14:45:17] <jbossbot> git [jboss-as] push master 1d65add.. jaikiran Fix @AccessTimeout and @LockType processing on singleton beans
[14:45:17] <jbossbot> git [jboss-as] push master 1744cff.. jaikiran Fix NPE in ProxyTypeEqualsInterceptor
[14:45:17] <jbossbot> git [jboss-as] push master 1318fa3.. jaikiran Remove commented out (dead) code
[14:45:17] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c893706...1318fa3
[14:46:28] <opalka> dmlloyd, and this David https://github.com/ropalka/jboss-as/tree/ejb3-ws-invocation
[14:48:09] <dmlloyd> Jaikiran: would you mind looking over opalka's change too?  it gets into some EJB stuff
[14:48:33] <opalka> dmlloyd, they already reviewed it together with wolfc
[14:48:38] <dmlloyd> okay
[14:48:40] <dmlloyd> great
[14:49:43] <opalka> dmlloyd, see #ejb3 channel on RH IRC server
[14:55:17] <hbraun> dmlloyd: morning
[14:55:25] <hbraun> dmlloyd: any comments on https://issues.jboss.org/browse/AS7-762 ?
[14:55:26] <jbossbot> jira [AS7-762] Provide an operation to request  service status report  after server has been started [Open (Unresolved) Feature Request, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-762
[14:55:42] <hbraun> trivial or not?
[14:55:46] *** torben is now known as torben|meeting
[14:56:42] <dmlloyd> hmmm
[14:58:50] <dmlloyd> it's a little tricky, because the server status can change
[14:58:52] *** davidbos has quit IRC
[14:58:56] <dmlloyd> and does change
[14:59:10] <dmlloyd> it's not tied to boot
[14:59:45] <dmlloyd> we could probably have an operation to list services which are failed or not started though
[14:59:59] <dmlloyd> like a runtime query op
[15:01:11] <hbraun> i see what you mean
[15:01:21] <hbraun> the expectations are twofild aas well
[15:01:40] <hbraun> twofold
[15:01:58] <hbraun> most often you just need to know: did the server boot w/o errors
[15:02:06] <hbraun> binary decision
[15:02:45] <hbraun> then on the other hand (probably as a consequence) you would ask: why didn't it?
[15:03:17] <hbraun> your suggestion sounds like a suitable approach for both cases, right?
[15:03:18] *** galderz has quit IRC
[15:04:56] <hbraun> dmlloyd: basically I would need to know if it's feasible for 7.0 at this point
[15:05:34] <dmlloyd> yeah an op handler to read the current service status is very doable
[15:05:45] <liweinan> dmlloyd: good morning :-)
[15:05:49] <dmlloyd> the question of "did the server boot withotu errors" is what is hard :)
[15:05:59] <dmlloyd> liweinan: hello!
[15:06:10] *** davidbos has joined #jboss-as7
[15:06:17] <liweinan> dmlloyd: Do you know where to get the source code of jboss-threads?
[15:06:24] <liweinan> dmlloyd: I've tried http://anonsvn.jboss.org/repos/jbossas/projects/jboss-threads/tags/
[15:06:30] <dmlloyd> https://github.com/dmlloyd/jboss-threads
[15:06:43] <dmlloyd> correction
[15:06:47] <dmlloyd> http://github.com/jbossas/jboss-threads
[15:06:56] <dmlloyd> the first is my fork, the second is the official upstream
[15:07:10] <liweinan> dmlloyd:  Cool! Thank you :-)
[15:07:17] <hbraun> dmlloyd: what about "are there any pending service activations"?
[15:07:37] <hbraun> i.e. due to unmet dependencies?
[15:07:48] <dmlloyd> hbraun: yeah that would be included
[15:07:53] <dmlloyd> it could work one of two ways
[15:08:11] <dmlloyd> it could block until the container is "stable", which is to say that no changes will happen in the container without user intervention
[15:08:31] <dmlloyd> on a server startup, this would be after the whole server starts (when the first status report is logged in the log file)
[15:09:00] <dmlloyd> the other way it could work is to return right away with the current status and a flag indicating whether the state is transient or stable
[15:09:05] *** magesh has left #jboss-as7
[15:09:18] <dmlloyd> the risk there is you can get false positives for errors as services are often installed out-of-order
[15:09:38] *** lgao has quit IRC
[15:09:42] <hbraun> i think the first status report is what I am asking for
[15:10:30] <hbraun> basically you tell a bunch of server to start through the console and somehow need to get hold that particular status report
[15:10:36] <hbraun> for each of them
[15:11:00] <dmlloyd> ideally we'd model a server start as an operation, but that's not currently feasible
[15:12:02] *** davidbos has quit IRC
[15:13:52] *** davidbos has joined #jboss-as7
[15:15:19] *** opalka has quit IRC
[15:20:46] <jbossbot> git [jboss-as] push master 25d150b.. Richard Opalka refactoring SessionBeanComponentDescription - removing code duplicities
[15:20:46] <jbossbot> git [jboss-as] push master c9fc419.. Richard Opalka Providing hook ViewDescription.createViewConfiguration() in ee framework to allow extensibility...
[15:20:46] <jbossbot> git [jboss-as] push master 19e7893.. Richard Opalka partially resuscitating EJB3 invocation
[15:20:46] <jbossbot> git [jboss-as] push master 950a8bb.. Richard Opalka get rid of invoke() method on *BeanComponents...
[15:20:46] <jbossbot> git [jboss-as] push master b636fe5.. Richard Opalka refactoring EJB3 invocation
[15:20:47] <jbossbot> git [jboss-as] push master c5b4724.. Richard Opalka Do not create multiple JNDI bindings if WS endpoint view is created.
[15:20:47] <jbossbot> git [jboss-as] push master f2359fc.. Richard Opalka use proper MethodIntf for MDB
[15:20:47] <jbossbot> git [jboss-as] push master 2bbb0cb.. Richard Opalka use double-checked-locking pattern instead of it's expensive synchronized version in InvocationHandlerEJB3
[15:20:47] <jbossbot> git [jboss-as] push master 6ce64ff.. Richard Opalka remove JNDI binding code duplicities in EjbJndiBindingsDUP
[15:20:48] <jbossbot> git [jboss-as] push master 59703fe.. Richard Opalka provide hasJNDIBindings() method on EJBViewDescription
[15:20:48] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1318fa3...59703fe
[15:21:36] *** aslak has quit IRC
[15:22:09] *** aslak has joined #jboss-as7
[15:22:10] *** ChanServ sets mode: +v aslak
[15:24:37] *** fnasser has joined #jboss-as7
[15:24:57] *** tcrawley_ has joined #jboss-as7
[15:24:57] *** ChanServ sets mode: +v tcrawley_
[15:24:57] *** jamezp_afk has quit IRC
[15:25:27] *** maeste has quit IRC
[15:25:39] *** jamezp_afk has joined #jboss-as7
[15:27:06] *** tcrawley has quit IRC
[15:27:49] *** torben|meeting has quit IRC
[15:29:16] *** mlinhard has quit IRC
[15:30:54] *** galderz has joined #jboss-as7
[15:30:54] *** ChanServ sets mode: +v galderz
[15:31:11] *** mlinhard has joined #jboss-as7
[15:32:21] <Nihility> hi everyone
[15:32:23] <Nihility> check it out
[15:32:24] <Nihility> https://issues.jboss.org/browse/AS7-858
[15:32:26] <jbossbot> jira [AS7-858] Cannot load module when applying resolver results [Resolved (Done) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/AS7-858
[15:32:27] <Nihility> see source tab
[15:32:31] *** tcrawley_ is now known as tcrawley
[15:33:08] *** jhalliday has quit IRC
[15:34:00] <Jaikiran> nice!
[15:34:26] *** davidbos has quit IRC
[15:35:04] *** mlinhard has quit IRC
[15:35:10] *** mlinhard has joined #jboss-as7
[15:35:24] *** pgier has joined #jboss-as7
[15:35:24] *** ChanServ sets mode: +v pgier
[15:40:05] *** aslak has quit IRC
[15:40:52] *** aslak has joined #jboss-as7
[15:40:52] *** ChanServ sets mode: +v aslak
[15:42:58] *** alesj has quit IRC
[15:45:30] *** sebersole has joined #jboss-as7
[15:45:30] *** ChanServ sets mode: +v sebersole
[15:45:58] *** sannegrinovero has quit IRC
[15:56:04] *** aloubyansky has joined #jboss-as7
[15:56:34] *** frainone has joined #jboss-as7
[15:56:34] *** ChanServ sets mode: +v frainone
[15:57:52] *** sannegrinovero has joined #jboss-as7
[15:57:52] *** sannegrinovero has joined #jboss-as7
[15:57:52] *** ChanServ sets mode: +v sannegrinovero
[15:59:26] *** alesj has joined #jboss-as7
[16:00:39] *** stuartdouglas has joined #jboss-as7
[16:00:39] *** ChanServ sets mode: +v stuartdouglas
[16:03:15] *** sebersole has quit IRC
[16:09:12] *** maxandersen has joined #jboss-as7
[16:09:12] *** ChanServ sets mode: +v maxandersen
[16:09:42] *** maxandersen1 has joined #jboss-as7
[16:09:42] *** maxandersen has quit IRC
[16:12:57] *** liweinan has quit IRC
[16:14:21] *** alesj has quit IRC
[16:15:21] *** davidbos has joined #jboss-as7
[16:15:52] *** liweinan has joined #jboss-as7
[16:16:44] *** liweinan has quit IRC
[16:16:48] *** bstans_zzz is now known as bstansberry
[16:18:35] *** balunasj has joined #jboss-as7
[16:18:35] *** balunasj has joined #jboss-as7
[16:18:35] *** ChanServ sets mode: +v balunasj
[16:18:55] *** lanceball has joined #jboss-as7
[16:18:55] *** ChanServ sets mode: +v lanceball
[16:38:59] *** balunasj has quit IRC
[16:39:31] <maxandersen1> is it supported to have your jars with ejb definitions in ear/lib folder ?
[16:39:49] *** stansilvert has joined #jboss-as7
[16:39:53] <dmlloyd> yes and no
[16:40:07] <maxandersen1> dmlloyd: awesome ;)
[16:40:08] <dmlloyd> if I understand the spec correctly, they will not be recognized as EJB JARs directly
[16:40:30] <dmlloyd> but if you have a subdeployment JAR which references them, they would be added as part of that subdeployment
[16:41:01] <maxandersen1> dmlloyd: so that forces people to add stuff to the war manifest AND have their jar packaged *outside* the lib dir …that sounds counterintuitive ?
[16:41:13] <maxandersen1> i.e. is that intended or an accidental "bug" in the spec ?
[16:41:27] <dmlloyd> intended.  If you want to have EJB JARs, they shouldn't be in the ear/lib dir
[16:41:53] <dmlloyd> ear/lib is for libraries that are referenceable from your real subdeployments
[16:42:14] *** mgoldmann has quit IRC
[16:42:49] <maxandersen1> dmlloyd: so I have to declare that ejb jar in both applicaiton.xml AND war/manifest.mf ?
[16:43:14] <dmlloyd> that I'm not so sure about
[16:43:18] <bstansberry> emuckenhuber: how are things with global ops?
[16:43:22] <dmlloyd> I think if you package an EJB JAR normally it's picked up automatically
[16:43:32] <dmlloyd> maybe, maybe not
[16:43:35] <Jaikiran> assuming it's EJB30
[16:43:40] <Jaikiran> yes it's picked automatically
[16:43:46] <dmlloyd> okay, just making sure
[16:43:46] <Jaikiran> infact you don't even need a application.xml
[16:44:21] <Jaikiran> maxandersen1: the war/Maniesf.mf just needs to point to the jar containing the bean interfaces which can reside in the .ear/lib (if required)
[16:44:36] <emuckenhuber> bstansberry: one sec
[16:44:46] <maxandersen1> Jaikiran: ok and you are forced (by spec?) to ref it in your manifest.mf because it can't be in ear/lib and automatically picked up /
[16:44:47] <maxandersen1> ?
[16:44:59] <bstansberry> dmlloyd: baileyje: kkhan: emuckenhuber: new new-controllers pushed; rebased to master. also fixes a merge problem w/ my push last night
[16:45:03] <maxandersen1> Jaikiran: if it is in .ear/lib then I dont need to ref it right ?
[16:45:08] <Jaikiran> maxandersen1: no, you don't need the manifest.mf if it's in .ear/lib
[16:45:11] <Jaikiran> right
[16:46:35] <dmlloyd> but if your EJBs are defined in ear/lib they won't be picked up as a subdeployment, right?
[16:47:37] <Jaikiran> right
[16:48:17] <Jaikiran> just the @Local and @Remote can reside there, if there a @Stateless in there (for example) it won't be picked up as a EJb deployment
[16:48:27] <Jaikiran> it'll just act like another class in the CP
[16:50:37] <maxandersen1> Jaikiran: sounds broken ;)
[16:50:49] <Jaikiran> not really
[16:50:53] <maxandersen1> Jaikiran: but I guess there are tricky reasons for that "anomaly" :)
[16:50:57] <Jaikiran> .ear/lib isn't meant for "components"
[16:51:06] <Jaikiran> btw, it applies for other components too not just EJB
[16:51:28] <Jaikiran> it's supposed to act as a place for "libraries"
[16:51:42] <Jaikiran> but yeah, it's sometimes confusing from end user p.o.v
[16:51:59] <baileyje> bstansberry: Should I start on the query operations?
[16:52:07] <Jaikiran> i mean when they end up with a @stateless or other component in .ear/lib
[16:52:46] <bstansberry> baileyje: one sec
[16:53:01] <maxandersen1> Jaikiran: the problem is that because of this "rule" and AS7s new strictness wars/ears that deploy fine on other AS's and Glassfishes doesn't work now ;)
[16:53:15] <maxandersen1> Jaikiran: at least on my quick basic testing.
[16:53:31] <Jaikiran> maxandersen1: if it used to work on AS6, then we should be able to get it working on AS&
[16:53:33] <Jaikiran> AS7
[16:53:45] <Jaikiran> because from what i know AS6 had these exact same semantic
[16:54:01] <Jaikiran> if you have an app, then feel free to point it to me
[16:54:55] <Jaikiran> btw, there's a slightly related feature request to this which I think might be affecting you https://issues.jboss.org/browse/AS7-306
[16:54:56] <bstansberry> baileyje: one issue from the add stuff: seems like the boot time semantics are different
[16:54:57] <jbossbot> jira [AS7-306] EJBs contained in an EAR are not accessible to WARs in the same EAR [Open (Unresolved) Enhancement, Major, jaikiran pai] https://issues.jboss.org/browse/AS7-306
[16:55:08] <Jaikiran> although can't really say without looking at the app
[16:55:20] <baileyje> bstansberry: In what way?
[16:55:22] <bstansberry> i.e. before some handlers wouldn't change runtime unless it was boot time
[16:55:31] <maxandersen1> Jaikiran: this is the exact issue i'm looking at
[16:55:38] <bstansberry> now, they change runtime, but just don't add the DUP
[16:55:47] <maxandersen1> Jaikiran: didnt know there were an issue for it ;) but all come from fbricon
[16:55:48] <Jaikiran> maxandersen1: i plan to fix it by CR1
[16:56:02] <baileyje> Was the previous supposed to be true?
[16:56:03] <bstansberry> which means if they execute after boot, things probably end up in a broken state
[16:56:38] <baileyje> Yeah.  That is likely true for the subsystems.
[16:56:46] <baileyje> not for the rest of the adds though
[16:57:05] <bstansberry> yeah, i just mean the ones that install DUPs
[16:57:05] <dmlloyd> it might be that only some subsystems would actually result in problems, but each should be evaluated to make sure...
[16:57:22] <bstansberry> this leads into the issue of restart-required
[16:57:54] <dmlloyd> yeah.... that
[16:58:19] *** Jaikiran is now known as Jaikiran|bbl
[16:58:37] <bstansberry> we were handling that before; there's logic in the old OperationContext around it
[16:58:39] <baileyje> we all dance around that one
[16:58:57] <dmlloyd> yeah because it turns out to be not quite as black-and-white as we originally assumed
[16:59:12] <dmlloyd> there are cases where a change should happen anyway
[16:59:20] <dmlloyd> or cases where it should be up to the user to decide
[16:59:39] <bstansberry> the latter I wanted to use an operation-header
[16:59:43] <dmlloyd> and of course cases where changes should not happen, however this often means the server is in an inconsistent state
[16:59:56] <maxandersen1> Jaikiran: if you fix that issue then https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 is "wrong" ? "This means that WARs (and other EJB jars) do not have access to classes defined in an EJB jar unless an explicit dependency is defined" ?
[17:00:39] <dmlloyd> I'm wondering if the "right" behavior isn't just to set a flag and carry on executing all operations regardless, and just report "restart-required" on every subsequent result
[17:00:50] <dmlloyd> the only thing we'd disallow is installing DUPs
[17:01:06] <dmlloyd> because at least this way the services are in a proper state
[17:02:54] *** jamezp_afk is now known as jamezp
[17:03:26] <bstansberry> so restart-required becomes simply an indicator that the runtime is out of sync with the model (who knows how)
[17:03:26] *** kevinpollet has quit IRC
[17:03:47] <dmlloyd> yeah, realistically though only the DUPs are really out of sync
[17:04:01] <dmlloyd> that's the only thing we *have* to restart for, when all's said and done
[17:04:02] <bstansberry> all sorts of things might be out of sync
[17:04:30] *** AndyTaylor has quit IRC
[17:04:40] <dmlloyd> even extension adds/removes don't require a restart, technically, unless they affect DUP
[17:04:51] <bstansberry> actually this leads to a semi-tangent
[17:04:57] <dmlloyd> well I guess we don't have clean unload of extensions
[17:05:06] <dmlloyd> so that presently requires a restart
[17:05:21] <bstansberry> a notion that was in alpha1 and died along the way
[17:05:24] <dmlloyd> DUPs require a restart because of deployments - though *really* they only require a restart of the deployer service...
[17:06:07] <bstansberry> basically being able to declare at the top level that the ops in a plan should be applied to servers via restart, rather than directly
[17:06:29] <dmlloyd> so it's "execute these then restart"?
[17:06:35] <bstansberry> that really handles the kinds of uses cases i'm most concerned about
[17:06:42] <dmlloyd> or "restart then execute during boot"?
[17:07:04] <dmlloyd> the former implies the latter, though indirectly via config persistence
[17:07:44] <bstansberry> e.g. change the binding associated with the "public" interface
[17:08:11] <bstansberry> for standalone mode, it would really need to be the former
[17:08:55] <bstansberry> for domain (which is what I had in alpha1) it's about how the DC/HC applies the ops to the servers
[17:09:05] <dmlloyd> well, it's how you define restart
[17:09:13] <dmlloyd> most of the time "reload" would suffice
[17:09:21] <dmlloyd> whic standalone can do no prob
[17:09:56] <bstansberry> ok, but even then I think your former case is easier
[17:10:22] <bstansberry> modify model but not runtime, persist, reload
[17:10:25] <dmlloyd> yeah
[17:10:38] <dmlloyd> I just obsessively explore every decision branch
[17:10:50] <bstansberry> sure, good habit
[17:11:49] *** mlinhard has quit IRC
[17:12:11] *** clebert has joined #jboss-as7
[17:12:11] *** ChanServ sets mode: +v clebert
[17:12:29] <bstansberry> but back to the idea of continuing to apply ops, and restart required just being a flag
[17:13:38] <bstansberry> trying to think about nasty ways that will break things :-)
[17:14:04] <dmlloyd> well it's not unlike what happens when you install updates on an OS
[17:14:18] <dmlloyd> you replace libc, the kernel, etc without rebooting, it's just a matter of time
[17:14:26] <dmlloyd> so, well, you reboot
[17:14:33] <dmlloyd> but sometimes you can kinda hang on
[17:14:49] <bstansberry> yeah
[17:15:08] <dmlloyd> tbh though adding a reload flag could really mitigate that, especially if we keep deployment time down
[17:15:30] <dmlloyd> or just encouraging users to do composite ops with "reload" at the end in these cases
[17:15:30] *** mmoyses is now known as mmoyses_
[17:16:36] <pilhuhn> Hey,
[17:16:47] <bstansberry> yeah, that's a good way to handle it for standalone
[17:16:56] <pilhuhn>  /socket-binding=foo used to have a port-offset - is that gone?
[17:17:25] <bstansberry> grr
[17:17:37] <bstansberry>  /socket-binding-group=foo has port-offset
[17:17:55] <bstansberry> the grr was because starting reply w/ a "/" doesn't work :)
[17:18:10] <dmlloyd> / just start with //
[17:18:10] *** jamezp has quit IRC
[17:18:37] <pilhuhn> ah crap that is a standalone vs domain thing
[17:18:46] *** jamezp has joined #jboss-as7
[17:19:06] <pilhuhn> bstansberry I see it in standalone mode, but was looking at domain before
[17:19:55] <pilhuhn> This is somewhat cool - starting the other mode to check something just takes a few seconds - not minutes
[17:20:36] <bstansberry> yeah, the testsuite now has domain tests where two host controllers and 3 servers total are started and stopped for each test class
[17:20:47] <bstansberry> and it's not totally painful
[17:21:18] <bstansberry> although big fat test classes with lots of test methods are encouraged :)
[17:22:09] <pilhuhn> :)
[17:22:22] <hbraun> bstansberry, dmlloyd: i didn't follow, but are thinking about adding a reloadRequired flag?
[17:22:31] <hbraun> or reboot required
[17:22:34] <dmlloyd> on replies, yes
[17:22:39] <dmlloyd> dunno could be either really
[17:22:52] <dmlloyd> maybe some things require a full reboot, or will later, like patching
[17:22:59] <bstansberry> right
[17:22:59] <hbraun> on replies? you mean operation response?
[17:23:04] <dmlloyd> yes
[17:23:13] <hbraun> ah, i was thinking about that too the other day
[17:23:31] <bstansberry> perhaps a response-headers section?
[17:23:42] <dmlloyd> seems reasonable
[17:23:50] <hbraun> just to indicate that the changes are not applied imediatly?
[17:24:13] <dmlloyd> they may be applied immediately, but that application may cause instability if the server isn't restarted
[17:25:00] <bstansberry> do we need to provide more info?
[17:25:06] <hbraun> so we have different meanings here:
[17:26:05] <hbraun> let me check the mailing list, we discussed this already
[17:27:08] <hbraun> cant find it anymore
[17:27:13] <hbraun> meh
[17:28:03] *** OndrejZizka has quit IRC
[17:28:26] <hbraun> thinking about the different scopes
[17:29:01] <bstansberry> "Configuration and user friendlyness"
[17:30:01] <hbraun> ah, right
[17:30:01] <hbraun> tnx
[17:30:30] <hbraun> yes, that's what I was looking for
[17:30:30] <bstansberry> maybe, thread had the words restart in it
[17:30:31] <hbraun> a) modifications to the configuration
[17:30:31] <hbraun> b) applying the new configuration to runtime components.
[17:30:35] <asaldhan> bstansberry: in the domain directory, is there a directory where the files are synched across the entire domain?   is it the content dir?
[17:30:37] <hbraun> curently we prevent a)
[17:30:45] <hbraun> in most cases
[17:30:57] <hbraun> because we don't have an answer to b)
[17:31:22] <hbraun> so, if the ideas just mention offer a solution for b)
[17:31:31] <hbraun> then we could allow a) in most cases, right?
[17:31:43] <bstansberry> asaldhan: that's where deployment content goes, and yes the domain mgmt layer will ensure that hosts that need stuff that ends up there have it
[17:31:53] *** kevinpollet has joined #jboss-as7
[17:32:01] <baileyje> bstansberry: I can update the adds with DUPs to only run at boot for now
[17:32:10] <bstansberry> it's not like farming though
[17:32:19] <asaldhan> bstansberry: example, I need to store an encryption key.  If I put it in the content directory, will it get synched across?  the refs will be in the domain model
[17:32:29] <bstansberry> baileyje: i'd say don't change until we resolve this
[17:32:39] <baileyje> ok..
[17:32:59] <bstansberry> asaldhan: no. that directory is not scanned. it relates to how the domain handles deployment operations
[17:33:15] <asaldhan> bstansberry: so there is no support for local stuff in the domain config?
[17:33:32] <asaldhan> bstansberry: I want to store a key locally that gets replicated across
[17:34:43] *** maxandersen1 has quit IRC
[17:35:02] *** maxandersen has joined #jboss-as7
[17:35:03] *** ChanServ sets mode: +v maxandersen
[17:35:48] <bstansberry> right now the only thing we are replicating is deployment content. other things we regard as being a provisioning issue users have to handle themselves
[17:36:37] <dmlloyd> in particular we should probably not come within 1000 miles of key management without really, really a lot of careful thought
[17:36:42] <asaldhan> bstansberry: the usecase is unified encryption. the settings will be in domain model.  But the key has to be stored somewhere.
[17:36:47] <dmlloyd> or bruce schneier will come and kick our asses
[17:37:03] <bstansberry> asaldhan: use the path functionality we provide
[17:37:39] <asaldhan> bstansberry: any references to "path func" ?
[17:37:52] <bstansberry> i.e. the location of the key can be relative to a path, and the domain config provides a lot of flexibility for resolving that path
[17:37:59] <jpederse> asaldhan: what about BASE64 in the model ?
[17:38:24] <dmlloyd> no keys in the model
[17:38:27] <jpederse> k
[17:38:33] <dmlloyd> no private or secret keys anyway
[17:38:39] <dmlloyd> public keys maybe are ok but ugly at best
[17:38:39] <asaldhan> dmlloyd: right. we cannot keep keys inside model
[17:38:46] <dmlloyd> passwords == secret keys
[17:40:25] <jamezp> dmlloyd: Any reason I shouldn't start working on the logging/message changes on the domain-controller?
[17:40:32] <bstansberry> asaldhan: look at TransactionSubsystemAdd in the transaction's module, follow from RELATIVE_TO
[17:40:54] <bstansberry> the jboss-7.0.xsd path element describes some background
[17:40:57] <bstansberry> as well
[17:41:11] <dmlloyd> jamezp: that is also in the midst of refactor
[17:41:22] <bstansberry> basically, in the config, users create a <path/> element and give that path a name
[17:41:45] <bstansberry> we create a Service<String> that can be injected into services that need to know the path
[17:42:25] <bstansberry> services that need to know the path usually add a relative-to="the.path.name" to their config
[17:42:47] <jamezp> dmlloyd: Glad I asked then. How about ee or embedded? (assuming all the domain-* is in refactor mode)
[17:42:49] <bstansberry> i.e. as an attribute in their config
[17:43:03] <dmlloyd> jamezp: those should be OK
[17:43:11] <asaldhan> bstansberry: thanks for the pointers.
[17:43:59] <bstansberry> baileyje: if you're blocking, yes query handlers are ok
[17:44:19] <baileyje> ok.   i will start on those
[17:47:28] *** alexsmirnov has joined #jboss-as7
[17:48:32] <asaldhan> bstansberry: the relative to looks good to me.  question is if I store files somewhere, will it get replicated in the domain.
[17:48:40] <asaldhan> bstansberry: or the admin has to do it manually
[17:50:39] <bstansberry> asaldhan: manually
[17:51:00] <bstansberry> we provide no replication services other than for deployments
[17:51:00] <asaldhan> bstansberry: ok. thanks for clarification.
[17:51:53] <asaldhan> bstansberry: noob question.  I am wondering if I can have a deployment with the key created. then it will get replicated.  deployment will be a derivative of jar. correct?
[17:52:33] *** OndrejZizka has joined #jboss-as7
[17:52:33] *** ChanServ sets mode: +v OndrejZizka
[17:52:46] <bstansberry> yes, any deployment that we'd replicate would have to be a jar
[17:52:53] *** maxandersen has quit IRC
[17:53:30] <asaldhan> bstansberry: got it.
[17:53:33] <bstansberry> but the content folder is an opaque blob; you can't refer to things inside it trivially via the config
[17:53:38] <dmlloyd> asaldhan: the replication mechanism isn't necessarily immune to eavesdropping attacks.  We'll need to scrutinize it carefully before recommending it as a key deployment mechanism
[17:54:07] <dmlloyd> in particular the content files would tend to be world-readable
[17:54:21] <asaldhan> dmlloyd: if we replicate the key. it wont be in the clear. It will be over ssl or massively encrypted/masked
[17:54:43] <dmlloyd> and then stored in a world-readable file on the target system :)
[17:54:49] <asaldhan> dmlloyd: no
[17:55:00] <asaldhan> dmlloyd: when I say a key, it is never in the clear
[17:55:05] <asaldhan> dmlloyd: I am not such a dumb guy
[17:55:11] <bstansberry> guys, we're not replicating it for 7.0 which is 3 weeks away, so.....
[17:55:41] <dmlloyd> never suggested you were, but even smart guys screw up key distribution routinely so I'm very cautious
[17:55:49] <asaldhan> dmlloyd: :)  missed that.
[17:56:22] <asaldhan> dmlloyd: the weak link is the key.  That is why I am thinking about how to do it without the complexity. :)
[17:56:55] <asaldhan> dmlloyd: if it has to be done manually - so be it.  I think manual distribution of the key is one justification to keeping it secure over the n/w
[17:58:00] <asaldhan> bstansberry: we can do this for 7.1.  No problem there.
[17:58:02] <dmlloyd> I think for 7.0 we should go manual
[17:58:10] <asaldhan> dmlloyd: yeah. agreed.
[17:58:52] <asaldhan> dmlloyd: it is going to be one circular loop to secure the key.  You bring in certs from the keystore to secure the key for example but the damn keystore needs securing the keystore pass.
[17:59:07] <dmlloyd> yeah, that's always the way of it
[17:59:17] <asaldhan> dmlloyd: so its one wretched b$tch. :)
[17:59:31] <dmlloyd> add to that, java doesn't have any really great way to ensure security of files it creates
[17:59:41] <dmlloyd> though that situation has improved a little in 1.6
[17:59:49] <dmlloyd> won't really be solved until 1.7 though
[18:00:30] <asaldhan> dmlloyd: in AS5, we used a keystore to encrypt/decrypt the key.  But it was not foolproof because the keystore password was just using masking.
[18:00:34] *** asoldano has quit IRC
[18:00:50] <asaldhan> dmlloyd: dont have real easy answers.
[18:01:45] *** vtunka has quit IRC
[18:03:36] <dmlloyd> bstansberry: so maybe instead of two flags we just have one that can have values restart-required, reboot-required, or everything-is-still-fine-here
[18:04:52] <bstansberry> i'm seeing two slightly different things though
[18:04:59] <bstansberry> state and effect
[18:05:10] <bstansberry> your last post sounds like a state
[18:05:15] <dmlloyd> yes
[18:05:30] <dmlloyd> effect is only useful if you know it ahead of time, right?
[18:05:47] <bstansberry> which could be transmitted w/ every response when it's not everything-is-still-fine-here
[18:05:49] <dmlloyd> I want to do XYZ, oh it would require a restart, do I want to continue?
[18:05:58] <dmlloyd> yeah
[18:06:28] <bstansberry> yeah, right now, i'm just thinking about responses, we have to cover telling folks in advance too
[18:07:00] <bstansberry> what i meant by "effect" is something specific to a particular op that caused a state transition
[18:07:02] *** smcgowan has joined #jboss-as7
[18:07:09] *** ChanServ sets mode: +v smcgowan
[18:07:36] <dmlloyd> I see what you're saying, but what would we (or the user) use it for?
[18:07:46] <dmlloyd> as opposed to the running state
[18:08:09] <dmlloyd> do they gain something from knowing the first operation which causes a restart to be required?
[18:08:34] <bstansberry> i.e. along the lines of hbraun 's 3 cases: I did nothing, I did something but may not be stable, everything-is-still-fine-here
[18:08:51] <bstansberry> but yeah, i think you're right, user doesn't gain a lot by knowing that
[18:08:55] <dmlloyd> yeah I guess that's good info...
[18:08:57] <dmlloyd> heh
[18:09:02] <dmlloyd> opinion swap complete!
[18:09:07] <hbraun> bstansberry: the second one is useless
[18:09:08] <bstansberry> lol
[18:09:44] <asaldhan> bstansberry: for the domain mode,  what is jboss.server.data.dir?    I only see data in standalone
[18:09:44] <hbraun> i vote fro runtimeChangeApplied=<true|false>
[18:10:03] <dmlloyd> affects-runtime
[18:10:16] <hbraun> did-affect-runtime
[18:10:22] <hbraun> is-applied
[18:10:43] <dmlloyd> runtime-affected-applied-is-affected-now-and-before
[18:10:44] <bstansberry> hbraun: then the 3rd case can be figured out by whether there was a change from everything-is-still-fine-here to restart-required?
[18:11:09] *** pilhuhn is now known as pil-dinner-afk
[18:11:26] <hbraun> bstansberry: you lost me
[18:11:31] <hbraun> bstansberry: what are you saying?
[18:11:44] <bstansberry> asaldhan: in domain mode, the servers, e.g. one name "server-one" would be in domain/servers/server-one
[18:11:46] <hbraun> (trying make IE7 look good)
[18:12:06] <bstansberry> jboss.server.data.dir would point to domain/servers/server-one/data
[18:12:31] <asaldhan> bstansberry: got it. thx.
[18:12:58] <jamezp> hbraun: If you can make IE7 look good, you truly are a miracle worker.
[18:13:34] <hbraun> jamezp: don't put too much hope in me
[18:13:35] <bstansberry> hbraun: i was thinking in terms of two pieces of info: the state of the server, and what happened with a particular operation
[18:13:46] <hbraun> ah, yes
[18:13:49] <hbraun> bstansberry: +1
[18:13:57] <jamezp> hbraun: It's not you I lack the hope in :-)
[18:14:04] <bstansberry> state of server = restart-required, reboot-required, or everything-is-still-fine-here
[18:14:15] <bstansberry> affect of operation is: applied to runtime or not
[18:14:23] <hbraun> bstansberry: yes, that's it
[18:14:39] <hbraun> but there is no diff. in restart/rebot-required
[18:14:42] <hbraun> is it?
[18:14:43] *** alesj has joined #jboss-as7
[18:15:04] <bstansberry> ah, hbraun get's to learn the cool stuff
[18:15:20] <bstansberry> boot a server, and then in the CLI execute :reload
[18:15:31] <hbraun> what?
[18:15:40] <hbraun> reload?
[18:15:45] <bstansberry> takes about 200-300 ms and essentially restarts everything
[18:15:53] *** kevinpollet has quit IRC
[18:15:57] *** aloubyansky has quit IRC
[18:16:02] <hbraun> and includes a the new config I assume
[18:16:20] <bstansberry> right, it re-reads the standalone.xml
[18:16:33] <hbraun> but the service wiring remains?
[18:16:38] <hbraun> why is it so fast?
[18:16:39] <bstansberry> gets rebuilt
[18:16:56] <bstansberry> because a huge % of our boot time is classloading
[18:16:56] <dmlloyd> it's fast because all the classes are already loaded
[18:17:02] <dmlloyd> and class init
[18:17:04] <hbraun> yihaa
[18:17:07] <hbraun> awesome shit
[18:17:18] <hbraun> i need that button in the console
[18:17:23] <dmlloyd> deployments are likely to be approximately the same speed though
[18:17:30] *** kevinpollet has joined #jboss-as7
[18:17:38] <bstansberry> good point
[18:17:52] <dmlloyd> which is why it is important for us to make deployment as efficient as possible
[18:17:57] <dmlloyd> and that has been under-tested
[18:18:25] <hbraun> taking everything that has been proposed into consideration I would say that approach with the different flags sounds pretty good
[18:18:54] <bstansberry> that's for responses
[18:19:14] <bstansberry> but users would probably like a clue about these things ahead of time :-)
[18:19:19] <dmlloyd> so here's what's on the table:
[18:19:24] <dmlloyd> a) response-headers
[18:19:43] <dmlloyd> b) a per-operation flag indicating whether the change had a runtime effect
[18:20:04] <dmlloyd> c) a per-operation flag indicating whether the change causes a reload or reboot to be necessary
[18:20:17] <dmlloyd> d) an overall response flag indicating whether reload or reboot is necessary
[18:20:32] <dmlloyd> e) b/c possibly being combined into one
[18:20:36] <dmlloyd> I think that's it
[18:20:39] <asaldhan> dmlloyd: bstansberry:  if u guys are interested, this doc will be where I figure things out:  http://community.jboss.org/wiki/JBossAS7PasswordMaskingAndEncryption
[18:21:19] <hbraun> dmlloyd: i think b) and c) expressed as runtime-headers
[18:21:23] *** rmaucher has left #jboss-as7
[18:21:42] <hbraun> sorry, response-headers
[18:23:11] <hbraun> dmlloyd, bstansberry: are we talking about 7.0?
[18:23:17] <dmlloyd> yes
[18:23:17] <bstansberry> hbraun: yeah
[18:23:30] <hbraun> bstansberry, dmlloyd: you guys kick ass
[18:23:35] <dmlloyd> response-headers would only apply to the overall operation though
[18:23:43] <dmlloyd> I guess?
[18:23:48] <bstansberry> hbraun: the encouragement is appreciated :-)
[18:23:59] <hbraun> overall?
[18:24:06] <hbraun> whata do you mean with overall response headers?
[18:24:10] <bstansberry> we're tallking about composite ops
[18:24:18] <hbraun> so, a single header
[18:24:30] <hbraun> for the composite op
[18:25:00] <bstansberry> the way composites work though is the response for each step looks like a normal response
[18:25:24] <hbraun> IMO it needs to be a header for each step
[18:25:33] <bstansberry> yes
[18:25:35] <hbraun> doesn't make much sense otherwise
[18:26:05] <hbraun> plus you have an implicit address
[18:26:28] <hbraun> you know the response-header describes the state of a server and which one
[18:26:28] <bstansberry> TBH, I think it's easier to implement that way anyway
[18:26:56] <hbraun> 200-300ms
[18:27:01] <hbraun> i still cannot believe it
[18:27:26] * bstansberry fears it's all an illusion and we just haven't discovered why
[18:27:32] <bstansberry> not really :-D
[18:27:40] <hbraun> should it be in the CLI already?
[18:27:58] <bstansberry> as a convenience op?
[18:28:07] <hbraun> I cannot find it
[18:28:22] <bstansberry> it's a low-level op
[18:28:51] <hbraun> ah, it's standalone only
[18:29:13] <bstansberry> you can do /host=local/server=server-one:reload
[18:29:30] <bstansberry> ah. maybe not?
[18:29:39] <hbraun> yeez, 280ms
[18:29:52] *** mmoyses_ is now known as mmoyses
[18:29:53] <bstansberry> I bet that's invalid though
[18:30:03] <hbraun> what do you mean=
[18:30:05] <hbraun> ?
[18:30:12] <bstansberry> yeah, reload in domain mode has a bogus semantic
[18:30:23] <bstansberry> we should disable it until it's correct
[18:30:45] <bstansberry> problem is, the reload goes to a "ConfigurationPersister" object to read the config
[18:30:51] <hbraun> if its that fast you can almost implictly apply it to all op's
[18:31:07] <bstansberry> in standalone mode, that object reads the config file
[18:31:36] <hbraun> btw, did you realize that CLI cannot auto complete the server name?
[18:31:37] <bstansberry> in domain mode, that object will return the config steps initially provided by the HC when the server was launched
[18:31:40] <hbraun> > /host=local/server=
[18:31:43] <bstansberry> yeah
[18:31:50] <hbraun> a know issue?
[18:31:51] <bstansberry> dunno if there is a JIRA for that
[18:32:20] <hbraun> I'll create one
[18:32:32] <bstansberry> thanks
[18:32:54] <bstansberry> are we set on the responses? move on to metadata?
[18:33:23] <hbraun> https://issues.jboss.org/browse/AS7-916
[18:33:24] <jbossbot> jira [AS7-916] CLI does not auto-complete server names [Open (Unresolved) Feature Request, Major, Alexey Loubyansky] https://issues.jboss.org/browse/AS7-916
[18:33:43] <hbraun> bstansberry: metadata?
[18:34:14] <bstansberry> info in the operation descriptions to give advance warning about likely effect of ops
[18:34:58] *** fnasser has quit IRC
[18:35:08] <bstansberry> although maybe that can wait, i.e. if you're not going to make use of it for 7.0
[18:37:26] <bstansberry> back to the responses: do you guys agree that we include no response-headers for the default case? (i.e. everything-is-fine, change was applied to runtime)
[18:40:13] <hbraun> bstansberry: are you thinking of netwrok overhead?
[18:40:47] <bstansberry> that and just general noisiness
[18:40:53] <hbraun> well, if everything is fine and the changes applied then we can probably leave it out
[18:40:59] <hbraun> agreed
[18:42:39] *** kevinpollet has quit IRC
[18:43:32] *** sannegrinovero has quit IRC
[18:52:05] *** emuckenhuber has quit IRC
[18:53:22] *** jfclere has quit IRC
[19:00:11] <dmlloyd> bstansberry: that problem (reload in domain mode) is one reason why I still don't like the asymmetry of config persistence - I want to revisit that in AS 8
[19:01:18] <bstansberry> you mean go ahead and persist the server config?
[19:02:06] * bstansberry thinks not as that seems like a pretty simple thing to change
[19:03:04] *** bstansberry is now known as bstans_afk
[19:04:22] <smarlow> Is anyone else getting arquillian errors running  tests in testsuite2/spec?
[19:04:31] * smarlow got "Arquillian has previously been attempted initialized, but failed. See previous exceptions for cause"
[19:06:26] <dmlloyd> tdiesler: we have a new MSC version coming down the pipe
[19:06:43] <dmlloyd> tdiesler: it breaks compat for listeners
[19:06:53] <dmlloyd> so you may want to start adjusting things now in OSGi
[19:07:19] <aslak> smarlow, look at the first test case ran.. it should have the real exception
[19:07:46] <smarlow> aslak:  I'll try that, thanks
[19:10:28] <smarlow> aslak:  the real exception is here http://pastie.org/1981630  "IllegalStateException: No implementation found for org.jboss.arquillian.spi.client.container.DeployableContainer, please check your classpath"
[19:10:46] * smarlow checking his classpath :)
[19:12:30] *** Jaikiran|bbl is now known as Jaikiran
[19:14:19] <hbraun> bstans_afk: check alex's comments on https://issues.jboss.org/browse/AS7-916
[19:14:20] <jbossbot> jira [AS7-916] CLI does not auto-complete server names [Resolved (Incomplete Description) Feature Request, Major, Alexey Loubyansky] https://issues.jboss.org/browse/AS7-916
[19:19:18] *** kevinpollet has joined #jboss-as7
[19:22:52] <dmlloyd> I am going to change MSC listener behavior on parent/child services
[19:23:14] <dmlloyd> listeners added to child ServiceTargets are no longer automatically inherited
[19:23:36] <dmlloyd> this _should_ only affect a couple parts of the code but just wanted to give a heads-up
[19:23:59] <dmlloyd> some folks had previously indicated that the inheritance behavior for listeners is surprising
[19:25:04] *** galderz has quit IRC
[19:26:36] *** dimitris_ has quit IRC
[19:30:50] *** Jaikiran has quit IRC
[19:38:28] *** alesj has quit IRC
[19:42:15] *** tdiesler has quit IRC
[19:48:00] *** baileyje has quit IRC
[19:51:36] *** kevinpollet has quit IRC
[19:53:29] *** clebert has quit IRC
[19:54:10] *** baileyje has joined #jboss-as7
[19:54:10] *** ChanServ sets mode: +v baileyje
[20:03:20] *** ALR has joined #jboss-as7
[20:03:21] *** ChanServ sets mode: +v ALR
[20:04:24] *** balunasj has joined #jboss-as7
[20:04:25] *** balunasj has joined #jboss-as7
[20:04:25] *** ChanServ sets mode: +v balunasj
[20:05:28] *** balunasj is now known as balunasj_mtg
[20:10:31] <bobmcw> dmlloyd: hey, so RootLoggerService ends up ripping the logs out from under my own service while it's logging
[20:10:58] <dmlloyd> you mean during the switchover from boot to regular logging?
[20:11:01] <bobmcw> yah
[20:11:06] <dmlloyd> yeah it's a problem
[20:11:10] <bobmcw> my boot-time Service is still churning
[20:11:15] <bobmcw> and goes silent
[20:11:22] <dmlloyd> same problem actually existed on 5/6
[20:11:25] <dmlloyd> presumably 4
[20:11:33] <dmlloyd> but since service startup was always linear it wasn't noticable
[20:12:02] <bobmcw> should I depend on RootLoggerService
[20:12:09] <bobmcw> so mine fires after the switchover?
[20:12:18] <dmlloyd> no, because the logging subsys is optional
[20:12:31] <bobmcw> optional dep on RLS?
[20:12:36] <bobmcw> hrm
[20:12:41] <bobmcw> what's the solution?
[20:12:44] <dmlloyd> you could do that, but it'd really delay startup
[20:12:52] <dmlloyd> solution is to tell the guy who designed that to fix it
[20:13:02] <bobmcw> dmlloyd: hey, dmlloyd said I should talk to you about fixing logging
[20:13:15] <dmlloyd> bobmcw: oh really? well... that guy's an idiot...
[20:13:18] <bobmcw> I know, right?
[20:13:30] <bobmcw> and a criminal! http://sanfrancisco.cbslocal.com/2011/05/26/technician-faces-charges-of-cleaning-out-bay-area-atms/
[20:13:36] <dmlloyd> keeps designing things that are almost awesome
[20:13:51] <dmlloyd> haha
[20:14:21] <bobmcw> somewhere we could jam dependencies that get added to RLS?
[20:14:35] <bobmcw> so he doesn't crank until boot-time logging things are done
[20:14:54] <bobmcw> like we do with unit.addAttachToList( WEB_DEPENDENCIES, something )
[20:14:58] <bobmcw> I know we have no unit...
[20:15:12] <bobmcw> to throw deps forward
[20:15:43] <dmlloyd> the real fix is to change the way logging config works so there isn't a boot phase at all
[20:15:53] <bobmcw> do it!
[20:15:58] <dmlloyd> it's on the list
[20:16:19] <dmlloyd> for your immediate personal purposes you could just remove the logging subsystem and use the boot.log
[20:16:28] <dmlloyd> tbh the boot log config is probably good enough for most people :)
[20:16:36] *** balunasj_mtg has quit IRC
[20:16:38] <bobmcw> just erase the <subsystem> for logging?
[20:16:42] <dmlloyd> yeah
[20:16:48] <bobmcw> 'k, might do that
[20:17:01] <dmlloyd> I hope to have this fixed for 7.0 but tbh it's not an official priority as of now
[20:17:11] <dmlloyd> I will try nonetheless
[20:17:51] *** bstans_afk is now known as bstansberry
[20:18:15] <bobmcw> my FooSubsystemAdd action is guaranteed a sane logger for it's lifecycle?
[20:18:24] <bobmcw> if not my Services it spins up?
[20:18:35] <dmlloyd> yeah the loggers themselves are fine
[20:18:48] <bstansberry> hbraun: thanks. I re-opened AS7-916 and assigned to emuckenhuber as it's in the same general are he's working now
[20:18:48] <dmlloyd> it's just the handlers and the level configs which are changed in mid-startup
[20:18:49] <jbossbot> jira [AS7-916] CLI does not auto-complete server names [Reopened (Unresolved) Feature Request, Major, Emanuel Muckenhuber] https://issues.jboss.org/browse/AS7-916
[20:18:53] <bobmcw> I'm trying to dump version/build/etc info for users who never know what version they're running
[20:19:11] <hbraun> bstansberry: good
[20:19:27] <smarlow> ALR:  I got the same error on AS7 upstream/master
[20:20:10] <ALR> smarlow: Running on my Hudson
[20:20:37] <ALR> http://jboss.hudson.alrubinger.com/job/AS7/12/
[20:20:41] <smarlow> ALR:  thanks, it will be interesting if its just me
[20:21:01] <ALR> Yeah, I mean that error comes up when you've got something missing from your ClassPath
[20:22:59] <mmoyses> bstansberry: Nihility: do you have time to discuss AS7-838?
[20:23:00] <jbossbot> jira [AS7-838] Allow individual security domains to be deployed [Open (Unresolved) Feature Request, Major, Marcus Moyses] https://issues.jboss.org/browse/AS7-838
[20:23:52] <Nihility> mmoyses: go ahead
[20:24:23] <mmoyses> Nihility: do we allow xml files to be deployed currently?
[20:24:27] <Nihility> nope
[20:24:44] <Nihility> we could though if we had a good reason
[20:24:52] <Nihility> so far nothing has made sense for them
[20:25:27] <bobmcw> we have hacks to allow deploying .yml files....
[20:25:31] <bobmcw> loose yaml files
[20:25:35] <mmoyses> being able to deploy a security domain along with applications or even by themselves has always been a nice feature for customers
[20:25:36] <bobmcw> screw archives!
[20:25:53] <smarlow> ALR:  I only get the error when i change into the testsuite2/spec folder and run from there.
[20:25:56] <Nihility> if you deploy a security domain by itself
[20:26:02] <Nihility> then it contradicts the domain model
[20:26:14] <ALR> smarlow: Ah I see.  Lemmme look at that
[20:26:16] <mmoyses> we could probably make it so that they would never override a domain set in the config file (standalone and domain.xml)
[20:26:39] <Nihility> deployed in an app might make sense
[20:26:43] <Nihility> its a bit sketchy though
[20:26:46] <Nihility> because its unmanagable
[20:27:14] <mmoyses> why is it unmanageble
[20:27:15] <jpederse> mmoyses: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/001836.html
[20:27:21] <mmoyses> ?
[20:28:21] <mmoyses> jpederse: right
[20:28:33] <mmoyses> jpederse: that would work
[20:29:11] <jpederse> mmoyses: we havn't had a use-case yet where it wouldn't work - "just" needs to be implemented
[20:29:17] <hbraun> bye guys
[20:29:21] <hbraun> have a nice weekend
[20:29:22] <mmoyses> Nihility: allow it only with web app or ear would be fine i guess
[20:29:45] <Nihility> mmoyses: its unmanagable because its not in the domain model
[20:29:48] *** hbraun has quit IRC
[20:30:00] <mmoyses> jpederse: i mean, i would be fine with that format as well
[20:30:07] <Nihility> mmoyses: so anything thats not in the domain model is a "developer" feature
[20:30:11] <jpederse> mmoyses: lets not open this discussion again - I closed the -ds.xml thread already
[20:30:16] <bstansberry> mmoyses: unmanageable == cannot appear in the management resource tree in the same location as other security domains whose configuration will be persisted if changes are made
[20:30:30] <mmoyses> i see
[20:30:31] <jpederse> mmoyses: so here is my -1
[20:30:40] <asaldhan> Nihility: ideally all security domains have to be part of the domain model. But in rare cases, I think we need to provide the option of deploying sd as part of the apps.
[20:30:57] <Nihility> asaldhan: yeah i think i just need to understand the use case
[20:30:58] <asaldhan> Nihility: discourage it.  Mainly for border cases.
[20:31:10] <jpederse> asaldhan: read the above link
[20:31:22] <Nihility> im not outright against unmanaged features
[20:31:30] <Nihility> i just like to make sure we need them
[20:31:33] <Nihility> thats all
[20:32:14] <Nihility> bobmcw: cool what are the yaml files for?
[20:32:14] <jpederse> Nihility: we will spend more time on implementing all the cases than the .cli archive... and we will end up with something a lot worse
[20:33:35] <asaldhan> jpederse: probably the SD may fit there.
[20:34:02] <Nihility> asaldhan: imo i think we should nail down common scenarios where people need this feature (other than we used to be able to )
[20:34:23] <Nihility> asaldhan: who knows maybe there is a better way to solve them
[20:34:28] <jpederse> asaldhan: yeah - just have a create-security-domain command in the management api
[20:34:30] <asaldhan> Nihility: as long as we can implement in the future, it should be fine.
[20:35:31] <mmoyses> Nihility: asaldhan: most likely the use case of deploying SDs is a developer's need. right now we have webservices needing this so they can run their testsuite i believe
[20:35:58] <bstansberry> they don't need this to run a testsuite
[20:36:16] <bstansberry> you don't need it for your testsuite, so they don't either
[20:37:26] <asaldhan> bstansberry: is the domain model hot deployable assuming users find the 3sec startup time a chore?
[20:37:51] <asaldhan> bstansberry: historically we had the issue of central config needing server restart.
[20:38:02] <asaldhan> bstansberry: that would tick users off.
[20:38:07] <Nihility> asaldhan: you can make changes live but its up to the subsystem to decide whether to apply them
[20:38:32] <Nihility> asaldhan: so if you have a way to do it in picketbox you can just add support for that
[20:38:48] <bobmcw> Nihility: our yaml files point to ruby apps elsewhere on disk, + other config
[20:38:53] <asaldhan> Nihility: that would just be clear and form a new SD.
[20:38:54] <bobmcw> we also deploy security domains with apps
[20:39:00] <bobmcw> in violation of the domain model, yay!
[20:39:08] <Nihility> bobmcw: hahaha
[20:39:12] * bobmcw is in ur appserver, mucking ur models
[20:39:17] <asaldhan> bobmcw: ur team is such a shame. ;)
[20:39:31] <asaldhan> bobmcw: disobeying conventional things. ;)
[20:39:44] <bobmcw> we're allowing our users to leverage convention over configuration... in XML
[20:39:47] <ALR> smarlow: How about just running from testsuite2/ ?
[20:39:49] <ALR> Not spec
[20:40:22] <bobmcw> Nihility: thankfully your models are not so canonized that we can't find ways to subvert them :)
[20:40:38] <bobmcw> with asaldhan's help, at times
[20:41:31] <bobmcw> Nihility: a lot of what we do is an implicit 1:1 mapping between app and domain
[20:41:36] <bobmcw> ruby users are sometimes a simple type
[20:41:50] <bobmcw> so delineating "inside" vs "outside" application scope is just pedantically annoying to them
[20:44:04] <Nihility> yeah the important bit is not taking away stuff from the admin
[20:44:05] <bobmcw> I might almost be happy mutating the domain model, if that were allowed from a DeploymentUnitProc
[20:44:08] <asaldhan> mmoyses: we should definitely consider live changes of the security domain model
[20:44:11] <bobmcw> in response to app deployment
[20:44:16] <asaldhan> mmoyses: refresh the SD
[20:44:18] <Nihility> big complaint in the past is that it was not very easy to manage without breaking open apps
[20:44:22] <Nihility> config all over the place
[20:44:23] <Nihility> etc etc
[20:44:33] <bobmcw> Nihility: sure, I can grok that
[20:44:37] <Nihility> developer v admin basically
[20:44:38] <Nihility> :)
[20:44:52] <bobmcw> ruby is closer to the "what admin?" end of that curve
[20:44:57] <Nihility> haha
[20:45:05] <bobmcw> so far in its lifecycle, there really aren't too many Ruby Application Deployer and Admins
[20:45:09] <mmoyses> Nihility: bstansberry: I guess this feature can be dropped then. if customers complain i'll raise the topic again ;)
[20:45:28] <Nihility> mmoyses: sounds like we should reexamine in 7.1
[20:45:41] <mmoyses> yeah, np
[20:46:11] <asaldhan> Nihility: may get raised for eap6.
[20:46:28] <smarlow> ALR:  I'll try that
[20:46:30] <Nihility> mmoyses: asaldhan another possible solution would be to introduce a special developer oriented deployment based thing which only had a certain set of limited security options, like just password files or something
[20:46:31] <asaldhan> Nihility: the community can live with single config
[20:46:33] <bobmcw> Nihility: so, our use-case is an app that needs a security domain that ends up being used for only and exactly that one app
[20:46:48] <bobmcw> we can express everything we need to in 4 lines of .yml inside that app
[20:46:57] <bobmcw> and turn that into the forest of PicketBox Service<T>
[20:47:00] <bobmcw> or a SecDomainAdd
[20:47:03] <bobmcw> on behalf of the app
[20:47:23] <bobmcw> but I don't want to have to tell folks to go click 19 times in a GUI, or edit an XML file
[20:47:30] <bobmcw> that's un-rubytastic
[20:47:34] <Nihility> bobmcw: ah ok, so if every app uses say a kerberos server you get like 50 domains and 50 connections?
[20:47:45] <bobmcw> remember, I'm talking 1-app shops
[20:47:53] <bobmcw> if they have 50 and kerb, then sure, we'll point them to XML
[20:48:05] <Nihility> ok i follow
[20:48:11] <bobmcw> but if they want 1 app, and an admin portion locked down by a UserRolesLoginModule or whatnot, with an app-specified set of users
[20:48:12] <smarlow> ALR:  same error
[20:48:22] <Nihility> so the goal is basically black box deployment
[20:48:25] <bobmcw> I'd like to leverage all the Picket stuff that already exists, on their behalf
[20:48:27] <Nihility> it gets its own things
[20:48:42] <smarlow> ALR:  oops. trying again
[20:48:52] <bobmcw> so, right now, we perform the same work as SecDomainAdd
[20:48:58] <bobmcw> but from a DeployUnitProc
[20:49:10] <bobmcw> likewise, we allow apps to deploy queues and topics
[20:49:29] <bobmcw> and sometimes we have to deploy app-specific queues to support some higher-order abstractions that we provide for async functionality
[20:49:42] <bobmcw> so, we do the same work as QueueAdd, but in a DeployUnitProc
[20:49:47] <bobmcw> standing up un-managed queues
[20:49:54] <Nihility> hmm maybe a compromising solution is that we give an admin the abiilty to restrict unmanaged content
[20:50:00] <bobmcw> I'd *love* to have them visible in the admin console
[20:50:07] <bobmcw> but I understand by doing it the way I am, we don't get that
[20:50:23] <Nihility> we might be able to show unmanaged resources
[20:50:30] <Nihility> in like a read-only runtime only view
[20:50:33] <Nihility> for a deployment
[20:50:51] <bobmcw> sure, works for me
[20:50:56] <Nihility> we should certainly revisit this whole area in 7.1
[20:50:58] <smarlow> bstansberry:  what are the command line options for running the testsuite2/spec tests?  I tried " mvn install -DskipTests=false" in testsuite2 and that didn't start the spec tests
[20:51:00] <bobmcw> yes please :)
[20:51:14] <Nihility> dmlloyd for example has mentioned an idea of letting domain override these kinds of things as well
[20:51:23] <bobmcw> just remember our use case is such that we provide functionality that gets implemented, by happenstance, by JaaS or JMS
[20:51:32] <bobmcw> but we care f'all about JavaEE, or specs
[20:51:37] <bobmcw> we just want a queue, or an authenticator
[20:51:47] <bstansberry> smarlow:  mvn install -DallTests
[20:51:59] <smarlow> thanks :)
[20:52:01] <bobmcw> user might never actually see the queue or the authenticator directly
[20:52:11] <bobmcw> it's just used in OurMagicService that they end up using
[20:52:17] <bobmcw> because OMS requires some async, or auth
[20:52:22] <bstansberry> tdiesler didn't like the -DskipTests=false approach, so we shifted to profiles triggered by -DallTests
[20:52:52] *** clebert has joined #jboss-as7
[20:52:52] *** ChanServ sets mode: +v clebert
[20:53:58] <Nihility> asaldhan: mmoyses so yeah we need to address the broad topic in 7.1
[20:54:04] *** pgier has quit IRC
[20:54:26] <Nihility> asaldhan: mmoyses: but when time comes around, if you could remember certain scenarios that you see int he field, be sure to jot them down on a wiki somewhere
[20:54:30] <smarlow> alr:  looks like a user error :)  The error doesn't happen if I run from testsuite2 with the right ( mvn install -DallTests) option
[20:54:42] <mmoyses> Nihility: sure
[20:55:36] <smarlow> ALR:  I was running from testsuite2/spec with the -DskipTests option, which is not supported anymore
[20:57:31] <asaldhan> Nihility: u figured out chicago's conf room?
[20:57:40] <asaldhan> Nihility: there is a receptionist who can help u out.
[20:58:08] *** mbg has joined #jboss-as7
[20:58:08] *** ChanServ sets mode: +v mbg
[20:58:38] *** jamezp is now known as jamezp_afk
[21:04:04] *** jpederse has quit IRC
[21:04:29] <ALR> smarlow: Ah, incomplete bug report :)
[21:04:34] * ALR back in a bit
[21:10:02] *** lazarotti has joined #jboss-as7
[21:20:39] <jbossbot> git [jboss-as] push master 03803a0.. Alexey Loubyansky refactoring of command arguments representation and parsing: limit names to full and short, avoid unnecessary re-parsing of the arguments during tab-completion
[21:20:39] <jbossbot> git [jboss-as] push master 4b42124.. Alexey Loubyansky refactoring in command arguments and command handlers with arguments and argument tab-completers to simplify the wiring between and remove duplicated code
[21:20:39] <jbossbot> git [jboss-as] push master 9fc96a1.. Alexey Loubyansky AS7-785 don't ignore unrecognized command arguments, fixed deploy command in batch mode, in batch edit command fixed the index for the command being edited and added to the candidates
[21:20:41] <jbossbot> jira [AS7-785] Setting runtime-name seems to have no effect [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/AS7-785
[21:20:41] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/59703fe...9fc96a1
[21:33:49] <aslak> is there a option to start as with all 'user deployments' disabled ?
[21:34:44] *** emuckenhuber has joined #jboss-as7
[21:34:44] *** emuckenhuber has joined #jboss-as7
[21:34:44] *** ChanServ sets mode: +v emuckenhuber
[21:38:08] *** opalka has joined #jboss-as7
[21:38:09] *** opalka has joined #jboss-as7
[21:38:09] *** ChanServ sets mode: +v opalka
[21:48:19] *** adietisheim has quit IRC
[21:50:20] *** jamezp_afk has quit IRC
[21:50:40] *** adietisheim has joined #jboss-as7
[21:52:39] <jbossbot> git [jboss-as] push master 3eb2183.. bstansberry at jboss dot com Remove override of normal maven.test.skip.exec handling that wasn't actually disabling tests any more
[21:52:39] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/9fc96a1...3eb2183
[21:52:43] *** mmoyses has quit IRC
[21:58:29] *** bobmcw has quit IRC
[21:58:46] *** smcgowan has quit IRC
[22:00:26] *** kcbabo has quit IRC
[22:11:43] *** jamezp has joined #jboss-as7
[22:31:59] *** kkhan has quit IRC
[22:35:04] *** bobmcw has joined #jboss-as7
[22:35:04] *** ChanServ sets mode: +v bobmcw
[22:35:30] *** davidbos has quit IRC
[22:50:29] *** baileyje has quit IRC
[22:56:46] *** baileyje has joined #jboss-as7
[22:56:46] *** ChanServ sets mode: +v baileyje
[22:59:13] *** emuckenhuber has quit IRC
[23:07:29] *** wolfc has quit IRC
[23:17:45] *** lanceball has quit IRC
[23:21:14] <stuartdouglas> morning
[23:21:24] <jamezp> morning
[23:45:00] *** clebert has quit IRC
[23:46:15] *** tcrawley has quit IRC

   May 27, 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 | >