May 19, 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 | >
May 19, 2011 NOTICE: This channel is no longer actively logged.
[00:01:26] *** misty has joined #jboss-as7[00:01:35] <stuartdouglas> Turns out I have managed to write a bug into the proxies where if the method has 6 or more parameters it generates invalid bytecode[00:03:02] *** maeste has quit IRC[00:04:37] <stuartdouglas> ah, there is no ICONST_6 instruction, that would do it[00:05:01] <jamezp> stuartdouglas: Not a bug, a warning there are too many parameters in that method ;-)[00:10:47] <pgier> sorry if this is a stupid question, but I keep getting a test failure while building the arquillian container managed module[00:10:53] <pgier> http://pastebin.com/7dyfSYzj[00:11:37] <pgier> I don't see the same failure in hudson, but I'm not sure what could be different in my local environment[00:12:04] <stuartdouglas> I see that sometimes if I have another AS instance running[00:13:43] <pgier> stuartdouglas: thank you much! one of my previous builds must not have shut down the server correctly[00:15:13] <stuartdouglas> dmlloyd: I have updated classfilewriter versions in my master for AS7 and jboss-invocation, which will fix the proxy problem[00:15:40] <dmlloyd> pgier: you should compare notes with baileyje...[00:17:40] *** kcbabo has quit IRC[00:21:24] <jbossbot> git [jboss-as] push master 1b13aac.. Andrew Lee Rubinger [AS7-730] Fix error message[00:21:25] <jbossbot> jira [AS7-730] Arquillian Managed Container Startup Timeout Message is wrong [Pull Request Sent (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-730[00:21:25] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/655e309...1b13aac[00:30:51] *** mbg has quit IRC[00:37:51] *** tcrawley has quit IRC[00:40:21] *** frainone is now known as frainone_away[00:40:47] *** tcrawley has joined #jboss-as7[00:40:47] *** ChanServ sets mode: +v tcrawley[00:46:09] *** smarlow has joined #jboss-as7[00:46:09] *** ChanServ sets mode: +v smarlow[00:46:09] *** jamezp has quit IRC[00:48:14] *** jamezp has joined #jboss-as7[01:13:01] *** lazarotti has quit IRC[01:20:49] <ALR> Nihility: ARQ Beta just released.[01:21:07] <ALR> FYIs all. So expect some new ARQ AS7 containers soonly.[01:21:17] <ALR> And unified ARQ subsystem[01:21:44] <dmlloyd> my expectations are high[01:21:45] <dmlloyd> ![01:22:17] <ALR> We're behind the ball in AS7 timewise[01:22:21] <ALR> As Jas notes[01:22:42] <ALR> Aslak and I team-coding starting tomorrow on the AS7 containers again[01:23:08] * ALR glad that SW is stable in any case[01:23:16] <ALR> We went Beta2 today[01:25:12] <dmlloyd> behind the ball is good in billiards[01:25:17] <dmlloyd> not so good in, say, soccer :)[01:26:02] <ALR> If you're on the offense, it's good.[01:27:04] <ALR> Also tdiesler has some neat stuff in his fork.[01:27:13] <ALR> So tomorrow should be pretty exciting.[01:27:19] <ALR> Once we fight Maven and POM changes.[01:27:22] *** fnasser has quit IRC[01:27:26] <ALR> (Artifacts GAVs moved, etc)[01:28:43] <bobmcw> maven is awesome, you heathen![01:28:50] * bobmcw can't keep a straight face[01:29:23] <ALR> I used to think that I had no right to complain about a piece of software I ultimately elected to use.[01:29:36] *** stuartdouglas_ has joined #jboss-as7[01:29:36] *** stuartdouglas_ has joined #jboss-as7[01:29:36] *** ChanServ sets mode: +v stuartdouglas_[01:29:36] <ALR> And then I remembered how much fun complaining is.[01:30:03] *** _baleyje has joined #jboss-as7[01:30:03] *** _baleyje has joined #jboss-as7[01:30:03] *** ChanServ sets mode: +v _baleyje[01:30:37] *** frainone_away has quit IRC[01:30:38] *** stalep has quit IRC[01:30:38] *** stuartdouglas has quit IRC[01:30:39] *** baileyje has quit IRC[01:30:40] *** _baleyje is now known as baileyje[01:30:40] *** stuartdouglas_ is now known as stuartdouglas[01:31:17] *** lazarotti has joined #jboss-as7[01:37:20] *** stalep has joined #jboss-as7[01:38:40] *** frainone has joined #jboss-as7[01:38:40] *** ChanServ sets mode: +v frainone[01:45:16] *** smarlow has quit IRC[01:45:52] *** JimMa has joined #jboss-as7[01:48:23] *** alexsmirnov has quit IRC[01:49:37] *** frainone is now known as frainone_dinner[01:53:38] <misty> ping stuartdouglas[01:53:44] <stuartdouglas> misty: pong[01:53:51] <misty> morning[01:53:58] <misty> how long do you reckon your talk will be next Friday?[01:54:09] <stuartdouglas> probably about an hour[01:54:17] <misty> also can you give me a one-paragraph summary of it so that I can make the meeting invitation?[01:54:32] <stuartdouglas> sure, I will email it to you today[01:54:37] <misty> I wonder if it would be too much to ask for you to give an AS7 one and a CDI one[01:54:46] <misty> AS7 will appeal to a much more generalized audience[01:55:23] <stuartdouglas> I should be able to do that[01:57:13] <misty> it seems like a lot to ask of you[01:57:18] <misty> two talks in one day[01:57:24] <misty> it is totally up to you[01:57:42] <stuartdouglas> It should be ok[01:57:59] <stuartdouglas> who is the audience for these talks?[01:57:59] <misty> cool, I will set them up after I get your email[01:58:11] <misty> tech writers and GSS mostly[01:58:46] <misty> knowing that jboss GSS people are extremely technical[01:59:13] <misty> we also have a few Java devs here[01:59:28] *** rawbdor has joined #jboss-as7[02:13:54] *** aslak has quit IRC[02:31:01] *** kcbabo has joined #jboss-as7[02:31:01] *** ChanServ sets mode: +v kcbabo[02:39:11] <stuartdouglas> dmlloyd: I think I haves sorted out the DriverManager issues, I am just running the full set of tests now[02:39:57] <dmlloyd> great[02:40:10] <dmlloyd> the sooner that's behind us the better imo[02:40:14] <stuartdouglas> It's horrible[02:40:19] <stuartdouglas> but it seems to work[02:42:06] <stuartdouglas> so what is the next priority? I have the JSF and the proxy bug fixed in my master[02:42:28] <dmlloyd> I pushed the JSF deal already[02:42:33] <dmlloyd> oh, not the new one though[02:42:48] <stuartdouglas> just that thing where I was not reading all the config files[02:43:04] <dmlloyd> hmmmm[02:43:04] *** jamezp is now known as jamezp_afk[02:43:13] <dmlloyd> a little weird that we're actually closing in on finishing EE/EJB[02:43:34] <stuartdouglas> there is still the timer service, and ejb remove methods[02:43:46] <stuartdouglas> they are the main things that are stopping the CDI tck from passing[02:43:50] <dmlloyd> hard to do EJB stuff without the EJB dudes[02:44:11] <stuartdouglas> yea, their timezone is not the best from my point of view[02:45:40] *** clebert has quit IRC[02:53:03] *** frainone_dinner is now known as frainone[03:00:40] *** mbg has joined #jboss-as7[03:01:40] *** mbg has quit IRC[03:03:37] *** pferraro has quit IRC[03:05:07] *** pferraro has joined #jboss-as7[03:05:07] *** ChanServ sets mode: +v pferraro[03:08:46] *** dmison has joined #jboss-as7[03:09:21] *** JimMa has quit IRC[03:11:06] *** pferraro has quit IRC[03:13:12] *** rawbdor has quit IRC[03:17:03] *** pferraro has joined #jboss-as7[03:17:04] *** ChanServ sets mode: +v pferraro[03:33:27] *** jwulf has quit IRC[03:53:29] *** bbrowning is now known as bbrowning_away[03:59:44] *** sgilda has quit IRC[03:59:51] *** frainone has quit IRC[04:00:45] *** stliu has joined #jboss-as7[04:00:45] *** ChanServ sets mode: +v stliu[04:11:38] <dmlloyd> stuartdouglas: are you ready to merge?[04:12:12] <stuartdouglas> I have stuff in my master that is ready to merge, but not the driver manager stuff, because I don't have commit rights to the spec repo[04:12:28] *** lgao has joined #jboss-as7[04:15:15] <stuartdouglas> dmlloyd: I was thinking I might have a look at doing AS7-388[04:15:16] <jbossbot> jira [AS7-388] Detect, filter, and act upon system APIs found in deployments [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/AS7-388[04:15:53] <stuartdouglas> should this be something that is configurable via standalone/domain.xml, or just defined by a file packaged up in a jar?[04:16:27] <stuartdouglas> I would think just packaged up in a jar, cause it will probably be a fairly big list[04:16:33] <dmlloyd> I'd say that we should have a default set of filters and they can be overridden on a per-deployment basis[04:16:40] <dmlloyd> but not via standalone/domain.xml[04:16:50] <dmlloyd> unless people really start bitching :)[04:17:25] <stuartdouglas> well in that case I will start hacking on it[04:17:40] *** lazarotti has quit IRC[04:17:44] <stuartdouglas> I updated jboss-metadata in my master, and now the richfaces example nearly deploys[04:17:51] <stuartdouglas> except that it needs TimerService[04:18:02] <dmlloyd> just in terms of boot time though it should be an external text or properties file which is read on init instead of being baked into the class[04:18:41] <stuartdouglas> external as in zipped up in the jar?[04:18:54] <stuartdouglas> or external as in outside the jar althogether?[04:19:27] <dmlloyd> inside the JAR as a resource[04:19:38] <dmlloyd> especially if the list is long[04:21:30] *** JimMa has joined #jboss-as7[04:21:35] <dmlloyd> okay we officially need timers then, even if they're not strictly WP[04:21:39] <dmlloyd> by themselves[04:21:51] <stuartdouglas> we also need them to pass the CDI TCK[04:21:59] <dmlloyd> yeah, that's why :)[04:22:10] <dmlloyd> does no good that they're excluded from the EJB TCK if they're in the CDI TCK[04:22:26] <Nihility> the funny thing is[04:22:32] *** dmlloyd sets mode: -o dmlloyd[04:22:34] <Nihility> we probably have to disable them[04:22:39] <Nihility> to be strict compliant[04:22:50] <Nihility> but we cant pass the cdi tck[04:22:55] <Nihility> without them[04:23:01] <stuartdouglas> we could challenge the CDI TCK[04:23:03] <Nihility> so i guess we try including them[04:23:17] <dmlloyd> well, further talk about it should be confined to RH internal IRC[04:23:33] <dmlloyd> suffice it to say that it's on the map for CR1...[04:23:42] <dmlloyd> so we need some solution[04:23:47] <stuartdouglas> CDI TCK is open source anyway :-)[04:23:53] <dmlloyd> that's helpful[04:24:09] <dmlloyd> is there a separate CDI TCK for web profile?[04:24:21] <Nihility> no its all silly the way it works[04:24:23] <stuartdouglas> don't think so[04:24:30] <Nihility> you have to run it separately[04:24:36] <Nihility> because they never had time to integrate it[04:25:22] <Nihility> how much of the ejb tck is still failing[04:25:29] *** bgeorges has quit IRC[04:25:52] <Nihility> lets talk about that in #ejb3[04:25:55] <dmlloyd> a secret, non-public amount[04:25:57] <dmlloyd> :)[04:26:21] <Nihility> stuartdouglas: can you login to rh irc and join #ejb3[04:26:37] <stuartdouglas> sure, one sec[04:27:03] *** stliu has quit IRC[04:28:16] *** JimMa has quit IRC[04:29:17] <baileyje> Any ideas why it is taking 15-25 seconds to start a jvm with the ARQ2 managed container tests?[04:31:31] <stuartdouglas> hmm, I can't seem to resolve the IRC servers[04:32:45] <baileyje> hmmm.. Must be running low on memory[04:41:41] <baileyje> dmlloyd: https://github.com/baileyje/jboss-as/commit/7b16a4f995ffe9bf561f2098de1d811a581d1db3[04:41:42] <jbossbot> git [jboss-as] 7b16a4f.. John E. Bailey [AS-771] - Add additional operations to support updating logging configuration[04:41:46] <baileyje> That is updated..[04:42:07] <baileyje> Finally figured out how to get past all my build issues.[04:42:20] <baileyje> Just had to free up a full 2GB for the build to run[04:42:48] <dmlloyd> cool, testing now[04:49:01] <Nihility> hahaah[04:56:05] *** pmuir has quit IRC[05:09:55] <stuartdouglas> dmlloyd: With this filtering thing should it be part of ee or server?[05:10:03] <dmlloyd> server[05:10:48] <stuartdouglas> thats what I started doing but I just thought I should check[05:16:40] *** asaldhan has left #jboss-as7[05:29:04] *** Nihility has quit IRC[05:33:10] *** liweinan has joined #jboss-as7[05:48:06] *** miclorb has quit IRC[05:56:21] *** bstansberry has quit IRC[05:59:40] *** bobmcw_ has joined #jboss-as7[05:59:59] *** bobmcw_ has quit IRC[06:00:19] *** bobmcw_ has joined #jboss-as7[06:01:55] *** bobmcw has quit IRC[06:02:13] *** jc3` has joined #jboss-as7[06:03:18] *** pferraro has quit IRC[06:06:06] *** jc3 has quit IRC[06:08:33] *** kcbabo has quit IRC[06:18:48] *** magesh has joined #jboss-as7[06:19:14] *** jwulf has joined #jboss-as7[06:21:05] *** ThePing has joined #jboss-as7[06:21:05] *** ThePing has left #jboss-as7[06:25:52] *** liweinan has quit IRC[06:26:26] *** liweinan has joined #jboss-as7[06:33:16] <stuartdouglas> dmlloyd: Still awake?[06:34:17] *** pgier has quit IRC[06:34:23] <dmlloyd> yeah what's up[06:34:44] <stuartdouglas> I have that filtering thing up and running: https://github.com/stuartwdouglas/jboss-as/commit/a81d66a06c5741ffd883c4e594e97a5dbbabd5b8[06:34:45] <jbossbot> git [jboss-as] a81d66a.. Stuart Douglas AS7-388 Add mechanism to filter packages and replace them with module dependencies[06:34:46] <jbossbot> jira [AS7-388] Detect, filter, and act upon system APIs found in deployments [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/AS7-388[06:35:06] <stuartdouglas> it just works from a properties file that is packageToFilter=module1,module2[06:35:24] <stuartdouglas> and then they can add a manifest entry to disable it for certain packages[06:35:36] <stuartdouglas> hmm, just realised I forgot to log a message[06:37:57] *** liweinan has quit IRC[06:42:04] *** liweinan has joined #jboss-as7[06:43:38] *** liweinan has quit IRC[06:44:13] <stuartdouglas> I just added logging[06:45:13] <stuartdouglas> do you think that this is sufficient from a filtering point of view, or do we need to support more advanced scenarios? (such as filter javasisst but not javassist.proxy) ?[06:45:24] *** stliu has joined #jboss-as7[06:45:24] *** ChanServ sets mode: +v stliu[06:46:22] *** JimMa has joined #jboss-as7[06:50:59] <dmlloyd> hmm[06:51:06] <dmlloyd> I think the filters should be an exact match[06:51:12] <dmlloyd> else we might run into trouble in javax. land[06:51:19] <dmlloyd> i.e. not a prefix match[06:51:19] *** magesh1 has joined #jboss-as7[06:51:36] *** magesh has quit IRC[06:51:47] <stuartdouglas> that is going to make the file huge, e.g. for stuff like hibernate that has heaps of packages[06:51:54] <dmlloyd> yeah that's ok[06:52:26] <stuartdouglas> also the packages might be different between versions,[06:52:26] <dmlloyd> you can intern those strings to shrink the map[06:52:52] <stuartdouglas> I will probably also need to split them into paths[06:53:05] <dmlloyd> what you could do is have a list of modules instead[06:53:11] <stuartdouglas> so if there is no org.hibernate it does not look though looking for other hibernate sub packages[06:53:16] <dmlloyd> then on boot it could query the module paths[06:53:23] <dmlloyd> of course that'd force loading a lot of modules :)[06:53:28] <stuartdouglas> can I do that without reflection hacks?[06:53:37] <dmlloyd> or better yet, we could generate it at build time[06:53:52] <dmlloyd> then we could just provide a list of maven artifacts or something[06:54:24] <dmlloyd> the filtering should be O(1) which you can do with exact paths but not with prefix matching[06:54:31] <stuartdouglas> will that cause problems if the user bundles a version that has different packages to what our artifacts have?[06:54:37] <dmlloyd> iow for each directory, look at the map once[06:54:42] <dmlloyd> yeah maybe[06:55:57] <dmlloyd> with prefix searching you have to check every path against the whole list[06:56:02] <dmlloyd> which kinda suck[06:56:02] <dmlloyd> s[06:57:25] <stuartdouglas> I could get around that by turning the prefix match into a list of packages before I add the jboss modules filer[06:57:34] <stuartdouglas> s/filer/filter[06:58:00] <dmlloyd> you still have to compare every deployment path against every prefix though[06:59:16] <stuartdouglas> hmm, I just realised that this is running to early[06:59:28] <stuartdouglas> to late I mean[06:59:46] <stuartdouglas> as we probably want to exclude filtered classes from annotation scanning[06:59:57] <dmlloyd> you could possibly blacklist whole JARs instead[07:00:07] <dmlloyd> i.e. if it looks like a hibernate jar nuke it[07:00:10] <stuartdouglas> I thought about that[07:00:23] <stuartdouglas> but some things provide 'uber jars' with all the deps[07:00:33] <dmlloyd> that's true[07:00:36] <dmlloyd> shade etc[07:00:38] <stuartdouglas> and it would be neat if we could just filter out the cruft[07:01:04] <dmlloyd> this would be a good task for a trie[07:01:21] <stuartdouglas> trie?[07:01:22] <dmlloyd> you could run each unique deployment path against the trie for O(1) prefix check[07:01:44] <dmlloyd> yeah a prefix tree, sort of a state machine which matches prefix strings[07:02:03] <dmlloyd> you could even compile it down to a tree of switch statements in bytecode :)[07:02:23] <dmlloyd> i.e. if the package name starts with "q" you know you don't have to check any further[07:02:37] <dmlloyd> if it's "j" you start down one path, "o" another[07:02:38] <dmlloyd> etc.[07:02:46] <stuartdouglas> sure[07:03:00] <dmlloyd> the problem is, say you use hibernate[07:03:10] <stuartdouglas> maybe it could be integrated with the annotation scanning process[07:03:12] <dmlloyd> say rather you blacklist org.hibernate[07:03:23] <dmlloyd> and then epbernard releases hibernate ninja[07:03:27] <dmlloyd> package org.hibernate.ninja[07:03:34] <dmlloyd> somoene wants to bundle it[07:03:37] <dmlloyd> *fail*[07:03:37] <stuartdouglas> yea, that will be a problem[07:04:14] <stuartdouglas> maybe we should not filter, but enable child-last behaviour for these packages instead[07:04:15] <dmlloyd> if we maintain a list or even if we use the package list from our shipped JAR it's probably good enough[07:04:46] <dmlloyd> sure, it amounts to the same thing, sort of, except that classes in the deployment JAR that aren't in the module will "leak through"[07:04:57] <stuartdouglas> yea, like hibernate ninja[07:05:14] <dmlloyd> no I mean classes in the same package[07:05:27] <dmlloyd> so org.hibernate.Foo gets deleted[07:05:33] <dmlloyd> the deployment JAR contains it, ours doesn't[07:05:49] <dmlloyd> even though our org/hibernate takes precedence, it'd still check the deployment's when Foo isn't found[07:06:00] <dmlloyd> whereas if we filter the package from the deployment that would not happen[07:06:04] <stuartdouglas> although in theory none of our new hibernate classes will reference Foo, so it does not matter[07:06:10] <dmlloyd> right exactly[07:06:21] <dmlloyd> same for deleted subpackages, which would leak through in either case[07:06:30] <dmlloyd> whether we filter the package or simply override it[07:06:39] <dmlloyd> but I think filtering it is somewhat cleaner[07:07:04] <stuartdouglas> yea, after thinking about it a bit I think the build time idea is probably the best[07:07:51] <stuartdouglas> so we will have a source file that lists the modules, and then process that at build time into a list of packages[07:08:15] <dmlloyd> yeah that sounds good[07:08:47] <stuartdouglas> the list of packages is probably going to need to go into it's own module[07:09:04] <stuartdouglas> so I don't have to open up the server jar and insert it[07:09:26] <dmlloyd> if you do it during the right phase then maven will insert it itself[07:09:31] <dmlloyd> there are generated resource dirs and stuff like that[07:09:55] <dmlloyd> if you were gonna use antrun or something like that I mean[07:10:10] <stuartdouglas> in that case I would need to list maven artifacts rather than module identifiers[07:10:27] <stuartdouglas> cause we can't really use module identifiers till the build project is running[07:10:42] <stuartdouglas> by which time server is already built[07:10:53] <dmlloyd> well you can do it another way[07:11:00] <dmlloyd> add a resource directory to the server module[07:11:08] <dmlloyd> populate it from the build phase[07:11:18] <dmlloyd> add it as a resource root[07:11:29] <dmlloyd> then it's not in any JAR[07:11:35] <dmlloyd> plus it's hackable then :)[07:11:42] <dmlloyd> for better or worse![07:11:52] <stuartdouglas> that sounds good[07:11:53] <dmlloyd> or you could build it into another JAR if you wanted[07:11:57] <dmlloyd> either way[07:12:41] <nickarls> stuartdouglas: much delayed pong. the verifyerror?[07:12:53] <stuartdouglas> nickarls: fixed, but not merged yet[07:13:32] <nickarls> stu: cool, thanks[07:13:57] <stuartdouglas> it's in my master, if you want it[07:14:15] <nickarls> stu: btw, is the issue with e.g. seam 3 i18n module and optional joda-time dep still open?[07:14:55] <nickarls> stu: no hurry on that one. I just drop the current app I'm working on in an AS7 once in a while and see what breaks ;-)[07:15:16] <stuartdouglas> the joda-time one should be fixed afaik[07:15:35] <nickarls> I still saw it yesterday[07:15:49] <nickarls> well, it's easy to get around anyways[07:16:28] *** jhalliday has joined #jboss-as7[07:17:05] <stuartdouglas> then it is not fixed :-([07:17:28] <nickarls> I didn't find the JIRA, was it in modules or as?[07:17:47] <stuartdouglas> I know there was one in weld[07:18:46] <stuartdouglas> nickarls: Are you sure it did not work or was there just big stacktraces in the log[07:18:48] <stuartdouglas> ?[07:19:05] <nickarls> stacktrace with a mention of a CNFE[07:19:18] <stuartdouglas> but did the stacktrace stop the deplyment?[07:19:46] <stuartdouglas> cause jboss modules logs and rethrows them at the moment[07:19:56] <stuartdouglas> and then I catch and ignore[07:20:08] <stuartdouglas> (at least, thats the way it is supposed to work)[07:20:56] <nickarls> hmm, good question, didn't check. But I would have to guess stopped since I only saw the verifyerror after I included joda-time[07:20:57] *** pferraro has joined #jboss-as7[07:20:57] *** ChanServ sets mode: +v pferraro[07:30:06] *** pferraro has quit IRC[07:32:16] *** pferraro has joined #jboss-as7[07:32:26] *** ChanServ sets mode: +v pferraro[07:42:34] *** lazarotti has joined #jboss-as7[07:44:22] *** pferraro has quit IRC[07:59:29] *** jfclere has joined #jboss-as7[07:59:29] *** ChanServ sets mode: +v jfclere[08:04:18] *** miclorb has joined #jboss-as7[08:06:04] *** misty has quit IRC[08:09:18] *** alesj has joined #jboss-as7[08:13:09] *** hbraun has joined #jboss-as7[08:14:35] <hbraun> good morning[08:14:54] <dmlloyd> guten morgen[08:15:03] <hbraun> oh, you are still awake?[08:15:08] <dmlloyd> not for long :)[08:15:16] <hbraun> what time is it over ther?[08:15:24] <dmlloyd> 1:17[08:15:29] <hbraun> 8:00 AM[08:15:46] <hbraun> still working?[08:15:56] <dmlloyd> if you could call it that[08:15:59] <hbraun> or playing angry birds with jason?[08:16:04] <dmlloyd> can't seem to get the brain cells to talk to each other[08:16:16] <hbraun> yeah, better get some sleep[08:16:30] <dmlloyd> trying to fix an AS problem by fixing an MSC problem by fixing *another* MSC problem[08:16:34] <dmlloyd> StackOverflowError[08:16:38] <hbraun> oh shit[08:16:54] <hbraun> but I belive you'll find the solution once you get a good night sleep[08:17:02] <dmlloyd> the StackOverflowError being in the brain, not in the code :)[08:17:10] <hbraun> hehe[08:17:15] <hbraun> that's better then[08:17:18] <dmlloyd> righto then[08:17:20] <dmlloyd> good night![08:17:23] <hbraun> good night[08:21:33] *** lazarotti has quit IRC[08:25:05] *** galderz has joined #jboss-as7[08:25:05] *** ChanServ sets mode: +v galderz[08:27:21] *** irooskov has joined #jboss-as7[08:27:28] *** ChanServ sets mode: +v irooskov[08:27:51] *** opalka has joined #jboss-as7[08:27:51] *** ChanServ sets mode: +v opalka[08:28:07] <opalka> morning[08:28:42] <hbraun> opalka: curently looking at your DMR changes[08:29:06] <opalka> hbraun, Hi heiko[08:29:13] <opalka> hbraun, those are available in standalone only[08:29:17] <opalka> hbraun, domain isn't fixed yet[08:29:22] <hbraun> ah, ok[08:29:30] <hbraun> then i don't need to look[08:29:32] <hbraun> ;)[08:29:41] <opalka> hbraun, :)[08:29:51] <opalka> hbraun, I'm not sure yet how to do it for domain[08:29:59] <opalka> hbraun, those are all runtime model data[08:30:15] <opalka> hbraun, no persistence and AFAIK for domain to work properly all needs to be persisted[08:30:18] <hbraun> what's the problem with the domain case?[08:30:30] <opalka> hbraun, I was playing with it on yesterday[08:30:43] <opalka> hbraun, when I'm running in domain mode[08:31:08] <hbraun> you are talking about the metrics, right?[08:31:09] <opalka> hbraun, in default domain in webservices subsytem[08:31:18] <opalka> hbraun, both metrics & endpoints[08:31:23] <hbraun> or the endpoint list as well?[08:31:25] <hbraun> ah ok[08:31:26] <hbraun> go on[08:31:43] <opalka> hbraun, I don't know how to do it for domain (yet)[08:31:59] <opalka> hbraun, I first focused to make it work in standalone (in expected way)[08:32:12] <hbraun> is it because the endpoint registry is a per server thing?[08:32:29] *** mgoldmann has joined #jboss-as7[08:32:29] *** ChanServ sets mode: +v mgoldmann[08:32:35] <opalka> hbraun, currently there's ugly hack to AS7 runtime[08:32:46] <hbraun> what hack?[08:32:49] <opalka> hbraun, that modified AS7 DMR model in un/deployment phase[08:32:50] <hbraun> in the Ws subsystem?[08:32:56] <opalka> hbraun, yes, in ws subsytem[08:33:06] <opalka> hbraun, we use endpoint registry only for metrics ATM[08:33:24] <opalka> hbraun, what's not decided yet is[08:33:38] <opalka> hbraun, whether WS endpoint DMR data should be all runtime or should be persisted[08:33:50] <hbraun> did you speak to brian about this?[08:34:01] <opalka> hbraun, not yet[08:34:15] <opalka> hbraun, I have reference to one discussion between Brian & JimMa[08:34:24] <hbraun> I would suggest you do that first, he might be able to help[08:34:39] <opalka> hbraun, I'm going to (hopefully tonight)[08:34:44] <hbraun> +1[08:35:14] <hbraun> the whole relation between runtime data in the subsystem and it's representation in the detyped model is queit unclear to me[08:35:25] <hbraun> but knows more about that[08:35:28] <hbraun> he[08:36:01] <hbraun> then you still have the issue of aggragated views on the domain level[08:36:27] *** Jaikiran has joined #jboss-as7[08:36:27] *** ChanServ sets mode: +v Jaikiran[08:36:31] <hbraun> ideally you can pull the metrics from the domain, opposed to each server individually[08:36:43] <hbraun> but that's a general design issue[08:36:52] <hbraun> not sure if that did make any progress[08:37:00] <hbraun> might be 7.1[08:37:30] <hbraun> we just need to figure out if it's possible atm[08:37:49] <hbraun> if not we might postpone the whole thing for the domain until we have a proper solution[08:38:32] <opalka> hbraun, the domain behavior is unclear to me too, but it's because of luck of any experience with it. I need to play with it little bit.[08:38:57] <opalka> hbraun, From my understanding this is the problem for all subsystems ATM[08:39:16] <hbraun> it's better to talk to brian and david. most of the time there is either:[08:39:26] <hbraun> a) a preferred way[08:39:32] <hbraun> b) a hidden solution[08:39:44] <hbraun> or a combination of both[08:40:06] <hbraun> yes, I believe it's a general requirement[08:40:21] <hbraun> we haad some discussions about this in the beginning[08:40:29] <hbraun> but AFAIK it didn't make any progress[08:40:37] <opalka> hbraun, will discuss it tonight (hopefully my baby boys will be sleeping) ;)[08:40:44] <hbraun> ;)[08:40:46] <hbraun> fine[08:41:05] <hbraun> i'll make sure the WS stuff will be available for standalone at least[08:41:17] <opalka> hbraun, that would be great[08:41:30] <hbraun> and wait for your feedback when you talked to brian[08:41:32] <opalka> hbraun, I did my best to make it behave in standard/expected way[08:41:38] <hbraun> just figure out if it's possible at all[08:41:39] <opalka> hbraun, k[08:41:56] <hbraun> great thanks[08:42:23] <opalka> hbraun, UR welcome Heiko :)[08:43:13] *** adietisheim has joined #jboss-as7[08:43:13] *** ChanServ sets mode: +v adietisheim[08:43:58] *** miclorb has quit IRC[08:43:59] *** irooskov has quit IRC[08:44:20] *** irooskov has joined #jboss-as7[08:44:20] *** ChanServ sets mode: +v irooskov[08:44:24] *** miclorb has joined #jboss-as7[08:48:05] *** davidbos has joined #jboss-as7[08:50:57] *** jwulf has quit IRC[08:51:53] *** Binbin_ is now known as Binbin[08:52:16] *** magesh has joined #jboss-as7[08:53:46] *** magesh1 has quit IRC[08:58:13] *** epbernard has joined #jboss-as7[08:58:13] *** epbernard is now known as emmanuel[08:58:13] *** ChanServ sets mode: +v emmanuel[08:59:38] *** jcosta has joined #jboss-as7[08:59:38] *** ChanServ sets mode: +v jcosta[09:05:00] *** miclorb has quit IRC[09:05:38] <hbraun> opalka: can we resolve https://issues.jboss.org/browse/AS7-698 when we have answer to the domain problem?[09:05:40] <jbossbot> jira [AS7-698] Add operation to query ws endpoints metrics [Resolved (Done) Task, Major, Richard Opalka] https://issues.jboss.org/browse/AS7-698[09:06:32] <opalka> hbraun, this is related to standalone only[09:07:05] <opalka> hbraun, there's https://issues.jboss.org/browse/AS7-740[09:07:06] <jbossbot> jira [AS7-740] WS Endpoint doesn't appear in domain mode [Open (Unresolved) Bug, Major, Richard Opalka] https://issues.jboss.org/browse/AS7-740[09:07:10] <hbraun> ok[09:07:25] <hbraun> sorry I did forget about that[09:07:27] <hbraun> ;9[09:08:01] *** pilhuhn has joined #jboss-as7[09:08:01] *** ChanServ sets mode: +v pilhuhn[09:08:40] <opalka> hbraun, NP :)[09:14:19] *** lgao has quit IRC[09:20:57] *** mbg has joined #jboss-as7[09:26:53] *** jhalliday has quit IRC[09:29:38] *** bgeorges has joined #jboss-as7[09:31:22] *** wolfc has joined #jboss-as7[09:31:22] *** ChanServ sets mode: +v wolfc[09:35:48] *** ALR has quit IRC[09:44:26] *** aslak has joined #jboss-as7[09:44:26] *** aslak has quit IRC[09:44:26] *** aslak has joined #jboss-as7[09:44:26] *** ChanServ sets mode: +v aslak[09:47:29] *** mlinhard has joined #jboss-as7[09:47:29] *** ChanServ sets mode: +v mlinhard[09:48:30] *** aslak has quit IRC[09:48:39] *** kkhan has joined #jboss-as7[09:48:39] *** ChanServ sets mode: +v kkhan[09:49:27] *** aslak has joined #jboss-as7[09:49:27] *** ChanServ sets mode: +v aslak[09:52:39] *** pmuir has joined #jboss-as7[09:52:39] *** pmuir has quit IRC[09:52:39] *** pmuir has joined #jboss-as7[09:52:39] *** ChanServ sets mode: +v pmuir[09:53:34] *** dmison has quit IRC[09:53:49] *** asoldano has joined #jboss-as7[09:53:49] *** ChanServ sets mode: +v asoldano[09:53:49] *** aslak has quit IRC[09:54:28] *** aslak has joined #jboss-as7[09:54:28] *** ChanServ sets mode: +v aslak[09:56:00] <opalka> Jaikiran, wolfc ping[09:56:08] <wolfc> opalka: pong[09:56:16] <opalka> wolfc, just curious ;)[09:56:24] <opalka> wolfc, I see in SLSB component the following code[09:56:36] <opalka> // FIXME:[09:56:36] <opalka> //return getComponentInterceptor().processInvocation(context);[09:56:36] <opalka> throw new RuntimeException("NYI");[09:56:44] <opalka> wolfc, any time estimation when we can expect it to be fixed ?[09:56:51] <wolfc> that breaks WS?[09:56:59] <opalka> wolfc, yes, some tests[09:57:25] <opalka> wolfc, I'm also not sure if we're using EJB components properly after recent changes in AS7 ?[09:57:27] <wolfc> Jaikiran, stuartdouglas: ^[09:57:45] * stuartdouglas looks[09:57:56] *** adietisheim has quit IRC[09:57:59] <wolfc> opalka: do you have a smoke or integration test in AS 7?[09:58:12] <opalka> wolfc, not yet, I can provide one ;)[09:58:23] <opalka> wolfc, providing ...[09:58:25] <wolfc> opalka: please do so, then we shouldn't see it regress again[09:58:36] *** adietisheim has joined #jboss-as7[09:58:37] *** ChanServ sets mode: +v adietisheim[09:58:41] <opalka> wolfc, agreed, this is our fault with small coverage[09:58:58] <stuartdouglas> where is that bit of code?[10:00:02] <wolfc> StatelessSessionComponent[10:02:02] <wolfc> Note that InvocationHandlerEJB3 is broken in itself as well[10:03:10] <stuartdouglas> So it the point of that method it invoke on the bean while by-passing view interceptors?[10:03:22] <wolfc> WS should really setup a view (of type MethodIntf.SERVICE_ENDPOINT) and invoke through that.[10:03:42] <opalka> wolfc, stuartdouglas listening ...[10:03:52] *** torben has joined #jboss-as7[10:03:52] *** ChanServ sets mode: +v torben[10:04:18] <wolfc> opalka, I'm mostly hoping to make sense to stuartdouglas :-)[10:05:55] <wolfc> opalka, you need to make sure that we can transport that view reference from the deployers to InvocationHandlerEJB3. Probably through the same mechanism as the SessionBeanComponent is done right now.[10:07:15] <opalka> wolfc, listening ...[10:08:13] *** jcosta has quit IRC[10:08:35] *** jcosta has joined #jboss-as7[10:08:35] *** ChanServ sets mode: +v jcosta[10:09:05] <Jaikiran> stuartdouglas: it should really bypass the interceptors[10:09:10] <wolfc> No[10:09:17] <Jaikiran> *shouldn't[10:09:20] <Jaikiran> :)[10:09:32] <Jaikiran> it should pick up an "entry point" and trigger the invocation on that[10:09:48] <wolfc> It should work a bit similar to BusinessViewAnnotationProcessor[10:10:02] <wolfc> Adding the SERVICE_ENDPOINT view[10:10:12] <wolfc> Which the InvocationHandlerEJB3 then looks up and invokes upon[10:10:16] <Jaikiran> ComponentViewInstance#getEntryPoint for example[10:10:29] <wolfc> You need the view itself first :-)[10:12:21] <Jaikiran> yep :)[10:12:35] <Jaikiran> but i am not sure what methods should be exposed by that view[10:14:26] * stuartdouglas afk dinner[10:16:51] *** lgao has joined #jboss-as7[10:17:18] *** mbg has quit IRC[10:18:17] *** kkhan has quit IRC[10:20:18] *** asoldano is now known as asoldano_afk[10:20:30] *** tdiesler has joined #jboss-as7[10:20:30] *** ChanServ sets mode: +v tdiesler[10:23:40] <wolfc> Jaikiran, that would be up to WS (opalka) defining the ViewDescription. I think I'm missing bits there for allowed methods.[10:24:09] <opalka> wolfc, Jaikiran I'll have a look[10:24:28] <opalka> wolfc, Jaikiran adding some tests & demos first ...[10:30:27] *** galderz has quit IRC[10:30:48] *** galderz has joined #jboss-as7[10:30:48] *** ChanServ sets mode: +v galderz[10:31:08] *** davidbos has quit IRC[10:31:11] *** davidbos1 has joined #jboss-as7[10:32:19] *** rawbdor has joined #jboss-as7[10:32:26] *** ChanServ sets mode: +v rawbdor[10:33:11] <alesj> stuartdouglas: ping?[10:33:58] *** asoldano_afk is now known as asoldano[10:37:02] *** tdiesler has quit IRC[10:39:00] *** tdiesler has joined #jboss-as7[10:39:00] *** ChanServ sets mode: +v tdiesler[10:40:10] *** tdiesler has quit IRC[10:43:43] <pilhuhn> Json to send: {"address":[{"deployment":"test.war"}],"operation":"add","runtime-name":"test.war","hash":{"BYTES_VALUE":"7jgpMVmynfxpqp8UDleKLmtgbrA="},"name":"test.war"}[10:43:44] <pilhuhn> ==> {"outcome" : "failed", "failure-description" : {"domain-failure-description" : "Parameter content may not be null "}}[10:44:02] <pilhuhn> Where can I learn about this change in http deployment ?[10:46:10] <wolfc> pilhuhn: bstansberry changed the descriptions, doesn't that suffice?[10:46:34] <wolfc> I don't know where and how we doc the admin operations atm[10:46:45] <wolfc> but I can tell you the differences[10:47:07] <pilhuhn> wolfc if it is a simple rename it will help :) Yes please[10:48:44] *** torben has quit IRC[10:49:09] <pilhuhn> wolfc ok, I see it in the recursive description of / - it is annoying when working code all of a sudden fails[10:50:06] <wolfc> I did tell you that the console would stop working with the AS7-434 changes ;-)[10:50:07] <jbossbot> jira [AS7-434] Implement EJB 3.1 FR 22 Embeddable Usage [Open (Unresolved) Task, Critical, Carlo de Wolf] https://issues.jboss.org/browse/AS7-434[10:50:12] <wolfc> AS7-431[10:50:13] <jbossbot> jira [AS7-431] Deployment content management enhancement [Open (Unresolved) Task, Major, Carlo de Wolf] https://issues.jboss.org/browse/AS7-431[10:50:25] <wolfc> https://github.com/jbossas/jboss-as/blame/master/testsuite/smoke/src/test/java/org/jboss/as/test/surefire/servermodule/HttpDeploymentUploadUnitTestCase.java[10:50:28] <wolfc> L132[10:50:48] <wolfc> pilhuhn: ^[10:50:50] * pilhuhn is the RHQ heiko , not the console one :-)[10:50:52] <pilhuhn> wolfc thanks[10:51:05] *** hardy_ has joined #jboss-as7[10:51:10] <wolfc> ah :-) I keep getting you guys confused, sorry.[10:51:31] <pilhuhn> np[10:52:51] *** bgeorges has quit IRC[10:55:25] <opalka> wolfc, Jaikiran I provided some tests to demos2 suite, how can I run demos2 suite against AS7 ? Is there doc ?[10:56:14] <opalka> pilhuhn, there are the changes U suggested for webservice endpoint management available on trunk[10:56:45] * wolfc is still fiddling to get testsuite2 going[10:56:53] <pilhuhn> opalka I've seen it already - I will update as and look at it as soon as I have deployment working again.[10:57:05] <pilhuhn> opalka Do you have a sample app for me that exposes webservcies?[10:57:16] <opalka> pilhuhn, sure, let me know your e-mail address[10:57:31] <pilhuhn> hrupp at redhat dot com[10:57:41] <opalka> pilhuhn, aha, U're the heiko ;)[10:57:43] <opalka> pilhuhn, sending ...[10:57:59] <pilhuhn> great , thx[10:59:17] <opalka> pilhuhn, sent[10:59:34] <opalka> wolfc, does it mean U don't know how to make it run too ?[11:00:01] <wolfc> yup, I'm just as ignorant[11:01:16] <Jaikiran> what's demos2?[11:01:21] <Jaikiran> i thought it's just testsuite2[11:01:48] *** maeste has joined #jboss-as7[11:01:48] *** ChanServ sets mode: +v maeste[11:04:13] *** opalka has quit IRC[11:05:55] *** alesj has quit IRC[11:10:06] *** pmuir has quit IRC[11:11:36] *** torben has joined #jboss-as7[11:11:36] *** torben has quit IRC[11:11:36] *** torben has joined #jboss-as7[11:11:36] *** ChanServ sets mode: +v torben[11:17:14] *** jwulf has joined #jboss-as7[11:25:26] *** AndyTaylor has joined #jboss-as7[11:25:26] *** ChanServ sets mode: +v AndyTaylor[11:30:07] *** torben has quit IRC[11:35:22] *** pmuir has joined #jboss-as7[11:35:23] *** pmuir has quit IRC[11:35:23] *** pmuir has joined #jboss-as7[11:35:23] *** ChanServ sets mode: +v pmuir[11:36:44] *** kkhan has joined #jboss-as7[11:36:44] *** ChanServ sets mode: +v kkhan[11:37:59] *** pmuir has quit IRC[11:38:08] *** kkhan has quit IRC[11:38:52] *** kkhan has joined #jboss-as7[11:38:53] *** ChanServ sets mode: +v kkhan[11:39:12] *** pmuir has joined #jboss-as7[11:39:13] *** pmuir has joined #jboss-as7[11:39:13] *** ChanServ sets mode: +v pmuir[11:39:29] <pilhuhn> wolfc another question. In the past I had {"address":[{"server-group":"main-server-group"},{"deployment":"test.war"}],"operation":"add","enabled":"true"}[11:40:03] <pilhuhn> this is now failing with a duplicate entry "test.war" exception -- even if it is not a dupe, but just added to /deployments in the op before[11:40:50] <wolfc> pilhuhn: I fear we have a mismatch there in operations[11:41:12] <pilhuhn> THis is all code that used to work *sigh*[11:42:22] <pilhuhn> but I see that this content=> mumbo jumbo has been added to :add here too - I will change my code and see what happens[11:43:28] *** kkhan has quit IRC[11:43:53] <pilhuhn> ah I guess that :add on server-group level is now the same as on /deployment level so I can use that synonymous. And then really deploy via :deploy ? Trying ...[11:44:04] *** kkhan has joined #jboss-as7[11:44:04] *** ChanServ sets mode: +v kkhan[11:51:20] *** kkhan has quit IRC[11:51:22] *** torben has joined #jboss-as7[11:51:23] *** torben has quit IRC[11:51:23] *** torben has joined #jboss-as7[11:51:23] *** ChanServ sets mode: +v torben[11:51:28] *** kkhan has joined #jboss-as7[11:51:28] *** ChanServ sets mode: +v kkhan[11:59:15] *** emmanuel has quit IRC[12:07:55] *** alesj has joined #jboss-as7[12:10:22] *** epbernard has joined #jboss-as7[12:10:22] *** epbernard is now known as emmanuel[12:10:22] *** ChanServ sets mode: +v emmanuel[12:14:34] *** JimMa has quit IRC[12:15:23] *** sannegrinovero has joined #jboss-as7[12:15:23] *** sannegrinovero has quit IRC[12:15:23] *** sannegrinovero has joined #jboss-as7[12:15:23] *** ChanServ sets mode: +v sannegrinovero[12:16:21] *** stansilvert has quit IRC[12:23:58] *** kcbabo has joined #jboss-as7[12:23:58] *** ChanServ sets mode: +v kcbabo[12:34:18] *** magesh has quit IRC[12:41:04] *** stliu has quit IRC[12:51:49] *** magesh has joined #jboss-as7[13:09:22] *** sgilda has joined #jboss-as7[13:12:15] *** Jaikiran has quit IRC[13:22:14] *** bbrowning_away is now known as bbrowning[13:22:34] *** Jaikiran has joined #jboss-as7[13:22:34] *** ChanServ sets mode: +v Jaikiran[13:29:53] *** jwulf has quit IRC[13:33:42] *** adietisheim has quit IRC[13:35:38] *** bstansberry has joined #jboss-as7[13:35:38] *** ChanServ sets mode: +v bstansberry[13:40:09] *** jc3` is now known as jc3[13:40:28] *** Jaikiran has quit IRC[13:40:45] *** Jaikiran has joined #jboss-as7[13:40:45] *** ChanServ sets mode: +v Jaikiran[13:41:51] *** asoldano is now known as asoldano_lunch[13:41:52] <hbraun> maeste: ping[13:42:03] <hbraun> maeste: doi we get the release today?[13:42:26] <hbraun> bstansberry: ping[13:58:18] *** darranl has joined #jboss-as7[13:58:18] *** darranl has joined #jboss-as7[13:58:18] *** ChanServ sets mode: +v darranl[13:59:50] *** smarlow has joined #jboss-as7[13:59:51] *** ChanServ sets mode: +v smarlow[13:59:59] *** kkhan has quit IRC[14:04:33] <hbraun> darranl: ping[14:04:41] <darranl> hi hbraun[14:04:52] <pilhuhn> darranl hey[14:05:12] <hbraun> i cannot remember if authentication works in domain mode already. does it?[14:05:32] <pilhuhn> darranl the ops in the security-domain=* have no request- and return-properties ?[14:05:38] <darranl> hbraun, yes it does, currently defined in the host.xml[14:05:49] <darranl> pilhuhn, they need to be expanded[14:05:55] <hbraun> so, i need to add the pieces you send me to host.xml?[14:06:07] <darranl> hbraun, yes they can go in the host.xml[14:06:22] <hbraun> how does it secure the DC then?[14:06:46] <darranl> sorry can I catch up with you a little later, just meeting with Kabir at the moment to secure the Remotine side of the call[14:07:07] <hbraun> ok[14:07:11] <darranl> but for that question, the DC runs in a host controller[14:07:17] *** darranl has quit IRC[14:07:56] *** galderz has quit IRC[14:09:50] *** alesj has quit IRC[14:11:45] *** emmanuel has quit IRC[14:12:15] *** lgao has quit IRC[14:13:52] *** jpederse has joined #jboss-as7[14:13:52] *** ChanServ sets mode: +v jpederse[14:17:56] *** epbernard has joined #jboss-as7[14:17:56] *** epbernard is now known as emmanuel[14:17:56] *** ChanServ sets mode: +v emmanuel[14:24:18] *** liweinan has joined #jboss-as7[14:34:48] *** asoldano_lunch is now known as asoldano[14:35:22] *** galderz has joined #jboss-as7[14:35:22] *** ChanServ sets mode: +v galderz[14:38:20] <smarlow> Jaikiran, wolfc: with the recent EJB3 changes, I noticed that the JPA SFSBCreateInterceptorFactory doesn't get invoked anymore. Did we switch to use a system level lifecycle interceptor?[14:38:40] <wolfc> probably the thing is no longer enabled[14:43:27] *** magesh has left #jboss-as7[14:47:53] *** jcosta has quit IRC[14:56:31] *** mmoyses has joined #jboss-as7[14:56:31] *** ChanServ sets mode: +v mmoyses[15:00:12] *** darranl has joined #jboss-as7[15:00:12] *** darranl has joined #jboss-as7[15:00:12] *** ChanServ sets mode: +v darranl[15:02:52] *** bstansberry has quit IRC[15:03:00] *** smcgowan has joined #jboss-as7[15:03:00] *** ChanServ sets mode: +v smcgowan[15:03:49] *** jcosta has joined #jboss-as7[15:03:49] *** ChanServ sets mode: +v jcosta[15:05:22] *** pferraro has joined #jboss-as7[15:05:22] *** ChanServ sets mode: +v pferraro[15:07:08] *** bgeorges has joined #jboss-as7[15:07:44] <smarlow> Jaikiran: regarding your comment on AS7-836, are you in favor of fixing the jira or rejecting it? Currently, native Hibernate applications can add a module dependency on our org.hibernate module as a workaround.[15:07:45] <jbossbot> jira [AS7-836] non JPA (native Hibernate) app using hibernate doesn't cause org.hibernate classes to be loaded [Open (Unresolved) Bug, Major, Scott Marlow] https://issues.jboss.org/browse/AS7-836[15:08:37] * Jaikiran is looking[15:09:14] <smarlow> Jaikiran: stuartdouglas proposed that we notice native Hibernate deployments and automatically inject the org.hibernate dependency so they don't have to (unless they already have their own hibernate jars).[15:10:05] <Jaikiran> smarlow: from what i have seen with earlier AS versions, most of the times the user apps never use AS specific hibernate version[15:10:16] <Jaikiran> so i'm not too sure we should be automatically adding that dep[15:10:33] <Jaikiran> btw, how do we identify a native hibernate deployment?[15:10:50] <Jaikiran> @Entity?[15:10:58] <smarlow> Jaikiran: he talked about looking inside for Hibernate breadcrumbs :)[15:11:10] *** pferraro has left #jboss-as7[15:11:17] <Jaikiran> i don't think that's worth it, unless I'm missing something :)[15:11:29] <hbraun> darranl: does it support both basic and digest?[15:11:44] <hbraun> or does basic require a custom configuration[15:11:49] <smarlow> Jaikiran: I previously thought the same but am open if it makes sense.[15:12:06] <hbraun> darranl: it seems the config you send me prompts for digest auth[15:12:16] <darranl> hbraun, digest for the users defined in the domain model (also will be adding database and properties file), basic for the ldap config[15:12:24] <smarlow> Jaikiran: the reason is mostly, that these apps used to just work because Hibernate was on the AS classpath in earlier releases[15:12:54] <Jaikiran> smarlow: actually, i'm more interested in how we handle *any* library dependency that is in .war/WEB-INF/lib (for example)[15:13:13] <Jaikiran> i mean, the spec says that any jars in that folder is expected to be on CP of the application and should be usable[15:13:19] <Jaikiran> (including any hibernate jars)[15:13:35] <Jaikiran> I don't know how that works in a module environment[15:13:46] <Jaikiran> without adding the additional Dependencies in the MANIFEST.MF[15:14:02] <Jaikiran> so it probably is a more generic issue than just Hibernate[15:14:24] *** ccrouch has joined #jboss-as7[15:14:24] *** ChanServ sets mode: +v ccrouch[15:14:38] <smarlow> Jaikiran: I need to try that case again. I tried before and was stopped because of the PersistenceProviderProcessor[15:15:04] <Jaikiran> smarlow: you mean the case of a standalone hibernate deployment app?[15:15:06] <smarlow> Jaikiran: it might work better now since I disabled the PersistenceProviderProcessor. I want to bring PersistenceProviderProcessor back in but have it only look at TLD[15:15:19] <smarlow> Jaikiran: yup[15:16:16] <smarlow> I don't want to support container managed persistence with a provider that is in a standalone hibernate app. It has to be purely a native Hibernate app.[15:17:33] <Jaikiran> right[15:18:18] <Jaikiran> i'll also check with dmlloyd and check if he knows how the .war/WEB-INF/lib dependencies are handled[15:18:50] *** mbg has joined #jboss-as7[15:34:06] *** bstansberry has joined #jboss-as7[15:34:06] *** ChanServ sets mode: +v bstansberry[15:34:33] *** maeste has quit IRC[15:35:06] *** maeste has joined #jboss-as7[15:35:06] *** ChanServ sets mode: +v maeste[15:42:15] *** asaldhan has joined #jboss-as7[15:42:26] *** ChanServ sets mode: +v asaldhan[15:42:32] *** frainone has joined #jboss-as7[15:42:32] *** ChanServ sets mode: +v frainone[15:45:20] *** jamezp_afk has quit IRC[15:45:55] *** jamezp has joined #jboss-as7[15:47:10] *** jamezp has left #jboss-as7[15:47:27] <hbraun> darranl: ping[15:47:34] <darranl> hi hbraun[15:47:43] <hbraun> darranl: got a minute?[15:47:47] <darranl> sure[15:48:06] <hbraun> darranl: i've added the realm declarations[15:48:12] <hbraun> the DC is secure now[15:48:19] <hbraun> but it forces digest auth[15:48:29] <hbraun> do we support basic as well?[15:48:48] <darranl> at the moment we only fall back to basic if we really have to e.g. for LDAP[15:49:38] <hbraun> hm[15:50:01] *** torben has quit IRC[15:50:24] <hbraun> is it right that the autnetication is only enforced for /domain-api?[15:50:52] <hbraun> darranl: /console seems to be accessible[15:51:43] <darranl> hbraun, at the moment I have not restricted that as it can't do anything but if you think they should be propmpted to authenticate before even connectinging to the coneole I can add the authenticator there as well[15:51:46] *** kkhan has joined #jboss-as7[15:51:46] *** ChanServ sets mode: +v kkhan[15:51:57] *** pgier has joined #jboss-as7[15:51:57] *** ChanServ sets mode: +v pgier[15:53:46] <hbraun> yeah, chicken and egg problem[15:54:05] <hbraun> todo digest I need the nounce value[15:54:13] <hbraun> which I get when requesting a secure resource[15:54:35] <hbraun> but this again prompts the native browser login[15:55:18] *** vtunka has quit IRC[15:55:59] <hbraun> how does it work? is the authentication stateful? I mean does it remember the nounces?[15:56:15] *** fnasser has joined #jboss-as7[15:56:24] <hbraun> can I retrieve the nounce differently?[15:56:39] <hbraun> darranl: ^[15:57:16] *** torben has joined #jboss-as7[15:57:22] <darranl> no the nonce to use is 'decided' at the time the request is recieved and I am putting in a choice of nonce strategies so a nonce could be used often or just once[15:57:27] *** ChanServ sets mode: +v torben[15:57:44] <darranl> is there a problem leaving the browser to handle the auth requests natively?[15:57:56] *** mbg has quit IRC[15:58:10] <hbraun> well, you don't hold of the principal on the one hand[15:58:30] <hbraun> and logout is not possible w/o terminating the browser app[15:58:58] <hbraun> do you see what I mean?[15:59:24] <darranl> yeah with the HTTP mechanisms technically you are never 'logged in' to 'log out'[15:59:36] <hbraun> can we flush the authentication state? does it expire?[15:59:53] <darranl> what do you need the principal for? just display on the console or something in addition?[16:00:15] <hbraun> authorization at some point[16:00:19] <hbraun> but not yet[16:00:35] <hbraun> but brainstorming about my initial idea[16:00:47] <hbraun> why not retrieve a nounce though an alternative path?[16:01:07] <hbraun> will that be insecure?[16:01:12] <darranl> well the console wouldn't perform the actual authorization so maybe some form of 'who am I' or 'what can I do' operation may help when we get to authorization[16:01:20] *** jamezp has joined #jboss-as7[16:01:24] *** Nihility has joined #jboss-as7[16:01:25] *** ChanServ sets mode: +v Nihility[16:01:34] <darranl> yes seperating the nonce retrieval from the actual HTTP exchange would reduce the effectiveness of DIGEST[16:01:50] *** kkhan_ has joined #jboss-as7[16:01:53] <hbraun> it would still be requrested through http[16:02:15] *** OndejZizka is now known as OndrejZizka[16:02:20] <hbraun> let's say there is a non secure /nounce resource[16:02:27] <hbraun> to retrieve a nounce[16:02:37] *** OndrejZizka has quit IRC[16:02:37] *** OndrejZizka has joined #jboss-as7[16:02:37] *** verne.freenode.net sets mode: +v OndrejZizka[16:02:51] <hbraun> why would that be different then requesting is through /domain-api?[16:03:19] <hbraun> for /nounce the server wouldn't use the "WWW-AUthenticate" header[16:03:29] <hbraun> which prompts the native login[16:03:36] *** kkhan has quit IRC[16:03:42] <darranl> the problem is you don't know when to request it, the digest headers already take into account allowing for nonce replacement[16:03:50] <hbraun> is that really that much different?[16:04:16] <hbraun> i don't understand that last part[16:04:25] <hbraun> when to request it ?[16:04:50] <darranl> yeah depending on the nonce strategy in use on the server will depend on how often a new nonce will need to be created for that client[16:06:28] <hbraun> ok, but thats a folloup problem[16:06:34] <hbraun> followup problem, no?[16:06:43] <hbraun> i mean the nonce can expire[16:07:24] <hbraun> ok, let me think though the other use case[16:07:35] <hbraun> leveraging the native login probmpt[16:07:56] <hbraun> it would require the /console resource to be secure as well[16:08:00] *** kkhan_ has quit IRC[16:08:08] <darranl> the nonce (depending on chosen strategy) can need to be replaced for any number of reasons - strictly allowing singe use, tying a nonce to a specific connection, providing a nonce that can be used for a defined time[16:08:43] <hbraun> yes, in that case the browser would automatically prompt for authentication again[16:09:36] <hbraun> we don't have session management, right?[16:09:36] *** vtunka has joined #jboss-as7[16:09:36] *** ChanServ sets mode: +v vtunka[16:09:50] <darranl> no, the response from the server tells the browser the password is correct but a new digest needs to be generate so the browser will do it automatically from the cached password[16:10:17] <darranl> correct no session manegement as we don't have a need for an actual session yet[16:10:20] <hbraun> you mean the client wouldn't notice?[16:10:32] <hbraun> in case the nonce is revoked[16:10:56] <darranl> yes the browser is just told the nonce is stale and to use a new nonce but the client does not see this[16:10:59] <hbraun> or is a browser implementation detail[16:11:06] <darranl> no part of the spec[16:11:11] <hbraun> ok[16:12:19] <hbraun> how is the nonce related to a specific browser/client?[16:12:47] <hbraun> does the httpd just know which nonces are valid at a current time?[16:13:54] <darranl> I am putting in three strategies so an administrator can choose between strong protection against replay attacks and performance[16:14:16] <darranl> one extreme is a completely random nonce that can only be used once, these are stored in a cache until used[16:14:37] <hbraun> how does that look on the client side?[16:14:41] <darranl> other extreme is to generate a nonce that embeds a timestamp so it can be used many times and expire after a configured time[16:15:16] <hbraun> i assume clients keep the principal/credential for further requests[16:15:17] <darranl> middle ground is to generate a nonce that is valid as long as requests come in on same connection and a new nonce is created when the browser creates a new connection[16:15:43] <darranl> yes for all scenarios the browser would cache the principal/credential and just re-respond when challenged to use a new nonce[16:15:56] <hbraun> ok, so no login prompt[16:16:03] <darranl> if the response from the server also indicates the digest was completely invalid then that is the only time for a new login prompt[16:16:30] <hbraun> ah, the server indicates both: nonce invalid, digest invalid?[16:16:39] <hbraun> i c[16:16:44] <hbraun> thanks for the explanation[16:16:48] <darranl> on rejecting a request there is an attribute called 'stale'[16:17:09] <darranl> stale=true means the request was technically valid but for some reason the nonce is stale so please use this new nonce[16:17:29] <darranl> any other rejection assumes the digest was invalid so the credentials passed were not accepted[16:17:41] <mmoyses> bstansberry: Nihility: do we support deployment of xml files containing small parts of the domain model? for example i want to deploy a new appender with my application, or in my case a new security domain[16:17:42] <hbraun> ok[16:17:47] <hbraun> got that[16:18:25] <darranl> this is where digest gives the options to protect against replays without having to make SSL a requirement[16:18:28] <hbraun> darranl: can you think of a way to return the principal to the client after authentication was successful?[16:18:46] <hbraun> i.e custom XX-princpipal header?[16:18:56] <hbraun> or is it insecure already?[16:19:01] *** kcbabo has quit IRC[16:19:16] *** kcbabo has joined #jboss-as7[16:19:16] *** ChanServ sets mode: +v kcbabo[16:19:26] <hbraun> afaik digest sumbits the principla plain text anyway, no?[16:20:05] <darranl> yes that is already sent in plain[16:20:18] <hbraun> so we can safely return it plain text[16:20:29] *** galderz has quit IRC[16:20:33] <hbraun> because that way I could retrieve the username at least[16:20:50] *** galderz has joined #jboss-as7[16:20:50] *** ChanServ sets mode: +v galderz[16:20:52] <darranl> yes I don't see that as being an issue, the browser sends it in plain for every request[16:21:13] <hbraun> ok, i have to think about it[16:21:22] <hbraun> but thanks for the detailed explanation[16:21:31] <darranl> or we add a 'who-am-i' operation to gather info which could possibly be extended later to 'what-can-I-do'[16:21:34] <hbraun> i 'll switch to native login prompts then[16:21:49] <hbraun> that would be even better[16:21:57] <hbraun> how much effort would that be?[16:22:14] <hbraun> when you say operation, you mean an DMR operation?[16:22:18] <hbraun> or an http resource?[16:22:24] <hbraun> liek /whoami[16:22:36] <hbraun> or /theyarehere[16:22:45] <bstansberry> mmoyses: no. invoking management ops from deployers can lead to deadlocks in the core controller logic. Plus it's a security hole[16:23:03] <darranl> yes - I just need to work on this stuff I have been talking to Kabir today as we need to ensure consistency with the native calls but I don't see it as a big issue[16:23:15] <darranl> for audit reasons anyway we need to get this identity to the operations[16:23:36] <bstansberry> hbraun: looks like you pinged me a couple hours ago; when you're done w/ darranl give me a shout[16:23:44] <hbraun> ok, can you create an issue that I can track?[16:23:54] <hbraun> bstansberry: will fo[16:23:56] <hbraun> will do[16:24:17] <darranl> hbraun, you mean for the who-am-I type call?[16:24:58] <hbraun> darranl: yes, because then I won't look for a customization of the ConsoleHandler. Instead I would simply wait till you provide that operation[16:25:04] <hbraun> which makes sense IMO[16:25:20] <hbraun> :whoami()[16:25:41] <hbraun> can we add :meh() as well[16:25:43] <hbraun> ?[16:25:58] <hbraun> in response to an error response?[16:26:01] <darranl> ok will create it now - this also makes sense if we allow the browser to do native Kerberos auth (which is a popular request) as there is no client prompt at all[16:26:17] *** clebert has joined #jboss-as7[16:26:17] *** ChanServ sets mode: +v clebert[16:26:20] <hbraun> darranl: +1[16:26:35] <hbraun> darranl: the pincipal is fine to begin with[16:26:45] *** jamezp has left #jboss-as7[16:26:55] <hbraun> darranl: we can add authorization meta data when needed[16:27:20] <hbraun> darranl: then me the link, so I can track it[16:27:29] <darranl> yes later we could add an optional parameter if we want to retrieve an expanded response[16:28:34] <hbraun> thanks darran[16:30:53] <darranl> hbraun, no problem, here is the issue, feel free to add any comments / use case specifics if you want https://issues.jboss.org/browse/AS7-851[16:30:54] <jbossbot> jira [AS7-851] Add some form of :whoami operation [Open (Unresolved) Task, Major, Jason Greene] https://issues.jboss.org/browse/AS7-851[16:31:19] <hbraun> should i assign it to you?[16:31:43] <hbraun> done[16:31:53] <mmoyses> bstansberry: are there any alternatives to starting a new service along with an application you can think of?[16:32:03] *** torben has quit IRC[16:32:23] <darranl> hbraun, sorry was supposed to be assigned to me[16:32:31] <hbraun> i did it[16:32:51] <hbraun> bstansberry: ping[16:33:38] <bstansberry> hbraun: pong[16:33:58] <hbraun> bstansberry: question about the jvm subresources[16:34:18] <hbraun> they exist on server-group, server-config and host level[16:35:04] <hbraun> i assume they are overridden in the following order: host, server-group, server-config[16:35:14] <hbraun> rhs replaces lhs[16:35:29] <hbraun> bstansberry: ^correct?[16:35:44] <bstansberry> I don't think so; believe it's server-group,host,server-config[16:35:49] * bstansberry goes to look[16:36:14] <hbraun> yes, makes sense[16:36:57] <hbraun> a host is more specific then a server-group[16:36:58] *** fnasser has quit IRC[16:38:04] <bstansberry> yep; generally we want hosts to be able to override domain.xml stuff, as they know the local env[16:38:10] <hbraun> yes[16:38:17] *** fnasser has joined #jboss-as7[16:38:20] <hbraun> second question:[16:38:53] <hbraun> server-group and server-config have a single jvm declaration, but host has multiple (named) ones[16:38:57] <hbraun> correct?[16:39:41] <bstansberry> but, looking at the code, it's actually host,s-g,s-c[16:40:04] <bstansberry> kkhan: any idea why this is? in JvmElement?[16:40:24] * bstansberry expects its because he wrote it that way long ago[16:40:25] <hbraun> bstansberry: you are still responding to the first question, right?[16:40:44] <bstansberry> yep; i looked at code to verify my opinion[16:40:49] <bstansberry> that was a mistake ;)[16:41:28] <bstansberry> hbraun: 2nd question: yes, correct[16:41:49] <hbraun> back to the seecond q:[16:42:05] <hbraun> what role does the name play for s-g and s-c?[16:42:13] *** bobmcw_ is now known as bobmcw[16:42:13] *** bobmcw has quit IRC[16:42:14] *** bobmcw has joined #jboss-as7[16:42:23] <hbraun> i.e. if I have just a named jvm ref, w/o any attributes?[16:42:32] <dmlloyd> good morning[16:42:38] <hbraun> does it refer to a host jvm setting by that name[16:42:39] <hbraun> ?[16:42:41] <hbraun> morning[16:42:44] *** mlinhard has quit IRC[16:42:45] <hbraun> it's you again[16:42:49] <hbraun> i am still here[16:42:49] <bstansberry> hbraun: yes, it's what allows the host one to be foun[16:43:01] <bstansberry> good morning[16:43:04] <hbraun> what if the host doesn't have one by that name?[16:43:45] <dmlloyd> yes me again[16:43:46] *** fnasser has quit IRC[16:43:49] <hbraun> ;)[16:43:49] <dmlloyd> I cannot be rid of so easily[16:44:06] <bstansberry> then the host part of the merging is ignored[16:44:12] *** fnasser has joined #jboss-as7[16:44:18] <pilhuhn> bstansberry Is there a document that describes the current version of the deployment stuff? I get strange errors - except for the very first deployment on a fresh build. This used to work and now I am trying to follow the recent changes in that area[16:45:00] <hbraun> bstansberry: thanks, then it basically works the way I expected it[16:45:16] <hbraun> bstansberry: just making sure I implement it properly[16:45:34] <bstansberry> haha, that's a first ;)[16:45:44] <bstansberry> laughing at our impl, not your expectations![16:46:06] <hbraun> bstansberry: what do you mean?[16:46:31] <bstansberry> sorry, i typed that before your "just making sure comment"[16:46:50] <hbraun> ;)[16:46:59] <bstansberry> I was joking that our impls are wacked and usually don't meet expectations[16:47:40] *** jamezp has joined #jboss-as7[16:47:52] <hbraun> well, i hope the resolution of jvm properties is correctly implemented ;)[16:48:12] <hbraun> doesn't look trivial[16:48:21] <bstansberry> pilhuhn: no document. what exactly are you doing[16:48:45] <pilhuhn> Json to send: {"address":[{"deployment":"test.war"}],"operation":"add","runtime-name":"test.war","content":[{"hash":{"BYTES_VALUE":"7jgpMVmynfxpqp8UDleKLmtgbrA="}}],"name":"7jgpMVmynfxpqp8UDleKLmtgbrA="}[16:48:45] <pilhuhn> ==> {"outcome" : "success", "result" : null, "compensating-operation" : {"operation" : "remove", "address" : [{"deployment" : "test.war"}]}}[16:48:45] <pilhuhn> Add to /deploy done {"outcome":"success","result":null,"compensating-operation":{"operation":"remove","address":[{"deployment":"test.war"}]}}[16:48:45] <pilhuhn> Json to send: {"address":[{"server-group":"main-server-group"},{"deployment":"test.war"}],"operation":"add","enabled":"true"}[16:48:57] <pilhuhn> ==> {"outcome" : "failed", "result" : {"server-groups" : {"main-server-group" : {"server-two" : {"host" : "local", "response" : {"outcome" : "failed", "failure-description" : "org.jboss.msc.service.DuplicateServiceException: Service jboss.deployment.unit.\"test.war\".contents is already registered"}}, "server-one" : {"host" : "local", "response" : {"outcome" : "failed", "failure-description" : "org.jboss.msc.service.DuplicateServiceException: Servic[16:48:57] <pilhuhn> s.deployment.unit.\"test.war\".contents is already registered"}}}}}, "failure-description" : "Operation was not applied successfully to any servers"}[16:49:05] * pilhuhn should have used a pastebin[16:51:05] <hbraun> pilhuhn: what a mess ;)[16:51:09] <bstansberry> "name":"7jgpMVmynfxpqp8UDleKLmtgbrA=" in the first command is weird[16:52:08] <pilhuhn> bstansberry that whole name/runtime-name thing is still questionable to me. As the description says the *§$@!! name needs to be unique accross all deployments, I think the sha is the best name - no?[16:52:38] <bstansberry> in any case it needs to match the address in the 2nd command: "deployment":"7jgpMVmynfxpqp8UDleKLmtgbrA="[16:53:11] <bstansberry> the issue is the user doesn't know the sha[16:54:33] *** mbg has joined #jboss-as7[16:54:33] *** ChanServ sets mode: +v mbg[16:56:03] <pilhuhn> why does then the server say "already registered " and not "unknown" ? hm ok[16:56:46] <bstansberry> pilhuhn: thinking about that[16:57:41] *** torben has joined #jboss-as7[16:57:41] *** torben has quit IRC[16:57:41] *** torben has joined #jboss-as7[16:57:41] *** ChanServ sets mode: +v torben[16:59:34] <bstansberry> pilhuhn: my guess is you already had "test.war" deployed[17:00:03] <pilhuhn> I still think that the user wants to upload different versions of test.war without having to invent different names himself[17:00:29] <pilhuhn> bstansberry this also happens when I clean out /server-group=main-sg/deployment=test.war and /deploment=test.war[17:00:31] <bstansberry> sounds to me like a good problem for a tool to solve :)[17:00:41] <pilhuhn> tool = AS7 :-)[17:00:58] <pilhuhn> I'll look around further[17:04:33] <asoldano> Jaikiran, wolfc: Richard already asked you about one of the regressions after the big ejb3 merge few days ago; while he's away, does this http://fpaste.org/hvqL/ tell somethin to you / can suggest how to ask for directions/explanations?[17:04:52] <asoldano> s/how/who[17:05:07] * Jaikiran looks[17:05:09] <wolfc> dmlloyd: injection is broken in general ^[17:05:22] <asoldano> that seems related to the @Resource WebServiceContext ctx in my bean[17:05:30] <wolfc> there is a big TODO in...[17:05:31] <Jaikiran> asaldhan: it's either me or stuart who has to look into this[17:05:36] <Jaikiran> oops[17:05:39] <Jaikiran> asoldano: ^[17:05:51] <Jaikiran> can you file a JIRA with the testcase which is failing?[17:05:59] <Jaikiran> either of us will pick it up[17:06:01] <asoldano> Jaikiran, sure, doing that now[17:06:13] <wolfc> ResourceInjectionAnnotationParsingProcessor[17:06:38] <pilhuhn> bstansberry I got it:[17:06:48] <pilhuhn> [domain@localhost:9999 /] /server-group=main-server-group/deployment=test.war:add(name=test.war)[17:06:50] <pilhuhn> works[17:07:00] <pilhuhn> [domain@localhost:9999 /] /server-group=main-server-group/deployment=test.war:add(name=test.war,enabled=true)[17:07:02] <pilhuhn> fails[17:07:37] <asoldano> Jaikiran, I'll also check Richard puts a @Resource WebServiceContext ctx member in one of the smoke tests he's adding to the AS7 testsuite[17:07:55] <Jaikiran> asoldano: yeah, that would be great. being able to test it in smoke-tests[17:08:42] <hbraun> maeste: ping[17:08:57] *** hbraun has quit IRC[17:09:09] <asoldano> Jaikiran, the reason for my request, though, is that afaik atm the injection of WebServiceContext members was not handled by the AS itself, but by jbossws[17:09:37] <asoldano> Jaikiran, probably that's going to change..[17:09:51] <Jaikiran> asoldano: how was the WebServiceContext setup by jbossws? ultimately it had to end up in the ENC of the component[17:10:09] <wolfc> wasn't SwitchB handling it in AS 6?[17:10:16] <bstansberry> mmoyses: you asked before about installing a service to update management?[17:10:24] <Jaikiran> they had a WS...Provider[17:10:35] <Jaikiran> so technically, switchboard allowed them to plugin their impl[17:10:56] <Jaikiran> so i don't really know how the WSContext was created[17:10:57] <asoldano> Jaikiran, ah, yes, we used switchboard, but the instance is probably still built by us, Richard worked on that, I need to check[17:11:03] <Jaikiran> right[17:11:17] <mmoyses> bstansberry: yes, for https://issues.jboss.org/browse/AS7-838[17:11:19] <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[17:12:00] *** vtunka has quit IRC[17:15:52] <asoldano> Jaikiran, AS7-852[17:15:53] <jbossbot> jira [AS7-852] No component found for type 'javax.xml.ws.WebServiceContext' [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/AS7-852[17:16:17] <Jaikiran> thanks, i'll take a look[17:16:23] <asoldano> Jaikiran, thank you[17:16:59] *** aloubyansky has joined #jboss-as7[17:18:00] *** darranl has quit IRC[17:18:15] <wolfc> Jaikiran, I've raised the stakes of AS7-852 to something more general[17:18:16] <jbossbot> jira [AS7-852] No component found for type '...' [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/AS7-852[17:18:31] <Jaikiran> makes sense[17:19:24] <bstansberry> mmoyses: sorry, was having system troubles[17:19:56] <Jaikiran> dmlloyd: got a minute for a module CL and web app deployment related discussion?[17:19:58] <bstansberry> this is related to similar requests people have for deploying datasources, deploying JMX resources[17:20:31] <dmlloyd> Jaikiran: sure[17:20:32] <bstansberry> Nihility: do you want to support deploying security domains?[17:20:40] <dmlloyd> I'll be around for about another hour[17:20:45] <dmlloyd> then I"ll be gone for a bit[17:20:50] *** alexsmirnov has joined #jboss-as7[17:20:54] <Jaikiran> dmlloyd: me and smarlow were discussing about AS7-836[17:20:56] <jbossbot> jira [AS7-836] non JPA (native Hibernate) app using hibernate doesn't cause org.hibernate classes to be loaded [Open (Unresolved) Bug, Major, Scott Marlow] https://issues.jboss.org/browse/AS7-836[17:20:56] <bstansberry> ^^^ is the first question. if yes, all such cases we'll support should be consistent[17:21:20] <Jaikiran> typically, in a EE deployment (for example .war) all the jars in the .war/WEB-INF/lib are expected to be in the CP of the application[17:21:30] <Jaikiran> and users can use those classes in their code[17:21:34] <bstansberry> and yes, the impl would involve deploying services directly, not making calls to the management layer. such services would be "unmanaged"[17:22:06] <Jaikiran> but it looks like in the current way, they will have to explicitly add a Dependencies to those libraries (and also first create them as modules)?[17:22:22] <pilhuhn> AS7-853[17:22:23] <jbossbot> jira [AS7-853] :add deploment on server group with enabled=true fails [Open (Unresolved) Bug, Major, Jason Greene] https://issues.jboss.org/browse/AS7-853[17:22:32] <bstansberry> the management layer might be able to expose a runtime-only view of them, but we'd have to keep that separate and distinct from the true ones[17:22:40] <Jaikiran> so for example, someone has a blah.jar in .war/WEB-INF/lib and has a Foo.class in it[17:22:56] <bstansberry> pilhuhn: please assign such jiras to "Domain Management" component[17:23:02] <pilhuhn> ok[17:23:02] <Jaikiran> if they want to access that Foo.class from some servlet in the .war, they will have to create blah as a module and a dep on that?[17:23:06] <bstansberry> i'm doign that now[17:25:14] *** bstansberry has quit IRC[17:26:09] *** vtunka has joined #jboss-as7[17:26:09] *** ChanServ sets mode: +v vtunka[17:27:41] <dmlloyd> Jaikiran: stuartdouglas is working on AS7-388[17:27:42] <jbossbot> jira [AS7-388] Detect, filter, and act upon system APIs found in deployments [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/AS7-388[17:28:01] <dmlloyd> the idea is if they have hibernate in their deployment it'd automatically filter it and add a dep on org.hibernate[17:28:07] <dmlloyd> unless they specify otherwise[17:28:34] <Jaikiran> yeah, that would take care of well known libraries[17:28:46] <Jaikiran> but what about app specific libraries which belong to the app themselves[17:28:54] <Jaikiran> or some not so well known libraries[17:29:11] <Jaikiran> wouldn't it violate the spec that those classes won't be found in the app CP?[17:29:32] <Jaikiran> (unless they explicitly add the Dependencies in MANIFEST.MF and yeah create a module out of it)[17:30:34] <dmlloyd> oh, those should be found[17:30:50] <dmlloyd> WEB-INF/lib should be on there[17:30:52] <dmlloyd> that did work at one time[17:30:58] <dmlloyd> so if it quit working it's a regression[17:31:06] <Nihility> why not use add all of our "public" APIs[17:31:10] <Nihility> to every EE deployment[17:31:17] <Nihility> and let them exclude it otherwise[17:31:32] <dmlloyd> we could do that, it's never really been decided[17:31:38] *** bstansberry has joined #jboss-as7[17:31:39] *** ChanServ sets mode: +v bstansberry[17:31:42] <dmlloyd> every time I ask everyone just looks at their shoes :)[17:31:47] <Nihility> hahaha[17:31:50] <Nihility> including me![17:32:03] <dmlloyd> I"d be willing to say that we include all public APIs by default though[17:32:34] <dmlloyd> maybe if we do that, plus parent-first CL for all those deps, then we don't need AS7-388 at all[17:32:35] <jbossbot> jira [AS7-388] Detect, filter, and act upon system APIs found in deployments [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/AS7-388[17:34:55] <dmlloyd> Jaikiran: do we have a jira for the default interceptor thing?[17:35:07] <Jaikiran> dmlloyd: not yet.[17:35:14] <dmlloyd> okay I'll open one[17:35:18] <Jaikiran> wolfc: did you create one for DD parsing and merging?[17:35:35] <Jaikiran> (it would fall in that category since default interceptors come from DD)[17:36:42] <dmlloyd> AS7-854[17:36:43] <jbossbot> jira [AS7-854] Default interceptors are not applied [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/AS7-854[17:38:58] *** AndyTaylor has quit IRC[17:40:09] *** jcosta has quit IRC[17:41:51] *** irooskov has quit IRC[17:43:11] *** mmoyses is now known as mmoyses_[17:46:55] *** tdiesler has joined #jboss-as7[17:46:55] *** ChanServ sets mode: +v tdiesler[17:47:21] *** frainone has quit IRC[17:49:24] <asoldano> wolfc, Jaikiran: another (different?) one http://fpaste.org/mhvJ/[17:49:45] <Jaikiran> asoldano: looks different[17:49:53] <Jaikiran> what the does the deployment look like?[17:51:00] <Jaikiran> asoldano: does that component class have a no-arg constructor?[17:51:10] <Jaikiran> anyway, the error message should have been more appropriate[17:51:17] <Jaikiran> so one more JIRA please :)[17:51:25] <asoldano> Jaikiran, http://fpaste.org/9OWX/[17:51:36] <asoldano> Jaikiran, it's a war with 3 classes and that web.xml[17:52:01] <Jaikiran> hmm that looks fine to me[17:52:07] * Jaikiran takes a look at the log and code[17:52:19] <asoldano> Jaikiran, if you want, I can send you the war[17:52:26] <Jaikiran> asoldano: that would be great[17:53:45] <asoldano> Jaikiran, sent[17:54:54] <asoldano> Jaikiran, to be honest, this second one is less critical to us, but the error might indicate a more general issue...[17:59:36] *** pilhuhn has quit IRC[18:01:26] <Jaikiran> asoldano: i get a different error for that one http://pastie.org/1927336[18:02:07] <asoldano> Jaikiran, ah, yes, forgot to tell that's a testcase for jbossws-native stack[18:02:34] <Jaikiran> do i have to toggle some config?[18:02:53] <asoldano> Jaikiran, leave that for the future... I'll create a jira, explain how to setup the AS, etc.[18:02:59] <Jaikiran> asoldano: sure[18:03:37] *** mbg is now known as mbg|afk[18:05:28] * Jaikiran will be away for a while[18:05:40] *** Jaikiran has quit IRC[18:06:34] *** hardy_ has left #jboss-as7[18:09:54] *** alesj has joined #jboss-as7[18:09:58] *** rawbdor has quit IRC[18:11:07] *** miclorb_ has joined #jboss-as7[18:11:56] <jbossbot> git [jboss-as] push master 32c0c0a.. Marcus Moyses fixing xsd[18:11:56] <jbossbot> git [jboss-as] push master d08ee61.. Marcus Moyses fixing descriptions[18:11:56] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1b13aac...d08ee61[18:16:12] <pgier> I'm getting a timeout error in the arquillian container managed testcase[18:16:15] <pgier> java.util.concurrent.TimeoutException: Managed server was not started within [10000] ms[18:16:44] <pgier> this is running on a slow machine, so it's possible it's just a normal timeout[18:16:58] <pgier> how can I increase the timeout for this?[18:17:03] *** torben has quit IRC[18:17:34] <pgier> it's this test case: Test set: org.jboss.as.arquillian.container.managed.IntegrationTestCase[18:20:14] <jpederse> pgier: try arquillian/common/src/main/java/org/jboss/as/arquillian/container/JBossAsContainerConfiguration.java :/[18:20:36] <aslak> pgier, you need to set startupTimeoutInSeconds in arquillian.xml[18:20:37] <jpederse> pgier: better file a JIRA on that - externalize ARQ config[18:21:24] <aslak> jpederse, pgier that is the mapping object used between arq.xml and the container. it is externalized[18:21:44] *** alesj has quit IRC[18:21:48] <jpederse> aslak: ah, k - the property just isn't defined there[18:21:55] <jpederse> ... yet[18:22:11] <aslak> it is in arquillian2[18:22:19] <aslak> https://github.com/jbossas/jboss-as/blob/master/arquillian2/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/JBossAsManagedConfiguration.java[18:22:23] *** OndrejZizka is now known as ozizka[18:22:28] <pgier> aslak, like this right? <property name="startupTimeoutInSeconds">20</property>[18:22:34] <jpederse> pgier: arquillian2/container-managed/src/test/resources/arquillian.xml[18:22:56] *** ozizka is now known as OndrejZizka[18:23:17] <aslak> pgier, what jesper said.. :)[18:23:33] <pgier> yep, I think I got it now, thanks guys[18:25:43] *** aloubyansky has quit IRC[18:29:39] *** jfclere has quit IRC[18:49:02] *** clebert has quit IRC[18:51:50] *** asoldano has quit IRC[18:52:28] *** smcgowan has quit IRC[18:53:07] *** smcgowan has joined #jboss-as7[18:53:08] *** ChanServ sets mode: +v smcgowan[18:57:10] *** ALR has joined #jboss-as7[18:57:10] *** ChanServ sets mode: +v ALR[19:07:38] *** pferraro has joined #jboss-as7[19:07:38] *** ChanServ sets mode: +v pferraro[19:12:57] *** tdiesler has quit IRC[19:14:55] <wolfc> pgier, ALR, that reminds me I got https://github.com/wolfc/jboss-as/commit/537191d8960ff0f3f08e9d812f391dce4f26365b (which is similar to AS7-730 patch)[19:14:57] <jbossbot> jira [AS7-730] Arquillian Managed Container Startup Timeout Message is wrong [Resolved (Done) Bug, Major, Andrew Rubinger] https://issues.jboss.org/browse/AS7-730[19:14:57] <jbossbot> git [jboss-as] 537191d.. Carlo de Wolf Increase startup timeout and always destroy the process if timed out[19:16:03] <ALR> wolfc: You make a pull request for that?[19:16:21] <ALR> Mine doesn't do any process-destroying, just fixes the message[19:17:07] <wolfc> ALR, it conflicts with your one as it stands[19:17:59] <ALR> wolfc: Right, you could apply yours instead.[19:17:59] <wolfc> It'll probably be rebased soon, it's part of the ejb3 testing branch.[19:18:22] <ALR> Yeah, this one over mine wouldn't make for problems[19:18:34] <ALR> Mine's a one-line dealie which just fixes the message[19:24:20] <jbossbot> git [jboss-as] push master 810cca4.. Jason T. Greene Error when enable-welcome-root=true and someone deploys a root context[19:24:21] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/d08ee61...810cca4[19:34:21] <pgier> ALR, wolfc: should the same error message be fixed in arquillian 1?[19:34:41] <ALR> pgier: That'll go the way of the dodo.[19:34:46] *** frainone has joined #jboss-as7[19:34:46] *** ChanServ sets mode: +v frainone[19:36:30] *** mmoyses_ is now known as mmoyses[19:45:06] *** emmanuel has quit IRC[19:45:21] *** mlinhard has joined #jboss-as7[19:55:12] *** galderz has quit IRC[19:57:34] *** stansilvert has joined #jboss-as7[20:02:02] *** epbernard has joined #jboss-as7[20:02:02] *** epbernard is now known as emmanuel[20:02:02] *** ChanServ sets mode: +v emmanuel[20:02:11] *** emmanuel has quit IRC[20:10:15] *** opalka has joined #jboss-as7[20:10:15] *** ChanServ sets mode: +v opalka[20:12:43] *** mbg|afk is now known as mbg[20:12:50] *** bstansberry has quit IRC[20:13:09] *** mlinhard has quit IRC[20:16:32] <jamezp> dmlloyd: You around?[20:33:56] *** lazarotti has joined #jboss-as7[20:42:22] *** sannegrinovero has quit IRC[20:45:20] *** jc3 has quit IRC[20:51:33] *** davidbos1 has quit IRC[20:51:37] *** davidbos has joined #jboss-as7[20:51:48] *** davidbos has quit IRC[20:56:04] *** hardy_ has joined #jboss-as7[20:56:04] *** jamezp has quit IRC[20:56:52] *** jc3 has joined #jboss-as7[20:56:52] *** ChanServ sets mode: +v jc3[20:58:31] *** stansilvert has quit IRC[20:58:46] *** jamezp has joined #jboss-as7[20:58:52] *** clebert has joined #jboss-as7[20:58:52] *** ChanServ sets mode: +v clebert[21:01:30] *** jamezp is now known as jamezp_afk[21:19:57] *** jwulf has joined #jboss-as7[21:23:21] *** pferraro has quit IRC[21:23:26] *** maeste has quit IRC[21:23:29] *** alesj has joined #jboss-as7[21:24:22] *** lazarotti has quit IRC[21:24:55] *** lazarotti has joined #jboss-as7[21:35:10] *** pferraro has joined #jboss-as7[21:35:10] *** ChanServ sets mode: +v pferraro[21:39:23] *** galderz has joined #jboss-as7[21:39:24] *** ChanServ sets mode: +v galderz[21:46:30] *** tdiesler has joined #jboss-as7[21:46:30] *** ChanServ sets mode: +v tdiesler[21:46:53] <tdiesler> dmlloyd, ping[21:48:32] <tdiesler> dmlloyd, when I add and install a service I assume that it is guaranteed that a subsequent call to ServiceContainer.getService(...) will find it, right?[21:51:06] *** pferraro has quit IRC[22:00:12] *** mgoldmann has quit IRC[22:00:25] <dmlloyd> back[22:00:44] <dmlloyd> tdiesler: yes, as long as it is installed[22:01:09] *** galderz has quit IRC[22:02:25] <dmlloyd> jamezp_afk: what's up[22:02:39] *** jamezp_afk is now known as jamezp[22:03:13] *** pferraro has joined #jboss-as7[22:03:13] *** ChanServ sets mode: +v pferraro[22:03:16] <jamezp> dmlloyd: What do we want to do about something like this? https://github.com/jamezp/jboss-as/blob/logging/connector/src/main/java/org/jboss/as/connector/metadata/deployment/AbstractResourceAdapterDeploymentService.java#L202[22:03:56] <jamezp> A logger in a constructor that extends an object in a library.[22:05:05] <dmlloyd> file a bug and assign it to those guys[22:05:10] <dmlloyd> JCA subsys[22:05:16] <dmlloyd> that's a broken design and we can't sustain it[22:05:23] <dmlloyd> logger per instance is also a bad idea[22:05:34] <dmlloyd> no reason that we can't just use static loggers[22:05:49] <dmlloyd> or just fix the base class yourself[22:06:03] <jamezp> No problem. I'll take a look.[22:06:34] <jamezp> dmlloyd: Oh, last question. Should I make one commit per subsystem or one large commit?[22:08:23] <dmlloyd> one commit per subsystem please[22:09:37] <jamezp> Perfect, I had a feeling it could grow rather large the other way.[22:11:43] <dmlloyd> yeah this way we'll be able to make progress even if there's a holdup on one subsystem[22:11:52] <dmlloyd> do you have that allocations page started?[22:12:14] <jamezp> Started, but I need to publish it.[22:14:11] <jamezp> dmlloyd: Okay, published http://community.jboss.org/wiki/LoggingIds[22:14:34] <dmlloyd> cool[22:16:08] <dmlloyd> sguilhen: are your latest changes pushed out to github?[22:16:22] <dmlloyd> I want to review your module files to rule out anything obvious[22:16:39] <sguilhen> dmlloyd: it was a simple change I can push it now[22:16:39] <dmlloyd> but I have a suspicion that the javax.rmi stuff is being referenced from the JDK somehow[22:17:03] <sguilhen> dmlloyd: that is weird, wasn't happening before[22:20:08] *** smarlow has quit IRC[22:21:49] <sguilhen> dmlloyd: I pushed the change: https://github.com/sguilhen/jboss-as/commit/006259e58642c5e0e58a8688643bc69c568d1300#diff-50[22:21:50] <jbossbot> git [jboss-as] 006259e.. Stefan Guilhen [AS7-405][AS7-425]: Adds the IIOP subsystem and integrates JacORB.[22:21:52] <jbossbot> jira [AS7-405] IIOP subsystem [Open (Unresolved) Task, Major, Stefan Guilhen] https://issues.jboss.org/browse/AS7-405[22:21:53] <jbossbot> jira [AS7-425] Integrate JacORB [Open (Unresolved) Task, Major, Stefan Guilhen] https://issues.jboss.org/browse/AS7-425[22:23:41] <sguilhen> it was a simple change in CorbaServiceUtil. It now uses ValueManagedReferenceFactory when binding stuff to JNDI[22:25:31] <sguilhen> dmlloyd: I tried downgrading modules to 1.0.0.CR1 and I got errors in the web subsystem, but the IIOP subsystem starts fine[22:25:51] *** clebert has quit IRC[22:26:01] <dmlloyd> sguilhen, can you grep through your modules directory and make sure nothing (other than org.jboss.modules and javax.api) are using the system module?[22:26:02] *** hardy_ has left #jboss-as7[22:26:03] *** alesj has quit IRC[22:26:22] <sguilhen> sure[22:26:36] <dmlloyd> I'd check it out but I'm in the middle of two different things already[22:26:42] <dmlloyd> I draw the line at two full checkouts of AS :)[22:27:10] <sguilhen> dmlloyd: grep yielded this:[22:27:12] <sguilhen> ./javax/api/main/module.xml[22:27:13] <sguilhen> ./javax/xml/stream/api/main/module.xml[22:27:13] <sguilhen> ./com/sun/xml/messaging/saaj/main/module.xml[22:27:13] <sguilhen> ./org/jboss/modules/main/module.xml[22:27:56] <dmlloyd> hm okay[22:27:59] *** tdiesler has quit IRC[22:28:00] <dmlloyd> I think that's correct[22:29:35] *** wolfc has quit IRC[22:30:14] *** pferraro has quit IRC[22:34:23] <jamezp> dmlloyd: I mistakenly committed the transactions and clustering the in the same commit.[22:34:33] <dmlloyd> you're fired![22:34:51] <jamezp> dmlloyd: When you get a chance can you make sure I'm on the right track :-) https://github.com/jamezp/jboss-as/commit/479f4943e803d71df7d85369374fe3346f3ed506[22:34:52] <jbossbot> git [jboss-as] 479f494.. James Perkins AS7-809 Use logging tool to create messages and loggers. Convert throwables and logs to use the new interfaces.[22:34:53] <jbossbot> jira [AS7-809] Convert modules to use JBoss Logging and message bundles [Open (Unresolved) Task, Major, James Perkins] https://issues.jboss.org/browse/AS7-809[22:34:54] <dmlloyd> don't worry about it, it probably doesn't matter[22:34:58] <dmlloyd> okay will do[22:35:15] <jamezp> I figured since it was small enough.[22:35:57] <dmlloyd> sguilhen: I don't suppose you know what version of Modules you were using before the rebase?[22:36:02] <jamezp> Last thing we need to do, if it looks okay of course, is release Beta7 of the logging tools. That has the overloaded method support.[22:36:12] <sguilhen> dmlloyd: I do, it was 1.0.0.Beta17[22:36:13] <dmlloyd> okay will do that asap[22:36:25] <dmlloyd> sguilhen: okay. I can at least check if anything significant changed...[22:36:48] <sguilhen> dmlloyd: all version up to CR1 are fine[22:36:56] <jbossbot> git [jboss-as] push master 3fdaa5a.. John E. Bailey [AS-771] - Add additional operations to support updating logging configuration[22:36:57] <jbossbot> git [jboss-as] push master c1048f2.. Stuart Douglas Update classfilewriter[22:36:57] <jbossbot> git [jboss-as] push master 522aa0e.. Stuart Douglas Change managed bean processor to look for additional JSF config files[22:36:57] <jbossbot> git [jboss-as] push master eceb2d4.. Stuart Douglas AS7-840 add support for javax.annotations.EJBs[22:36:57] <jbossbot> jira [AS7-840] Add a @javax.ejb.EJBs processor [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/AS7-840[22:36:58] <jbossbot> git [jboss-as] push master 7c8451f.. Stuart Douglas Update jboss metadata[22:36:58] <jbossbot> git [jboss-as] push master 91933bf.. jaikiran Fixed minor typo in comments[22:36:58] <jbossbot> git [jboss-as] push master 11b2225.. jaikiran Fix processing of @PersistenceContext on fields to use the correct ENC name for the binding[22:36:58] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/810cca4...11b2225[22:37:19] <dmlloyd> sguilhen: up to but not including?[22:37:34] <sguilhen> I mean, if I change jboss-modules.jar to the CR1 version I get an error when starting the web subsystem, but the IIOP subsystem starts fine[22:37:41] <sguilhen> dmlloyd: including CR1[22:37:51] <dmlloyd> ah interesting[22:38:12] <sguilhen> that should narrow it down a bit further :)[22:39:02] <jpederse> Nihility: can you delete http://community.jboss.org/message/606152#606152 ?[22:39:37] <dmlloyd> sguilhen: the weird thing is I don't really see any significant differences[22:41:03] <sguilhen> dmlloyd: I really don't know whats going on. I find it strange that it is using the org.jboss.as.standalone module to load that class. I may be mistaken, but shouldn't the org.jboss.as.iiop module be doing that instead?[22:41:30] <sguilhen> what makes it worse is that the failure is not consistent. Sometimes the server boots fine[22:41:32] <dmlloyd> the problem is that the JVM deletes stack frames[22:41:42] <dmlloyd> it's linking some class, transitively out to that module[22:42:00] <dmlloyd> I don't know why it wouldn't be consistent thoguh[22:42:20] <dmlloyd> could you try enabling TRACE logging for org.jboss.modules?[22:42:24] <sguilhen> sure[22:42:29] <dmlloyd> it's noisy as hell but maybe it'll give a clue[22:42:40] <sguilhen> ok, I'll try that[22:42:42] <dmlloyd> logging will probably make the problem go away :)[22:43:30] <jpederse> Nihility: nm[22:43:50] <Nihility> sguilhen: any chance that code is using TCCL[22:44:10] <Nihility> the JDK corba code that is[22:44:25] <dmlloyd> well the question is, how is the JDK code being loaded in the first place[22:44:33] <dmlloyd> TCCL is a good guess though[22:44:46] <dmlloyd> if TCCL is null and something tries to load a corba class it'd hti the JDK[22:44:53] <dmlloyd> I don't know why it would be inconsistent though[22:44:57] <dmlloyd> seemed more like a race condition[22:45:17] <dmlloyd> tdiesler is also observing something race-like :-/[22:45:33] <dmlloyd> could be a problem with linking, somehow[22:45:40] <Nihility> well the thing loading is in an executor right[22:45:57] <dmlloyd> http://community.jboss.org/message/606146#606146[22:46:01] <dmlloyd> it's an MSC service thread[22:46:02] <dmlloyd> so yeah[22:46:21] <Nihility> yeah so who knows what value TCCL is[22:46:33] *** smcgowan is now known as smcgowan_dinner[22:46:40] <dmlloyd> presumably it's either null or set by the service[22:46:47] <dmlloyd> we're pretty well-behaved in service threads[22:46:50] <Nihility> or it was set by another service[22:46:56] <Nihility> in the same thread[22:47:00] <Nihility> and never reset to null[22:47:03] <dmlloyd> though good point, I should have MSC reset the TCCL after each task[22:47:22] <dmlloyd> yeah that would explain the random behavior[22:47:36] <Nihility> maybe it should be set to the service class' class loader[22:47:46] <dmlloyd> that's an interesting idea[22:47:50] <dmlloyd> yeah I like that[22:47:51] <dmlloyd> will do it[22:49:12] <dmlloyd> MSC-96[22:49:14] <jbossbot> jira [MSC-96] Set TCCL before and after user tasks [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/MSC-96[22:49:22] *** mmoyses has quit IRC[22:50:21] <Nihility> imo we should follow that pattern everywhere it will at least fix problems with using certain JDK APIs[22:51:00] <dmlloyd> yeah[22:51:14] <Nihility> i meant o suggest it before[22:51:15] <dmlloyd> modules already sets TCCL on the main thread when kicking it off[22:51:20] <Nihility> but it fell off the priority list[22:51:48] <dmlloyd> nice thing is if we control the executor we can set it without a privileged block a lot of times[22:52:44] *** opalka has quit IRC[22:52:46] <Nihility> cool[22:53:08] <dmlloyd> should do the same for jboss threads[22:55:18] *** fnasser has quit IRC[22:55:50] <dmlloyd> JBTHR-20[22:55:51] <jbossbot> jira [JBTHR-20] Set TCCL before and after executor tasks [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBTHR-20[22:56:19] *** mbg has quit IRC[22:56:41] <Nihility> we probably should do it for extensinos/subsystems as well[22:56:54] <dmlloyd> op handlers you mean?[22:56:58] <dmlloyd> deployers?[22:57:04] <dmlloyd> dunno that might be going a little far :)[22:57:16] <Nihility> yeah i was thinking op handlers[22:57:19] <Nihility> but maybe thats stupid[22:57:35] <dmlloyd> could be doable[22:57:45] <Nihility> mainly subsystem add[22:59:36] *** misty has joined #jboss-as7[22:59:45] <sguilhen> Nihility: phone call, sorry. The javax.rmi.CORBA.Stub was using TCCL but I changed it. When the startup fails, you can see that the javax.rmi code is coming from the JDK and not from the javax.rmi.api module[22:59:51] *** kevinpollet has joined #jboss-as7[23:01:45] *** liweinan has quit IRC[23:01:51] <Nihility> sguilhen: what does at org.jacorb.orb.Delegate.getReference(Unknown Source) do[23:02:15] *** liweinan has joined #jboss-as7[23:02:53] <sguilhen> Nihility: it creates an org.jacorb.orb.Referece which extends javax.rmi.CORBA.Stub[23:03:48] <Nihility> ok yep i see that now[23:03:55] <Nihility> so the module definition[23:03:58] <Nihility> for jacorb[23:04:02] <Nihility> can you pastebin that[23:04:59] <dmlloyd> it's in his github tree[23:05:05] <dmlloyd> I checked em all out, it looks ok[23:05:18] <sguilhen> Nihility: http://pastebin.com/0nQjGkWB[23:06:06] <Nihility> ok yeah so basically this call path is[23:06:30] <Nihility> service->jacorb->javax.rmi[23:06:33] <sguilhen> right[23:08:50] <Nihility> ok yeah[23:08:56] <Nihility> im thinking bug now[23:09:27] <Nihility> this call path doesnt use TCCL[23:10:16] <Nihility> i would see if you you can trace logging to modules[23:10:21] <Nihility> and if the problem still happens[23:10:25] <sguilhen> nope, the Stub class used it before but I changed it[23:10:34] <sguilhen> yea, I was about to do that[23:10:43] <Nihility> yeah and even if Stub did[23:10:48] <Nihility> it didnt even get that far[23:10:55] <Nihility> it linked the wrong Stub[23:11:14] <Nihility> hmm[23:11:19] <Nihility> one other crazy idea[23:11:26] <Nihility> let me look at something[23:17:30] *** torben has joined #jboss-as7[23:17:31] *** torben has quit IRC[23:17:31] *** torben has joined #jboss-as7[23:17:31] *** ChanServ sets mode: +v torben[23:17:31] <dmlloyd> remember it's only happening sometimes[23:17:44] <Nihility> yeah i was wondering[23:17:55] <Nihility> if we bundled those classes somewhere else[23:18:00] <Nihility> like in the transaction subsystem[23:18:13] <Nihility> and we had some kind of inconsistent linking or something[23:18:19] *** bstansberry has joined #jboss-as7[23:18:19] *** ChanServ sets mode: +v bstansberry[23:18:22] <Nihility> but its nowhere else[23:19:42] <dmlloyd> if it is some kind of race, trace logging might make it go away[23:19:45] <dmlloyd> that's what I'm worried about[23:20:49] *** jpederse has quit IRC[23:21:12] <Nihility> well if that doesnt work[23:21:16] <Nihility> there is a simple fallback[23:21:55] <Nihility> we just add a conditional and log only when the class name is javax.rmi.CORBA.Stub[23:26:23] *** pmuir has quit IRC[23:26:53] <dmlloyd> byteman![23:26:55] <dmlloyd> :)[23:27:05] *** pmuir has joined #jboss-as7[23:27:05] *** ChanServ sets mode: +v pmuir[23:28:48] *** kcbabo has quit IRC[23:29:34] *** pmuir has quit IRC[23:35:50] *** liweinan has quit IRC[23:38:29] *** frainone has quit IRC[23:39:23] *** sannegrinovero has joined #jboss-as7[23:39:23] *** sannegrinovero has quit IRC[23:39:23] *** sannegrinovero has joined #jboss-as7[23:39:23] *** ChanServ sets mode: +v sannegrinovero[23:44:11] *** torben has quit IRC[23:45:28] <stuartdouglas> morning[23:45:36] <misty> :)[23:45:48] <jamezp> morning[23:47:54] *** pmuir has joined #jboss-as7[23:47:54] *** ChanServ sets mode: +v pmuir[23:49:21] *** kevinpollet has left #jboss-as7[23:50:32] *** pmuir has quit IRC[23:55:30] *** Nihility has quit IRC[23:57:22] *** pferraro has joined #jboss-as7[23:57:26] *** ChanServ sets mode: +v pferraro