May 11, 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 11, 2011 NOTICE: This channel is no longer actively logged.
[00:01:40] *** mmoyses has quit IRC[00:09:18] *** misty has left #jboss-as7[00:11:51] *** maxandersen is now known as max_sleeping[00:12:51] *** misty has joined #jboss-as7[00:12:57] *** pgier has quit IRC[00:24:36] *** irooskov has quit IRC[00:26:05] *** max_sleeping has quit IRC[00:27:33] *** clebert has quit IRC[00:34:57] *** mbg has quit IRC[00:36:07] *** clebert has joined #jboss-as7[00:36:07] *** ChanServ sets mode: +v clebert[00:36:43] *** clebert has quit IRC[00:37:28] *** balunasj has quit IRC[00:50:20] *** irooskov has joined #jboss-as7[00:50:42] *** irooskov has quit IRC[00:51:16] *** irooskov has joined #jboss-as7[00:51:35] *** miclorb_ has joined #jboss-as7[00:51:53] *** jwulf has quit IRC[00:52:15] *** AndyTaylor has quit IRC[00:52:33] *** jpearlin has joined #jboss-as7[00:52:54] *** sannegrinovero has joined #jboss-as7[00:52:54] *** sannegrinovero has joined #jboss-as7[00:52:54] *** ChanServ sets mode: +v sannegrinovero[00:57:16] *** miclorb_ has quit IRC[00:57:30] *** miclorb has joined #jboss-as7[01:13:00] *** aslak has quit IRC[01:14:00] <dmlloyd> stuartdouglas: yeah though it's on the back burner atm[01:18:18] <stuartdouglas> ok[01:18:52] <stuartdouglas> You know how I asked about using a Phase.java type setup for interceptor / configurator ordering a few days ago?[01:19:33] <stuartdouglas> I talked to Jaikiran about it last night, and he thought it was a good idea, because at the moment the ordering is pretty fragile, and it is hard to figure out exactly where a given interceptor is in the chain[01:24:21] <dmlloyd> well if we want an interceptor order why not just use DUP phase numbers directly?[01:24:46] <dmlloyd> I mean we can do it the other way but then we'll have to sort them[01:25:16] *** jwulf has joined #jboss-as7[01:26:24] <stuartdouglas> If we try and force the dup order to reflect the interceptor order we will probably end up with a heap of DUP's that only add a single interceptor[01:27:11] <dmlloyd> so we'd only sort once on deployment though?[01:27:17] <stuartdouglas> and sometimes DUP's have their own ordering considerations that are different to the interceptor order[01:27:31] <dmlloyd> I guess it'd be OK though I don't have the cycles to do the work[01:27:49] <dmlloyd> or as the perl guys used to say, I don't have a "round tuit"[01:27:56] <stuartdouglas> I can do it, it is not a big change[01:28:20] *** rmaucher has quit IRC[01:28:25] <stuartdouglas> here you go: http://suziedoscher.com/?page_id=126[01:29:03] <dmlloyd> yessss[01:30:18] <stuartdouglas> anyway, the interceptor ordering is not as high a priority as getting the remaining tests to pass[01:32:09] <dmlloyd> I'm all done with interceptors at this point so you can just coordinate it with jaikiran if you want to make the change[01:32:55] <stuartdouglas> ok[01:45:00] *** sannegrinovero has quit IRC[01:45:34] *** alexsmirnov has quit IRC[01:46:49] <jamezp> dmlloyd: I might have this done finally https://github.com/jamezp/jboss-modules/commit/d2f5667131c0a76e953ff06e59800a99b580608e[01:46:50] <jbossbot> git [jboss-modules] d2f5667.. James Perkins MODULES-85 Add classpath module loader and CLI processing.[01:46:52] <jbossbot> jira [MODULES-85] Add support for class path bootstrap [Open (Unresolved) Enhancement, Major, James Perkins] https://issues.jboss.org/browse/MODULES-85[01:57:59] *** kcbabo has joined #jboss-as7[01:57:59] *** ChanServ sets mode: +v kcbabo[02:10:32] *** opalka has quit IRC[02:13:48] *** jamezp is now known as jamezp_afk[02:15:18] <dmlloyd> checking it over now jamezp_afk[02:15:29] <jamezp_afk> Perfect, thanks![02:15:37] *** jamezp_afk is now known as jamezp[02:28:07] <dmlloyd> okay for Main a couple things[02:28:24] <jamezp> Sure thing.[02:28:35] <dmlloyd> first a minor thing: printstream has a "printf" method so you don't have to nest like this: https://github.com/jamezp/jboss-modules/commit/d2f5667131c0a76e953ff06e59800a99b580608e#L1R319[02:28:36] <jbossbot> git [jboss-modules] d2f5667.. James Perkins MODULES-85 Add classpath module loader and CLI processing.[02:28:37] <jbossbot> jira [MODULES-85] Add support for class path bootstrap [Open (Unresolved) Enhancement, Major, James Perkins] https://issues.jboss.org/browse/MODULES-85[02:29:10] <dmlloyd> second, the class path module's main-class should be set on the command line[02:29:20] <jamezp> Yes it does. No idea why I did it like that.[02:29:21] <dmlloyd> so it's just like running: java -cp whatever.jar org.foo.MyClass[02:29:39] <dmlloyd> so if -cp is specified, then the last arg is a class name[02:29:55] <dmlloyd> so I guess you'd change moduleIdentifierOrJarName to moduleIdentifierOrJarNameOrMainClassNameWhat[02:30:07] <dmlloyd> Whuuuut[02:30:10] <jamezp> Haha. Sure, that I can do.[02:30:16] <dmlloyd> maybe a more terse name will do :)[02:30:31] <jamezp> Right, I can figure something out there.[02:32:59] <jamezp> I've got to run for now, but if I don't get to that tonight, I will first thing in the morning.[02:34:21] *** jamezp is now known as jamezp_afk[02:38:57] *** asaldhan has left #jboss-as7[02:50:54] *** slaboure has quit IRC[03:01:10] *** jwulf has quit IRC[03:01:44] *** liweinan has joined #jboss-as7[03:09:46] *** bstansberry has joined #jboss-as7[03:09:47] *** ChanServ sets mode: +v bstansberry[03:23:19] <jbossbot> git [jboss-as] push master 6b1bbe2.. Marcus Moyses adding eviction listener to default cache impl[03:23:19] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/5f94da5...6b1bbe2[03:24:30] *** Nihility has joined #jboss-as7[03:24:30] *** Nihility has joined #jboss-as7[03:24:30] *** ChanServ sets mode: +v Nihility[03:43:39] *** jwulf has joined #jboss-as7[03:47:06] *** JimMa has joined #jboss-as7[03:53:47] *** jpearlin has quit IRC[03:55:47] *** fnasser_ has quit IRC[04:01:24] *** miclorb has quit IRC[04:06:16] <JimMa> bstansberry, ping[04:06:56] <bstansberry> JimMa: hi Jim[04:07:08] <JimMa> bstansberry, Do you have minutes ? Ask a quick question... :-)[04:07:25] <bstansberry> sure, go ahead[04:07:57] <JimMa> bstansberry, Do we have some apis or extensions that I can manipulate the ModelNode in DeploymentUnitProcessor ?[04:08:25] <jbossbot> git [jandex] push master c71eaa2.. Jason T. Greene JANDEX-2 & JANDEX-3[04:08:26] <jbossbot> jira [JANDEX-2] Allow the creation of Index [Open (Unresolved) Feature Request, Major, Jason Greene] https://issues.jboss.org/browse/JANDEX-2[04:08:27] <jbossbot> jira [JANDEX-3] sort first before binarySearch [Open (Unresolved) Enhancement, Major, Jason Greene] https://issues.jboss.org/browse/JANDEX-3[04:08:27] <jbossbot> git [jandex] push master d5961f2.. Jason T. Greene Release beta7[04:08:27] <jbossbot> git [jandex] push master URL: http://github.com/jbossas/jandex/compare/13ddd05...d5961f2[04:08:30] <dmlloyd> no, you can't change the management model from a service or deployer[04:08:54] <bstansberry> JimMa: what do you want to do?[04:08:56] <dmlloyd> right now it'll jam up the server, but soon(?) we'll have an error message and exception which is thrown[04:09:11] <JimMa> dmlloyd, I want to add some ws endpoints child node to ws subsystem.[04:09:23] <JimMa> dmlloyd, bstansberry I want to add some ws endpoints child node to ws subsystem.[04:09:42] <bstansberry> are these really associated with the deployment?[04:09:47] <JimMa> dmlloyd, bstansberry then we can use common read resource operation to read all the endpoints information .[04:10:13] <dmlloyd> it should not be necessary to modify the management model in order to be able to do that[04:10:16] <JimMa> dmlloyd, bstansberry currently the ws endpoints are deployed in a war or ejb jar file .[04:10:35] <bstansberry> emuckenhuber is working on how to expose deployment related stuff via the management api as child resources under a deployment[04:10:51] <bstansberry> but dmlloyd is right; you don't need to add model nodes to do that[04:11:28] <jbossbot> git [jandex] push 1.0.0.Beta7 URL: http://github.com/jbossas/jandex/compare/0000000...d5961f2[04:11:45] <JimMa> dmlloyd, bstansberry ok. Then after emuckenhuber's work , we can use common operation to get that information from the deployments ?[04:12:04] <jbossbot> git [jandex] push master 1b51f61.. Jason T. Greene Next is Beta8[04:12:04] <jbossbot> git [jandex] push master URL: http://github.com/jbossas/jandex/compare/d5961f2...1b51f61[04:12:37] <bstansberry> a subsystem can have child resources that expose state that is only part of the runtime state, isn't part of the persistent model[04:13:14] <JimMa> bstansberry, I see. Is this jira issue that emuckenhuber is working : https://issues.jboss.org/browse/AS7-367 ?[04:13:15] <jbossbot> jira [AS7-367] Expose deployment details via the domain management API [Open (Unresolved) Feature Request, Critical, Unassigned] https://issues.jboss.org/browse/AS7-367[04:13:47] <Nihility> actually on that topic[04:13:51] <bstansberry> JimMa: yes. but the ws subsystem would need to add operation handlers that can expose the runtime state[04:14:11] <Nihility> long ago we talked about having some easy way for deployments to add their own management operations (runtime)[04:14:38] <Nihility> i.e. a replacement for people using @Management[04:15:18] <jbossbot> git [jboss-as] push master 3d1f2ad.. Jason T. Greene Go to jandex Beta7[04:15:18] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/6b1bbe2...3d1f2ad[04:16:45] <Nihility> bstansberry: so we should make sure we leave space under the deployment for the user[04:17:00] <JimMa> Nihility, ok.[04:17:26] <Nihility> JimMa: but this doesnt help you, as in this case, you want to provide subsystem runtime ops[04:19:59] <JimMa> Nihility, can you explain that for me ? why this does not help. ;-)[04:20:32] <jbossbot> git [jboss-as] push master c793bbf.. bstansberry at jboss dot com Store all history files in _history dirs; use 'boot' instead of 'original'[04:20:32] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/3d1f2ad...c793bbf[04:20:54] <Nihility> JimMa: well in this case what I think you want is just to add some management operations to the WS subsystem[04:21:09] <JimMa> Nihility, yes.[04:21:39] <JimMa> Nihility, I still need to add other things ?[04:22:49] <JimMa> Nihility, for example do some work in the deployment process, or something else ?[04:26:04] <JimMa> bstansberry, to summarize , after https://issues.jboss.org/browse/AS7-367 is resolved, I just need add some operation then user can use read-resource to list the deployed endpoints ?[04:26:05] <jbossbot> jira [AS7-367] Expose deployment details via the domain management API [Open (Unresolved) Feature Request, Critical, Unassigned] https://issues.jboss.org/browse/AS7-367[04:28:19] *** frainone has quit IRC[04:32:46] <bstansberry> JimMa: emuckenhuber is still working out the details, but the way we were talking today is a deployment unit processor would register a child resource (and operation handlers) under the resource that represents a deployment[04:33:22] <Nihility> JimMa: in the meantime though you can add as many operations as you want to the ws subsystem[04:33:35] <Nihility> JimMa: so you could for example have an op that is "listEndpoints"[04:36:47] <JimMa> Nihility, I wrote one operation to list the ws endpoint from our internal WSendpointRegistry. Heiko(RHQ team) expect us to add ws endpoints child node to ws subsystem like connector resources added to web subsystem, then he can use general operation to read all subsystem information.[04:37:47] <smarlow> Nihility: If we were to fork BoundedConcurrentHashMap into AS7 and create an additional Hibernate (local only) 2nd level cache based on that, would you prefer that over Infinispan for the AS7 default 2lc? I would prefer to stick with Infinispan for the default AS7 2lc but could see starting a github repo for creating a RegionFactory based 2lc. What do you think?[04:38:27] <Nihility> smarlow: i just dont want infinispan in our default config until the perf cost is reasonable[04:38:44] <JimMa> bstansberry, It's clear now. Thanks for the clarification.[04:38:52] <Nihility> smarlow: so if we dont use 2lc by default, which sounds like what we want[04:39:00] <Nihility> smarlow: then it doesnt matter[04:40:04] <smarlow> Nihility: we were just trying to lower the barrier to get going with a 2lc and make sure stuff works.[04:40:40] <Nihility> basically i dont want > 3 sec startup[04:40:47] <JimMa> bstansberry, btw, pleas ignore my email. I wrote you to ask the same question. ;-)[04:40:54] <stuartdouglas> where is jboss-stdio located? I just found a bug in WriterOutputStream[04:41:08] <bstansberry> JimMa: oh,right. sorry :([04:41:10] <dmlloyd> what? a bug? nonsense![04:41:15] <dmlloyd> http://github.com/dmlloyd/jboss-stdio I think stuartdouglas[04:41:33] <bstansberry> I thought this sounded familiar. I was at the conf last week and got behind on mail[04:41:34] <stuartdouglas> cool, pull request coming shortly[04:42:06] <JimMa> bstansberry, ;-)[04:43:08] <smarlow> Nihility: my startup was 2.5s with infinispan as the default 2lc configured but I wasn't deploying an app that uses the 2lc. If I did a cold boot, I did consistently see around a ten second AS boot.[04:43:24] <stuartdouglas> dmlloyd: It does not seem to be there[04:44:04] <smarlow> Nihility: it sounds like no 2lc is more likely to not regress in the future[04:44:36] <Nihility> ah right since the subsystem is used lazily[04:44:47] <Nihility> i guess thats fine too[04:46:55] <dmlloyd> hmmm[04:46:59] <dmlloyd> where *did* I put that thing[04:47:12] <stuartdouglas> svn?[04:50:37] <Nihility> dmlloyd: did you check your commodor datasette 1530?[04:51:59] <dmlloyd> https://github.com/dmlloyd/jboss-stdio in about 15 minutes[04:52:28] <stuartdouglas> ok[04:53:10] <stuartdouglas> It's a pretty hard bug to trigger, you need to write exactly 256 bytes using write(final byte[] b, int off, int len), and then write a byte using write(final int b)[04:55:10] <dmlloyd> stuartdouglas: done[04:55:21] <dmlloyd> guess it has a pretty brief history :)[04:58:00] <Nihility> haha that bug is pretty obvious looking at the code[05:00:12] <dmlloyd> go ahead and laugh[05:00:17] <dmlloyd> you just wait[05:00:30] <Nihility> i do shit like that all the time[05:00:39] <Nihility> so im laughing with you[05:01:03] <stuartdouglas> https://github.com/stuartwdouglas/jboss-stdio[05:01:23] <stuartdouglas> damn't, there was another problem with the test as well[05:01:32] <stuartdouglas> that was supposed to fix it[05:01:33] <Nihility> that doesnt fix it completely[05:01:43] <Nihility> you need to fix the single byte method[05:01:54] <Nihility> dont let it write to a full buffer![05:02:18] <stuartdouglas> looking at the code though it looks like after you write the buffer should always be flushed if it is full[05:02:46] <stuartdouglas> so at the entry to the write method the buffer should never be full[05:04:09] *** magesh has joined #jboss-as7[05:04:33] <stuartdouglas> the two write methods are the only ones that write to the buffer, and now they should both flush it if they fill it up[05:05:04] <dmlloyd> tests??? that's crazy talk[05:05:29] <stuartdouglas> It's unlikely a test would have picked this up anyway[05:09:29] <Nihility> stuartdouglas: your change doesnt do anything[05:10:04] <stuartdouglas> yes it does[05:10:26] <stuartdouglas> if the write method exactly filled the buffer it was not being flushed[05:10:39] <stuartdouglas> now if write fills the buffer it is flushed[05:11:26] <stuartdouglas> which means that the buffer will never be full when write() is called[05:11:46] <stuartdouglas> if you want I can just change it so that the write method checks if the buffer is full[05:12:45] <Nihility> rem != cnt happens when len > rem, in which case len -= cnt = 0[05:13:04] <stuartdouglas> len == rem is the problem[05:13:33] <Nihility> final int cnt = rem <= len ? rem : len;[05:13:35] <stuartdouglas> len > rem results in a flush, and then the loop iterates again and writes the rest[05:13:37] <Nihility> its <=[05:14:02] <stuartdouglas> yes, and it's the case when they are equal that you have problems[05:14:44] *** smarlow has quit IRC[05:19:15] <stuartdouglas> I've changed it anyway[05:19:43] <stuartdouglas> it is easier to understand this way, and this way it does not run the loop again and write 0 bytes[05:22:54] *** Nihility has quit IRC[05:28:37] <dmlloyd> ready?[05:31:07] <stuartdouglas> yep[05:32:28] <stuartdouglas> actually now it is ready[05:33:09] <dmlloyd> erk[05:33:10] <dmlloyd> ok[05:33:24] <stuartdouglas> just out of curiosity why do you do final ByteBuffer inputBuffer = this.inputBuffer; rather than just using this.inputBuffer directly? I know why you would do that for volatile fields[05:33:35] <stuartdouglas> but does it make any difference for final ones?[05:33:45] <dmlloyd> yes[05:33:49] <dmlloyd> it shouldn't but it does[05:34:07] <dmlloyd> discovered that when working on JBMAR, and just got into the habit after that[05:34:33] <dmlloyd> probably doesn't really matter except in the most dire perf circumstances[05:38:22] <stuartdouglas> how big a difference does it make? Thinking about it there would always be slightly more work for a getfield as opposed to an aload, but I did not think it would be noticable[05:44:34] <dmlloyd> it made a big diff in JBMAR[05:44:38] <dmlloyd> well "big"[05:44:41] <dmlloyd> percentage-wise[05:45:05] <dmlloyd> but that's slicing a fine hair[05:51:38] <stuartdouglas> down to 7 failures in the ejb branch test suite, 4 from duplicate bindings, one from no concurrency interceptor, and the other 2 I am not sure about[06:08:46] *** magesh has quit IRC[06:10:24] *** magesh1 has joined #jboss-as7[06:14:01] *** kcbabo has quit IRC[06:48:11] *** irooskov has quit IRC[06:57:42] *** Nihility has joined #jboss-as7[06:57:43] *** Nihility has joined #jboss-as7[06:57:43] *** ChanServ sets mode: +v Nihility[07:08:38] *** bstansberry has quit IRC[07:13:25] *** Nihility has quit IRC[07:50:11] *** aslak has joined #jboss-as7[07:50:11] *** aslak has quit IRC[07:50:11] *** aslak has joined #jboss-as7[07:50:11] *** ChanServ sets mode: +v aslak[07:51:02] *** alesj has joined #jboss-as7[08:03:55] *** jfclere has joined #jboss-as7[08:04:05] *** Jaikiran has joined #jboss-as7[08:04:06] *** ChanServ sets mode: +v Jaikiran[08:05:02] <Jaikiran> stuartdouglas: good morning[08:05:09] <stuartdouglas> Jaikiran: morning[08:05:17] <Jaikiran> just picked up your latest commits[08:05:29] <Jaikiran> i'll redo the application exception part of the EJB today[08:05:39] <stuartdouglas> cool, I'm just working on some weld TCK issues at the moment[08:05:43] <Jaikiran> ok[08:05:57] <stuartdouglas> ok, the other thing that is missing is the concurrency interceptor[08:05:57] <Jaikiran> i think, the current impl (other than the ordering part) is kind of stable now[08:06:07] <Jaikiran> yeah for singleton and sfsb[08:06:12] *** misty has quit IRC[08:07:33] <stuartdouglas> I only have 7 tests failing now, 4 are duplicate bindings stuff, 1 is to do with the ejb entry point from web services, 1 is the missing concurrency interceptor and I have not debugged the other[08:08:22] <Jaikiran> ok, the webservices thing needs some thinking in terms of what needs to be changed in the ws module. so i'll keep it last[08:08:51] <Jaikiran> do you remember which testcase showed you this issue https://github.com/stuartwdouglas/jboss-as/commit/39abed9abc7b940037b6cd9fbef3eae127c3dbad[08:08:52] <jbossbot> git [jboss-as] 39abed9.. Stuart Douglas Fix NPE when exception is thrown from EJB[08:08:53] <Jaikiran> ?[08:09:29] <stuartdouglas> the exception was caused by a NPE, because CDI injection was not working correctly[08:09:36] <stuartdouglas> so now the NPE is fixed[08:09:58] <stuartdouglas> I think it was the test for CDI injection into interceptors[08:10:14] *** jfclere has quit IRC[08:10:21] <Jaikiran> ok[08:10:28] <Jaikiran> btw, have you seen this one before http://pastebin.com/VNzmZVN4[08:10:49] <Jaikiran> i just updated my workspace with your branch and it's failing in arquillian-container-managed module with this excepiton[08:10:53] <stuartdouglas> yes, thats a new one I just created[08:11:02] <stuartdouglas> I have a fix locally[08:11:09] <stuartdouglas> one sec[08:11:12] <Jaikiran> sure[08:11:24] *** magesh has joined #jboss-as7[08:11:40] <stuartdouglas> done[08:11:53] *** magesh1 has quit IRC[08:11:59] <Jaikiran> thanks![08:11:59] <stuartdouglas> weld is a bit of a PITA because it does not work at all if you have the wrong TCCL set[08:12:25] <stuartdouglas> so there are heaps of places where I have to explicitly set the TCCL before invoking weld[08:12:38] <Jaikiran> i see[08:14:18] *** miclorb_ has joined #jboss-as7[08:15:59] *** rawbdor has quit IRC[08:20:19] *** jwulf has quit IRC[08:25:29] *** tdiesler has joined #jboss-as7[08:25:29] *** ChanServ sets mode: +v tdiesler[08:30:48] *** irooskov has joined #jboss-as7[08:33:02] *** jfclere has joined #jboss-as7[08:33:02] *** ChanServ sets mode: +v jfclere[08:36:01] *** galderz has joined #jboss-as7[08:36:01] *** ChanServ sets mode: +v galderz[08:36:50] *** rmaucher has joined #jboss-as7[08:39:08] *** opalka has joined #jboss-as7[08:39:08] *** ChanServ sets mode: +v opalka[08:39:26] <opalka> morning[08:43:16] *** maxandersen has joined #jboss-as7[08:43:16] *** ChanServ sets mode: +v maxandersen[08:44:35] <alesj> stuartdouglas: Caused by: java.lang.NullPointerException[08:44:35] <alesj> at org.jboss.as.ee.component.EnvEntryProcessor.getResourceRefEntries(EnvEntryProcessor.java:122)[08:44:50] <alesj> NPE == bug[08:46:37] *** pilhuhn has joined #jboss-as7[08:46:38] *** pilhuhn has joined #jboss-as7[08:46:38] *** ChanServ sets mode: +v pilhuhn[08:47:23] <Jaikiran> alesj: upstream?[08:47:51] *** wolfc has joined #jboss-as7[08:47:51] *** ChanServ sets mode: +v wolfc[08:48:38] <alesj> Jaikiran: last night[08:48:53] <alesj> but let me rebase it, and try again[08:48:59] <Jaikiran> ok[08:49:58] *** Binbin has joined #jboss-as7[08:52:31] *** miclorb_ has quit IRC[08:53:04] *** aslak has quit IRC[08:53:24] *** aslak has joined #jboss-as7[08:53:24] *** ChanServ sets mode: +v aslak[08:55:24] <alesj> Jaikiran, stuartdouglas: Caused by: java.lang.NullPointerException[08:55:25] <alesj> at org.jboss.as.ee.component.EnvEntryProcessor.getResourceRefEntries(EnvEntryProcessor.java:122)[08:55:30] <alesj> still the same NPE[08:56:02] <Jaikiran> alesj: can you create a jira and assign it to me? if there's an easy to reproduce app, please add it[08:56:05] <Jaikiran> i'll take look[08:57:05] <stuartdouglas> alesj: Is this in the new ejb branch or in master?[08:58:18] <Jaikiran> master[08:59:04] <alesj> the issue is my res-ref doesn't have any res-type or injection-targets[08:59:10] <alesj> is this valid?[08:59:14] <Jaikiran> it's valid[08:59:21] <stuartdouglas> are you sure?[08:59:36] <stuartdouglas> I thought it needed one of the other to figure the type to bind to jndi[08:59:37] <Jaikiran> oh wait! both injection-target and type are missing?[08:59:50] <stuartdouglas> still should not npe though[08:59:53] <Jaikiran> yeah, either the injection-target or type is required to infer the type[09:00:00] <Jaikiran> it should a sane error message though[09:00:07] <Jaikiran> *should throw[09:01:07] <alesj> ok, let me add the type[09:01:10] <alesj> and check again[09:01:26] <alesj> but, like stuartdouglas said, it shouln't throw NPE[09:01:44] <Jaikiran> agreed[09:03:13] <alesj> yup, it works now[09:05:00] <alesj> stuartdouglas: but again, for some strange reason, the Weld interceptors are not applied ...[09:05:30] <alesj> with this iceptors, i don't even know anymore which issue i'm hitting … :-([09:06:34] <stuartdouglas> so was that interceptors test you showed me the other day with AS7?[09:07:06] <alesj> yes[09:07:17] <alesj> there are 3 dif issues[09:07:35] <alesj> 1st — didn't check all super classes[09:08:10] <alesj> 2nd — checked the wrong method[09:08:11] *** mgoldmann has joined #jboss-as7[09:08:11] *** ChanServ sets mode: +v mgoldmann[09:08:19] *** rawbdor has joined #jboss-as7[09:08:29] <alesj> 3rd — didn't find the iceptor due to deployment ordering, hence not applied[09:08:39] <stuartdouglas> didn't some of these miss the 1.1 release?[09:08:44] <stuartdouglas> 1.1.1[09:08:49] <alesj> all of them :-([09:09:03] <alesj> hence i'm using my own snapshot[09:09:10] <alesj> with AS7 build[09:09:12] <stuartdouglas> It's amazing that none of them have been reported before now[09:09:18] <alesj> eactly[09:09:20] <alesj> x[09:09:44] <alesj> well, 1., 2. can easily be explained why[09:10:04] *** lgao has joined #jboss-as7[09:10:06] <alesj> no deep hierarchy + no generics usage in the hierarchy[09:10:08] *** asoldano has joined #jboss-as7[09:10:08] *** ChanServ sets mode: +v asoldano[09:10:30] <alesj> 3. ~ single bean archive[09:10:34] <stuartdouglas> and as AS6 merged bda's into one super bda, 3 is explainable ot[09:10:36] <stuartdouglas> to[09:10:44] <alesj> yes[09:10:55] <alesj> specially for .war[09:10:56] <stuartdouglas> when we do TCK 1.1 we need heaps of bean visibility tests[09:11:10] <alesj> and .ear is broken for AS6[09:11:17] <alesj> hence people moved to .war[09:11:31] <alesj> probably most of the .ear issues are exactly 3.[09:11:39] <alesj> as then you get more then one bda[09:12:26] <alesj> and the exception i'm getting now, looks like i'm hitting what i tried to explain it to you the other day[09:12:51] <stuartdouglas> the one that you could not reproduce?[09:12:54] <alesj> which was what that friend was seeing[09:12:55] <alesj> yes[09:13:00] <alesj> he was able to, but not me[09:13:40] <alesj> i'll re-check if i have all of the patches in that current snapshot[09:13:59] <alesj> if not, it might explain why it doesn't work[09:14:10] <alesj> if yes, then we're off for another wild chase ...[09:16:52] *** Jaikiran has quit IRC[09:19:36] *** miclorb has joined #jboss-as7[09:23:02] *** bgeorges has joined #jboss-as7[09:23:02] *** ChanServ sets mode: +v bgeorges[09:27:19] *** galderz has quit IRC[09:27:40] *** galderz has joined #jboss-as7[09:27:42] *** galderz has quit IRC[09:27:43] *** galderz has joined #jboss-as7[09:27:43] *** ChanServ sets mode: +v galderz[09:32:17] *** stliu has joined #jboss-as7[09:32:17] *** ChanServ sets mode: +v stliu[09:36:29] *** irooskov has quit IRC[09:40:16] *** adietisheim has joined #jboss-as7[09:40:16] *** ChanServ sets mode: +v adietisheim[09:48:28] *** miclorb has quit IRC[09:49:51] *** maxandersen has quit IRC[09:54:53] *** tdiesler has quit IRC[09:57:54] *** hardy has joined #jboss-as7[10:00:47] *** emuckenhuber has joined #jboss-as7[10:00:47] *** emuckenhuber has joined #jboss-as7[10:00:47] *** ChanServ sets mode: +v emuckenhuber[10:07:49] *** pmuir has joined #jboss-as7[10:08:54] *** pmuir has quit IRC[10:08:54] *** pmuir has joined #jboss-as7[10:11:08] *** emuckenhuber has quit IRC[10:23:50] *** emuckenhuber has joined #jboss-as7[10:23:51] *** emuckenhuber has joined #jboss-as7[10:23:51] *** ChanServ sets mode: +v emuckenhuber[10:29:18] *** rawbdor has quit IRC[10:39:22] *** hbraun has joined #jboss-as7[10:43:40] *** zroubali has joined #jboss-as7[10:43:40] *** ChanServ sets mode: +v zroubali[11:00:57] *** maxandersen has joined #jboss-as7[11:00:57] *** ChanServ sets mode: +v maxandersen[11:09:24] *** asoldano is now known as asoldano_afk[11:17:23] *** asoldano_afk is now known as asoldano[11:26:04] *** mgoldmann has quit IRC[11:45:52] *** bgeorges has quit IRC[11:46:34] *** rawbdor has joined #jboss-as7[11:51:55] *** jcosta has joined #jboss-as7[11:51:55] *** ChanServ sets mode: +v jcosta[11:56:54] *** rawbdor has quit IRC[12:07:52] *** alesj has quit IRC[12:13:06] *** darranl has joined #jboss-as7[12:13:07] *** ChanServ sets mode: +v darranl[12:13:19] *** Jaikiran has joined #jboss-as7[12:13:19] *** ChanServ sets mode: +v Jaikiran[12:18:38] *** alesj has joined #jboss-as7[12:31:00] *** kcbabo has joined #jboss-as7[12:31:00] *** ChanServ sets mode: +v kcbabo[12:37:38] *** slaboure has joined #jboss-as7[12:39:49] *** slaboure has quit IRC[12:40:06] *** slaboure has joined #jboss-as7[12:40:24] *** asoldano is now known as asoldano_lunch[12:45:52] *** stliu has quit IRC[12:48:40] *** AndyTaylor has joined #jboss-as7[12:48:40] *** ChanServ sets mode: +v AndyTaylor[12:49:05] <wolfc> stuartdouglas: ping[12:50:10] *** sgilda has joined #jboss-as7[12:51:31] <wolfc> stuartdouglas: lazily instantiating the SFSB instance can lead to EJBTHREE-666[12:51:32] <jbossbot> jira [EJBTHREE-666] Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance [Closed (Done) Bug, Critical, Carlo de Wolf] https://issues.jboss.org/browse/EJBTHREE-666[12:52:09] *** alesj has quit IRC[12:52:19] <wolfc> https://github.com/stuartwdouglas/jboss-as/commit/052214674c392c59c40f4892a20c5a1a8f9c5c13#L0R74[12:52:21] <jbossbot> git [jboss-as] 0522146.. Stuart Douglas Initial half-baked SessionObjectReference implementation[12:52:46] *** alesj has joined #jboss-as7[12:56:08] *** sannegrinovero has joined #jboss-as7[12:56:08] *** sannegrinovero has quit IRC[12:56:08] *** sannegrinovero has joined #jboss-as7[12:56:08] *** ChanServ sets mode: +v sannegrinovero[13:13:02] *** JimMa has quit IRC[13:14:42] *** pmuir has quit IRC[13:20:54] *** pmuir has joined #jboss-as7[13:20:54] *** pmuir has quit IRC[13:20:54] *** pmuir has joined #jboss-as7[13:20:54] *** ChanServ sets mode: +v pmuir[13:33:52] *** balunasj has joined #jboss-as7[13:33:52] *** balunasj has joined #jboss-as7[13:33:52] *** ChanServ sets mode: +v balunasj[13:39:03] *** bstansberry has joined #jboss-as7[13:39:03] *** ChanServ sets mode: +v bstansberry[13:39:19] *** bstansberry has quit IRC[13:40:54] *** tdiesler has joined #jboss-as7[13:40:55] *** ChanServ sets mode: +v tdiesler[13:45:36] *** zroubali has quit IRC[13:51:39] *** kkhan has joined #jboss-as7[13:51:39] *** ChanServ sets mode: +v kkhan[13:55:48] *** galderz has quit IRC[13:57:28] *** asoldano_lunch is now known as asoldano[14:07:04] *** zroubali has joined #jboss-as7[14:07:19] *** zroubali has quit IRC[14:08:29] *** bgeorges has joined #jboss-as7[14:09:23] *** smarlow has joined #jboss-as7[14:09:23] *** ChanServ sets mode: +v smarlow[14:12:40] *** magesh has quit IRC[14:13:09] *** magesh has joined #jboss-as7[14:13:33] <wolfc> baileyje: are you awake?[14:14:38] <wolfc> baileyje: my comments on AS7-223 are incomplete, but I do not want to start a full discussion there. An @EJB setting up a dependency on a specific EJB view might be wrong altogether. But that impacts the whole EJB services construct.[14:14:40] <jbossbot> jira [AS7-223] Setting beanName to an EJB that does not expose the interface leads to hang [Open (Unresolved) Bug, Critical, John Bailey] https://issues.jboss.org/browse/AS7-223[14:14:52] <wolfc> Jaikiran: FYI ^[14:17:13] *** balunasj has quit IRC[14:22:32] *** hbraun has left #jboss-as7[14:24:09] *** maeste has joined #jboss-as7[14:24:09] *** ChanServ sets mode: +v maeste[14:24:46] *** maeste2 has joined #jboss-as7[14:24:46] *** ChanServ sets mode: +v maeste2[14:24:50] *** maeste2 has quit IRC[14:26:05] *** davidbos has joined #jboss-as7[14:28:23] *** smarlow has quit IRC[14:29:56] *** jpederse has joined #jboss-as7[14:30:07] <stuartdouglas> wolfc: The SessionObjectReference stuff is still a complete hack[14:30:35] <wolfc> stuartdouglas: ah okay, just making sure you're aware[14:31:15] <stuartdouglas> I am actually not sure about the best way to implement it, I think it will require some changes to the view stuff[14:32:15] <jbossbot> git [jboss-as] push master 36be9ee.. asoldano [AS7-745] Upgrade to jbossws 4.0.0.Beta1[14:32:16] <jbossbot> jira [AS7-745] Upgrade to JBossWS-CXF 4.0.0.Beta1 [Open (Unresolved) Component Upgrade, Major, Alessio Soldano] https://issues.jboss.org/browse/AS7-745[14:32:16] <jbossbot> git [jboss-as] push master a58c47a.. Stefano Maestri AS7-719 AS-724 fixing some deployment bugs for XA datasources[14:32:25] <jbossbot> jira [AS7-719] En/Disable datasource returns error although state change is applied [Open (Unresolved) Bug, Critical, Stefano Maestri] https://issues.jboss.org/browse/AS7-719[14:32:25] <jbossbot> git [jboss-as] push master d823919.. Scott Marlow remove comment + unused imports[14:32:26] <jbossbot> git [jboss-as] push master 7098c97.. Scott Marlow persistence unit/context references in the deployment descriptor should cause the deployment unit to be marked as JPA deployment[14:32:26] <jbossbot> git [jboss-as] push master afe17a4.. Scott Marlow JBCTS-1109 adjust datasource name if needed[14:32:26] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c793bbf...afe17a4[14:33:59] *** torben has joined #jboss-as7[14:33:59] *** torben has quit IRC[14:33:59] *** torben has joined #jboss-as7[14:33:59] *** ChanServ sets mode: +v torben[14:34:12] *** hbraun has joined #jboss-as7[14:34:32] *** smarlow has joined #jboss-as7[14:34:32] *** ChanServ sets mode: +v smarlow[14:37:43] *** mmoyses has joined #jboss-as7[14:37:43] *** ChanServ sets mode: +v mmoyses[14:42:09] <jpederse> smarlow: Happy birthday ![14:42:21] *** Nihility has joined #jboss-as7[14:42:21] *** Nihility has joined #jboss-as7[14:42:21] *** ChanServ sets mode: +v Nihility[14:42:36] <smarlow> thanks jpederse! :)[14:45:52] <kkhan> Happy birthday :-)[14:46:58] <smarlow> kkhan: thanks! and thanks for the merge too! :-)[14:48:56] <dmlloyd> jamezp_afk: ping me when you're up[14:52:15] *** fnasser has joined #jboss-as7[14:55:17] *** clebert has joined #jboss-as7[14:55:17] *** ChanServ sets mode: +v clebert[14:57:28] <Jaikiran> dmlloyd: when you have some time please take a look at this branch[14:57:41] <Jaikiran> it's the latest from both stuartdouglas' and my commits[14:57:52] <Jaikiran> https://github.com/jaikiran/jboss-as/commits/new-ee-framework[14:59:40] *** lgao has left #jboss-as7[15:03:02] <dmlloyd> I don't understand why we need a separate instantiation interceptor chain[15:03:10] <dmlloyd> and why we need to tag the post-construct chain on the component instance[15:03:18] <dmlloyd> it shouldn't be necessary[15:03:28] <dmlloyd> we don't need two code paths[15:03:40] <Jaikiran> regarding the instantiation interceptor chain[15:04:08] *** Nihility has quit IRC[15:04:19] <Jaikiran> there are certain interceptors which run during the (previously) postconstruct chain of a component instance[15:04:37] <Jaikiran> and those interceptors require a ComponentInstance instance[15:05:25] <Jaikiran> and since previously, the postconstruct chain was triggered from within the constructor of the (Basic)ComponentInstance attaching the (not yet initialized) ComponentInstance instance wasn't feasible[15:06:04] <Jaikiran> to be more precise[15:06:09] <Jaikiran> consider this example:[15:06:47] *** mmoyses is now known as mmoyses_[15:06:56] <Jaikiran> http://pastebin.com/eaAmKYuG[15:07:38] <Jaikiran> for this one, we end up creating a ManagedFieldInjectingInterceptor (or something like that) which runs in the postconstruct invocation chain of the ComponentInstance[15:08:15] <Jaikiran> to successfully, inject the EJBContext, the injection source needs access to the current ComponentInstance to return the correct EJBContext[15:10:45] <dmlloyd> okay well it seems to me that all we need to do is move the constructor logic out of BasicComponentInstance[15:10:49] <dmlloyd> then we don't have the final field problem[15:11:09] <dmlloyd> we don't want the component instance keeping a reference to the post construct interceptor chain[15:11:11] <dmlloyd> because it will never use it[15:11:23] *** pilhuhn is now known as cassandra_[15:11:41] *** cassandra_ is now known as pilhuhn[15:14:23] *** bstansberry has joined #jboss-as7[15:14:23] *** ChanServ sets mode: +v bstansberry[15:14:44] <Jaikiran> dmlloyd: tried that, but didn't look straightforward[15:15:00] <bstansberry> jpederse: good morning[15:15:01] <Jaikiran> because the preDestroy and postConstruct should share the same interceptor factory context[15:15:07] <jpederse> bstansberry: Hey[15:15:16] <jpederse> maeste: you have time now ?[15:15:18] <Jaikiran> unless ofcourse we plan to create the preDestroy outside of the constructor too[15:15:24] <dmlloyd> Jaikiran: yeah that's what I'm thinking[15:16:02] <Jaikiran> ok, that should be possible then - moving that logic out of the construct and making some of those fields non-final[15:16:14] <wolfc> hbraun: ping[15:16:28] <hbraun> wolfc: carlo, what's up?[15:16:42] <jpederse> bstansberry: we have to wait for maeste to be here[15:17:10] <jpederse> bstansberry: but I give a quick intro to put in your noodle[15:17:29] <jpederse> bstansberry: resource adapters can have dynamic statistics in IronJacamar[15:17:31] *** pgier has joined #jboss-as7[15:17:39] <jpederse> bstansberry: because each resource adapter is different[15:17:41] *** ChanServ sets mode: +v pgier[15:18:00] <jpederse> bstansberry: so in order to describe these stats we need an actual deployment[15:18:19] <jpederse> bstansberry: which means we can't up-front provide a list[15:19:02] <bstansberry> interesting[15:19:04] <jpederse> bstansberry: maeste hasn't found a way to describe the resources and operations at a later point[15:19:26] <Jaikiran> dmlloyd: i'll change that part now. anything else that doesn't look right?[15:19:30] <jpederse> bstansberry: which means that he has hardcoded this s... currently[15:19:46] <jpederse> bstansberry: I want that out, since the first thing people will do is to deploy MQ[15:20:24] <jpederse> bstansberry: the correct way is to use our SPI, which will provide all the information[15:20:28] <bstansberry> k; so these resources would be children of /substem=ra/ra=somera?[15:20:33] <jpederse> bstansberry: both of the run time JCA container[15:20:33] <dmlloyd> just the fact that we've got two create interceptor chains[15:20:42] <dmlloyd> if we can flatten those down I'd feel better[15:20:43] <jpederse> bstansberry: but also vendor specific extensions[15:21:01] <jpederse> bstansberry: yeah[15:21:10] <Jaikiran> which 2 create chains?[15:21:17] <jpederse> bstansberry: but lets wait until maeste gets back[15:21:19] <dmlloyd> the instantiate vs. create[15:21:20] <maeste> jpederse: I'm here[15:21:31] *** Nihility has joined #jboss-as7[15:21:32] *** Nihility has joined #jboss-as7[15:21:32] *** ChanServ sets mode: +v Nihility[15:21:34] <Jaikiran> oh yeah, that's the one i'll be undoing now[15:21:40] <jpederse> maeste: ok, a quick intro ^ - feel free to expand[15:22:16] <maeste> jpederse, bstansberry : well I'm here for few mins, and I'll get back at 4.30PM my time[15:22:32] <maeste> bstansberry: but jpederse has said almost everything[15:22:34] <jpederse> bstansberry: this is the SPI that we - but also the vendors - implement http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jboss-jca/trunk/core/src/main/java/org/jboss/jca/core/spi/statistics/StatisticsPlugin.java?revision=111241&view=markup[15:22:50] <maeste> bstansberry: from an AS7 point f view my problem is that[15:23:24] <maeste> bstansberry: operation registration and resource-description providers ar eregistered before I've made a rela deployment of DS or RA[15:24:00] <maeste> bstansberry: so I can't get from the instance the attribute users can read as metrics getting them runtime from the instance of DS[15:24:00] <dmlloyd> excellent[15:24:21] <bstansberry> maeste: right, I see the issue[15:24:29] *** asaldhan has joined #jboss-as7[15:24:29] *** ChanServ sets mode: +v asaldhan[15:24:31] <jpederse> bstansberry: plus we will expand stats in future releases of IJ - that shouldn't require changes to AS 7 in order for them to be activated[15:24:44] <maeste> bstansberry: my question is if there is a way to do that or if I well understood the API of the model[15:25:08] <maeste> bstansberry: and so if there is a way[15:25:09] <bstansberry> emuckenhuber is working on adding hooks to allow registration of resources, handlers as part of deployment[15:25:18] <maeste> bstansberry: cool[15:25:19] <bstansberry> but that's not really what you want[15:25:38] <bstansberry> they would be child resources of /deployment=x.rar[15:25:39] <maeste> bstansberry: well perhaps could be enough[15:25:53] <maeste> bstansberry: for rar[15:25:59] <bstansberry> but what if there is no deployment?[15:26:05] <maeste> bstansberry: but we have the same proble also with DS[15:26:15] <bstansberry> right --> no deployment[15:26:16] <maeste> bstansberry: which are deployed during ADD operation[15:26:16] <jpederse> bstansberry: then there is nothing[15:26:30] <maeste> bstansberry: yup[15:26:34] <bstansberry> the hq rar is basically no deployment as well[15:26:40] * bstansberry assumes[15:26:55] <jpederse> bstansberry: the JCA container lives within the resource adapter, so we need an instance before we can fully describes the capabilities[15:26:57] <maeste> bstansberry: yup[15:27:06] <jpederse> bstansberry: well, sort of[15:27:23] <jpederse> bstansberry: it is not a .rar archive, but it is a resource adapter[15:27:28] <bstansberry> i mean there is no deployment in the AS sense[15:27:30] *** smcgowan has joined #jboss-as7[15:27:30] *** ChanServ sets mode: +v smcgowan[15:27:40] <bstansberry> there is no /deployment=hq.rar in the model[15:27:49] <jpederse> bstansberry: we just have a service within AS 7 that you can use if you have a "rar" library[15:27:57] <maeste> bstansberry: what we need is the ability to add operation ad resource (+ description) to a particula instance of a resource...when it is added[15:27:59] <Nihility> i think you need subsystm=resource/resource=name/metrics*[15:28:40] <bstansberry> the issue is the ops, metrics etc is unknown until the ra is created[15:28:42] <maeste> Nihility: yup[15:28:52] <bstansberry> it's not known at subsystem add time[15:29:12] <maeste> bstansberry: exactly[15:29:20] <bstansberry> our hooks for adding resource descriptions, op handlers etc are done as part of extension registration[15:29:23] <Nihility> this sounds like what we were talking about last night[15:29:54] <maeste> bstansberry, jpederse, Nihility : I'm sorry, but I have to go offline for an hour. I'll be back later. Sorry again[15:30:00] <bstansberry> np[15:30:02] <jpederse> bstansberry: the really nice part (for us at least) is that if stats are disabled they disappear from the view :)[15:30:13] <jpederse> maeste: sure, we will continue in an hour[15:30:32] <Nihility> in the case of subsystem configured ras though[15:30:40] <Nihility> those are created at the time of subsystem init[15:30:44] <Nihility> albeit via services[15:31:22] *** maeste has quit IRC[15:32:17] *** aslak has quit IRC[15:38:06] *** mmoyses_ is now known as mmoyses[15:40:56] *** opalka has quit IRC[15:42:37] *** frainone has joined #jboss-as7[15:42:39] *** frainone has joined #jboss-as7[15:42:40] *** ChanServ sets mode: +v frainone[15:53:34] *** bstansberry has quit IRC[15:53:39] *** Nihility has quit IRC[15:53:49] *** pilhuhn is now known as pil-biab[15:58:21] <Jaikiran> dmlloyd: does this look fine https://github.com/jaikiran/jboss-as/commit/f880745ab4ab19d5f99bd72e3829a811b2df4009[15:58:22] <jbossbot> git [jboss-as] f880745.. jaikiran Remove the instantiation interceptors and instead revert back to using the postconstruct chain for ComponentInstance. The interceptor chain creation and invocation is now moved out of the constructor[16:00:32] <dmlloyd> well the fields should still be final[16:02:14] <dmlloyd> iow this constructor logic could be moved to the BasicComponent and then the BasicComponentInstance constructor could just accept params for all the fields[16:02:21] <dmlloyd> synch won't be sufficient imo[16:02:38] <dmlloyd> unless we synchronize everything on BasicComponentInstance which we don't want to have to do[16:03:12] *** bstansberry has joined #jboss-as7[16:03:12] *** ChanServ sets mode: +v bstansberry[16:03:39] *** hbraun has quit IRC[16:03:42] *** Nihility has joined #jboss-as7[16:03:42] *** Nihility has joined #jboss-as7[16:03:42] *** ChanServ sets mode: +v Nihility[16:04:29] <smcgowan> bstansberry, nihility: you avail for the call this morning?[16:04:44] <bstansberry> we're on a call with the HQ guys[16:05:06] <bstansberry> as is dmlloyd[16:05:10] <smcgowan> k[16:08:02] *** jdcasey has joined #jboss-as7[16:08:34] *** galderz has joined #jboss-as7[16:08:34] *** ChanServ sets mode: +v galderz[16:11:02] *** galderz has quit IRC[16:14:38] *** rawbdor has joined #jboss-as7[16:14:53] *** pil-biab is now known as pilhuhn[16:20:49] *** galderz has joined #jboss-as7[16:20:49] *** ChanServ sets mode: +v galderz[16:29:01] *** galderz has quit IRC[16:29:54] <asaldhan> rmaucher: hi. do u have a link to the JBWeb openssl settings?[16:33:30] <rmaucher> you can look at the web subsystem impl[16:36:05] *** maeste has joined #jboss-as7[16:36:05] *** ChanServ sets mode: +v maeste[16:36:23] <maeste> jpederse, bstansberry : I'm back if you need me[16:36:49] <bstansberry> maeste: we're on a call for a bit[16:37:12] <maeste> bstansberry: oki, just ping me when you are free[16:40:12] *** tdiesler has quit IRC[16:41:26] <bstansberry> dmlloyd: maeste's issue ties into what you're doing[16:41:44] <bstansberry> basically an op handler wants to register resources/handlers etc[16:42:05] <dmlloyd> just do be clear, I wasn't doing that, just arguing about it :)[16:42:35] <bstansberry> you're doing == your branch[16:43:08] <bstansberry> i.e. changes to operation context[16:44:03] *** Nihility has quit IRC[16:46:57] *** bstansberry has quit IRC[16:51:01] *** mbg has joined #jboss-as7[16:51:01] *** ChanServ sets mode: +v mbg[16:51:21] *** jamezp_afk is now known as jamezp[16:52:57] *** AndyTaylor has quit IRC[16:55:08] <bobmcw> dmlloyd: I could use a hand...[16:55:16] <bobmcw> got my stuff subverting WebDeployment bits[16:55:17] <bobmcw> seeing[16:55:18] <bobmcw> 10:56:08,056 INFO [org.jboss.web] (MSC service thread 1-4) registering web context: /simple.[16:55:27] *** mbg has quit IRC[16:55:27] *** mbg has joined #jboss-as7[16:55:27] *** leguin.freenode.net sets mode: +v mbg[16:55:31] <bobmcw> but nothing showing[16:59:17] *** bstansberry has joined #jboss-as7[16:59:17] *** ChanServ sets mode: +v bstansberry[17:07:40] *** Nihility has joined #jboss-as7[17:07:41] *** Nihility has joined #jboss-as7[17:07:41] *** ChanServ sets mode: +v Nihility[17:08:01] <bstansberry> wolfc: been testing AS7-431[17:08:02] <jbossbot> jira [AS7-431] Deployment content management enhancement [Open (Unresolved) Task, Major, Carlo de Wolf] https://issues.jboss.org/browse/AS7-431[17:08:23] <bstansberry> I'll push a branch up with some tweaks for your review before I can merge it[17:08:27] <bstansberry> in a sec[17:08:39] <wolfc> bstansberry: take your time, dinner is up for me[17:08:45] <bstansberry> an interesting thing I see is this when a full replace is done on a domain[17:08:47] <bstansberry> http://pastebin.com/rKfbghHc[17:08:52] <bstansberry> cool enjoy[17:09:13] <bstansberry> ^^^ seems to work out in the end, but stuff shows up in the logs[17:09:23] <bstansberry> something i'll poke at a bit[17:15:07] <jpederse> bstansberry: so, we are good ?[17:15:41] <bstansberry> no, we have to figure out how to do this. david is driving to where we are; i'll talk more with him[17:16:07] <bstansberry> maeste: what are the call paths that result in the need for these resources?[17:16:11] <jpederse> bstansberry: but you are good with input from us ?[17:16:17] <bstansberry> ^^^[17:16:43] <bstansberry> i.e. some mgmt op that adds an ra to the ra subsystem would be one[17:17:10] <maeste> bstansberry: well we need to add metrics and operations where handlers could receive an instance of ResourceAdapter or DataSource(XA too)[17:17:31] *** stliu has joined #jboss-as7[17:17:39] <maeste> bstansberry: we have add operations that create the instance and start services[17:17:41] *** ChanServ sets mode: +v stliu[17:18:08] <maeste> bstansberry: atm we are adding ops and metrics statically in the extension[17:18:23] <maeste> bstansberry: but we haven't there any instace of the resource to use[17:19:05] <bstansberry> AIUI you also don't know what all is exposed by the resource[17:19:17] <bstansberry> when you register the extension[17:20:03] <maeste> bstansberry: yup we need the instance, because we can do something like ds.getStatistics().getExposedAttributeStats()[17:20:22] <bstansberry> let's divide this into 2 pieces[17:20:58] <bstansberry> to properly register these mgmt resources and their handlers, you need access to the appropriate ModelNodeRegistration when you add the ra, or ds[17:21:21] <maeste> bstansberry: yup[17:21:42] <maeste> bstansberry: and during deployment too[17:21:54] <maeste> bstansberry: for deployed RA through .rar[17:22:27] <bstansberry> then later to handler the operation you need access to the service that represents the ds, ra etc[17:22:44] <bstansberry> this latter part is supported now; you can lookup services[17:23:00] <maeste> bstansberry: yup, but[17:23:30] <maeste> bstansberry: we need to access this services also during registration[17:24:00] <maeste> bstansberry: because the metrics we add are different for each vendor (for example) in DS[17:24:10] <bstansberry> the basic issue is having access to the ModelNodeRegistration during handling of an operation[17:24:22] <smarlow> Could someone please pull my "relative datasource name" test case from https://github.com/scottmarlow/jboss-as/commit/c38460087767e9879967231d8f2ad15792f85c9a[17:24:23] <jbossbot> git [jboss-as] c384600.. Scott Marlow JBCTS-1109 add unit test for relative datasource name[17:24:48] <maeste> bstansberry: yup the add operation in this case[17:24:55] <bstansberry> I'm assuming that the operation has access to the needed services; the new bit is access to the MNR[17:25:04] <maeste> bstansberry: yup you are right[17:25:13] <dmlloyd> bobmcw: what's up?[17:26:34] <bstansberry> but, what I'm concerned about is all code paths that need to do this registration, and where these runtime resources should live in the tree[17:27:16] <maeste> bstansberry: yup right[17:28:23] <bstansberry> I'd discussed w/ emuckenhuber having DUPs able to register new resources as children of the resource that represents the deployment[17:28:44] *** adietisheim has quit IRC[17:28:59] <bobmcw> dmlloyd: 'k, figured out, partially[17:28:59] <bstansberry> and I can see for example the ra subsystem registering new resources under /subsys=ra/ra=somera as part of the "add" op[17:29:06] <bobmcw> we're deploying an archive named "simple.knob"[17:29:22] <bobmcw> AS7 rediscovered an AS6 bug that assumes extensions are 3 letters[17:29:29] <bobmcw> so, the context ends up being "simple."[17:29:37] <bstansberry> maeste: where i'm not clear is where stuff should be registered when user deploys foo.rar[17:29:38] <bobmcw> ffs people, lastIndexOf('.') isn't that hard :)[17:30:20] <bobmcw> dmlloyd: so, we get a 404, because somehow the WarMetaData/WebMetaData that contains our config for a servlet filter isn't actually deploying our filter[17:30:29] *** kcbabo has quit IRC[17:30:29] <bobmcw> we've marked the unit as a WAR deployment-type[17:30:36] <bobmcw> things mostly work, but our filter doesn't init[17:30:47] <bobmcw> and logging/console both seem pretty quiet[17:30:48] <maeste> bstansberry: that's another problem. atm we are not registering any operation for them[17:30:57] *** kcbabo has joined #jboss-as7[17:30:57] *** ChanServ sets mode: +v kcbabo[17:31:17] <bstansberry> the general support for that, emuckenhuber is working on[17:31:22] <bobmcw> I have everything jacked to TRACE, but post-boot, everything is suspiciously non-TRACEy[17:31:26] <maeste> bstansberry: oki[17:31:54] *** maxandersen has quit IRC[17:32:03] *** mmoyses is now known as mmoyses_[17:32:05] *** pmuir has quit IRC[17:32:12] <bstansberry> maeste: but, for the deployment of foo.rar, where would these new resources live in the overall tree?[17:32:40] *** pmuir has joined #jboss-as7[17:32:40] *** pmuir has quit IRC[17:32:40] *** pmuir has joined #jboss-as7[17:32:40] *** ChanServ sets mode: +v pmuir[17:32:55] <bstansberry> the idea was DUPs could register new resources under /deployment=foo.rar *not* under /subsystem=ra/ra=foo.rar[17:33:17] *** maxandersen has joined #jboss-as7[17:33:18] *** ChanServ sets mode: +v maxandersen[17:33:18] <maeste> bstansberry: yup, but it's right[17:33:43] <bstansberry> ok, but what about, for example, the hq.rar which has no deployment?[17:33:55] <smcgowan> ALR: you there?[17:34:13] <maeste> bstansberry: it is in fact deployed with a special service[17:34:39] <maeste> bstansberry: we can add to this service the ability to register resources[17:35:00] <maeste> bstansberry: giving the address as parameter[17:35:03] <bobmcw> dmlloyd: also, it'd do awesome to have a <system-resources> in a module.xml, perhaps[17:35:30] <bobmcw> TorqueBox wants to assume folks have JRuby installed on their system somewhere, and $JRUBY_HOME or jruby.home property/etc points to it[17:35:40] <bobmcw> we'd like to use $JRUBY_HOME/lib/*.jar[17:35:48] <bobmcw> in our TorqueBoxExtension[17:35:50] <maeste> bstansberry: so when hq call us to add a ra, they have to give us also the new address to add operations and metrics[17:36:13] <dmlloyd> bobmcw: have you located the code that does the extension thing?[17:36:28] <bobmcw> dmlloyd: I have my FooExtension, FooParser, etc[17:36:34] <bobmcw> that extension? or some other type of extension?[17:36:45] <dmlloyd> the one where we are not doing lastIndexOf('.') :-)[17:36:56] <bstansberry> maeste: where do you see that address being? /subsystem=hq/something... ?[17:36:58] <bobmcw> ah, no, just saw the result in my URL[17:37:06] *** frainone has quit IRC[17:37:23] <maeste> bstansberry: /subsystem=hq/ra[17:38:17] <bstansberry> maeste: so are there going to be 3 locations where these things appear in the tree?[17:39:01] <maeste> bstansberry: yup for hq, because it's special[17:39:05] <bstansberry> e.g. some in the ra subsystem, some under a deployment, 1 in hq subsystem?[17:39:17] <dmlloyd> baileyje: do you recall anyplace in our deployers where we are assuming a three-char extension?[17:39:34] <dmlloyd> I was browsing thru last night and couldn't find anything like that[17:39:37] <baileyje> dmlloyd: I do not.[17:39:41] <maeste> bstansberry: having rar support we can remove ones from subsystem=ra[17:39:47] <dmlloyd> I wonder if it's something with the EE deployers.[17:39:48] <bobmcw> maybe it's bad code from our end[17:39:52] <baileyje> I think we were always looking for specific extensions.[17:39:53] <bobmcw> I'll double-check that[17:39:55] <dmlloyd> maybe specific to web even...[17:39:56] <maeste> bstansberry: it would be redundant[17:40:07] <dmlloyd> i.e. maybe jbossweb is making assumptions[17:40:22] <bstansberry> maeste: cool; that's clearer.[17:40:29] <baileyje> dmlloyd: What is the issue?[17:40:45] <bstansberry> the hq.rar one doesn't concern me so much; it's clearly a special case[17:40:50] <jpederse> bstansberry: it is basically the same as datasources - they are backed by JCA but have their own space[17:40:51] <alesj> dmlloyd: https://github.com/jbossas/jboss-vfs/pull/2[17:41:00] <bbrowning> ee/src/main/java/org/jboss/as/ee/component/EEModuleInitialProcessor.java: appName = parentName.substring(0, parentName.length() - 4);[17:41:02] <alesj> dmlloyd: fix for JBVFS-170[17:41:04] <jbossbot> jira [JBVFS-170] Support for -Djboss.vfs.forceCaseSensitive=true [Open (Unresolved) Feature Request, Minor, Ales Justin] https://issues.jboss.org/browse/JBVFS-170[17:41:06] <bbrowning> one place, maybe more ;)[17:41:12] <bbrowning> dmlloyd: ^^[17:41:53] <dmlloyd> baileyje: bob is doing torquebox integration and his deployments don't have a three-char extension, and his context URLs (I guess?) are messed up as a result[17:42:02] <bstansberry> jpederse: yeah, but the space for datasources is under /subsystem=datasource[17:42:14] <bobmcw> dmlloyd: exactly[17:42:36] <baileyje> Yeah. Web does take the extension off.[17:42:41] <jpederse> bstansberry: yup - so the HQ RA stuff should show up under HQ[17:42:45] <baileyje> to make the context root[17:43:04] <bstansberry> jpederse: ok, i see what you are saying. sure[17:43:06] <bbrowning> ahh yes - web/src/main/java/org/jboss/as/web/deployment/WarDeploymentProcessor.java: pathName = "/" + deploymentUnit.getName().substring(0, deploymentUnit.getName().length() - 4);[17:43:45] <baileyje> dmlloyd, bobmcw: WarDeploymentProcessor line 130[17:44:07] <baileyje> nevermine..[17:44:12] <baileyje> bbrowning got it[17:44:17] <dmlloyd> alesj: got it thanks.[17:44:33] <alesj> dmlloyd: np, i also have another pull no. 1[17:44:53] <dmlloyd> okay should be an easy fix[17:44:58] <alesj> dmlloyd: which is just a useful to have .. i needed it somewhere[17:46:38] *** hardy has left #jboss-as7[17:47:04] <alesj> dmlloyd: can you also pull in #1?[17:49:26] <rmaucher> for the context path, it's just a default; I think people should use a jboss-web.xml in most cases it is cleaner[17:49:51] *** maeste has quit IRC[17:51:51] <bobmcw> rmaucher: yah, we don't use web.xml/jboss-web.xml, but instead our Processors munge WarMetaData[17:51:53] <bobmcw> and so far, failing[17:52:05] <bobmcw> the final merged metadata doesn't include our configs[17:54:27] <baileyje> bobmcw: You could update the metadata to set the path[17:54:50] <bobmcw> assuming we can figure out how to get our updates to stick, sure![17:55:26] <bbrowning> bobmcw: yeah we should be able to setContextRoot on JBossWebMetaData[17:55:57] <bbrowning> for a temporary workaround[17:56:32] <baileyje> bobmcw: As an example.. EarContextRootProcessor sets the context root in a processor.[17:57:43] <baileyje> bobmcw: There could be an issue with the order of attachments.[17:58:00] <bobmcw> I think we're early enough in the chain[17:58:08] <bobmcw> but I'll double-check[17:58:35] *** liweinan has quit IRC[17:58:37] <dmlloyd> alesj: oh ok[17:59:36] <dmlloyd> got it[17:59:43] *** jcosta has quit IRC[17:59:45] <alesj> dmlloyd: thanks[18:02:36] *** alesj has quit IRC[18:03:30] *** maeste has joined #jboss-as7[18:03:30] *** ChanServ sets mode: +v maeste[18:04:03] <maeste> bstansberry, jpederse : sorry network down. So are we goo?[18:04:32] *** maxandersen has quit IRC[18:04:37] <bobmcw> rmaucher: exactly, bad ordering on processors[18:04:39] <bobmcw> all good![18:04:42] <bobmcw> thanks![18:05:55] *** pilhuhn is now known as pil-dinner[18:07:21] *** magesh has quit IRC[18:07:53] *** sannegrinovero has quit IRC[18:07:59] *** sannegrinovero has joined #jboss-as7[18:07:59] *** sannegrinovero has quit IRC[18:07:59] *** sannegrinovero has joined #jboss-as7[18:07:59] *** ChanServ sets mode: +v sannegrinovero[18:08:09] <bstansberry> maeste: what would make me more comfortable is if you could send a mail to the dev list summarizing what for what subsystem ops you would like to have the MNR exposed, as well as for what deployment types[18:08:29] <bstansberry> and then for each of those, where you see the new resource ending up in the tree[18:08:58] <bstansberry> I have a picture from this chat, but it would be nice to have it clearly spelled out in one place[18:09:38] <maeste> bstansberry: oki I'll do this evening[18:09:59] <bstansberry> thanks. :)[18:13:10] *** davidbos has quit IRC[18:21:33] *** stansilvert has joined #jboss-as7[18:22:59] *** jfclere has quit IRC[18:24:06] *** emuckenhuber has quit IRC[18:24:56] <bobmcw> rmaucher: next question... I've got a servlet Filter, and I'd like to inject a Service<T> into it[18:25:09] <bobmcw> under AS6, we were cheap, and used the Kernel to lookup an mcbean by name[18:25:11] <rmaucher> well, you don't ;)[18:25:35] <bobmcw> rmaucher: what's the solution to inject stuff into servlet componentry? I'm happy to be spec-noncompliant[18:26:13] <rmaucher> there's not going to be any solution for injection[18:26:23] <rmaucher> (besides the EE stuff of course)[18:26:32] <dmlloyd> yeah you could use EE stuff[18:26:38] <bobmcw> @Inject?[18:26:39] <dmlloyd> add the dependency to the phase context via attachment[18:26:41] *** alexsmirnov has joined #jboss-as7[18:26:57] <bobmcw> dmlloyd: I have no idea what you just said, really[18:27:01] <dmlloyd> then you can define a resource injection on the EE module class, or you can just use the service directly[18:27:15] <dmlloyd> bobmcw, during deployment processing you can add dependencies to the deployment itself[18:27:30] <dmlloyd> if you're trying to depend on something external that is[18:27:34] <bobmcw> what replaces the Kernel registry bits?[18:27:44] <dmlloyd> if you're trying to inject something from your deployment to something else in your deployment it's different[18:28:11] <bobmcw> yah, deploying an app creates a Service<RubyRuntimePool> basically, *and* sets up a Filter that needs to access it[18:28:36] <bobmcw> I've been able to Injector<RubyRuntimePool> with InjectedValue<T> to get it into other services[18:28:42] <dmlloyd> and that filter gets attached to a single servlet? or a bunch of em?[18:28:44] <bobmcw> but I need to cross into the servlet container now[18:28:54] <bobmcw> dmlloyd: gets attached to the root context[18:28:59] <bobmcw> we don't really have any servlets[18:29:09] <dmlloyd> oh you use contexts[18:29:23] <dmlloyd> well we SHOULD have a service for each context[18:29:24] <bobmcw> path pattern or whatnot, yah[18:29:31] <dmlloyd> and a service for each filter and one for each servlet[18:29:42] <dmlloyd> because it makes sense architecturally[18:29:50] <dmlloyd> that said, this lot isn't so into making sense these days :)[18:30:12] <bobmcw> so, if I want to replace my AS6 kernel.lookup(...).getTarget()[18:30:12] <dmlloyd> how are you creating your context?[18:30:19] <bobmcw> JBossWebMetaData[18:30:24] <bobmcw> and its deploying like a war[18:30:36] *** jdcasey has quit IRC[18:30:39] <dmlloyd> cripes[18:30:43] <dmlloyd> well, rmaucher will fix it :)[18:30:46] <bobmcw> https://gist.github.com/f25d26fff6145fc0a1f7[18:30:49] *** jdcasey has joined #jboss-as7[18:30:57] <bobmcw> and we just set the url-pattern to *[18:31:02] <dmlloyd> you can get at any service via a ServiceRegistry instance[18:31:06] <bobmcw> so it is effectively our big-ass single bridge back to jruby[18:31:14] <bobmcw> dmlloyd: 'k, thanks, that'll do[18:31:27] <bobmcw> well[18:31:33] <bobmcw> kernel used to be available in the servlet context[18:32:08] <baileyje> bobmcw: You should still be able to use injection.[18:32:26] <baileyje> just may be a bit tricky.[18:32:29] <bobmcw> baileyje: which flavor of injection, and can you point me somewhere?[18:32:45] <bobmcw> I hate lookups, prefer injecting, of course[18:32:50] <baileyje> I am still looking at what you have going on in your gist[18:32:55] <wolfc> bstansberry: looking at the paste I think it's a result from what stuartdouglas noted. msc is incorrectly reported as being stable.[18:33:20] <bobmcw> baileyje: so this is mostly AS6 code I'm adjusting[18:33:27] <bbrowning> bobmcw: could we not also stuff things onto the servlet context via deploymentUnit.getAttachment(ServletContextAttribute.ATTACHMENT_KEY) ?[18:33:28] <bobmcw> but we used to set an init param of the MCBean we'd have to lookup[18:33:33] <baileyje> bobmcw: One issue is your filter is being created by jboss-web based on the filter metadata, correct?[18:33:35] <bobmcw> and then grab the Kernel from the context, and do the lookup in Filter.init[18:33:57] <wolfc> bstansberry: the bit I don't like in my patch is where I have to make sure certain services are down before installing new ones. I basically disabled the asynchronism of msc to make it happen.[18:34:00] <bobmcw> bbrowning: perhaps?[18:34:06] <bobmcw> baileyje: yah, we're doing FilterMetaData[18:34:08] *** emuckenhuber has joined #jboss-as7[18:34:08] *** ChanServ sets mode: +v emuckenhuber[18:34:13] <bobmcw> if there's a better way, I'm happy to do it[18:34:14] <bstansberry> wolfc: i assumed the same[18:34:28] <bobmcw> was just trying to leverage the existing tomcat bits, and conform to its MetaData expectations[18:34:47] <bbrowning> bobmcw: any ServletContextAttributes on ServletContextAttribute.ATTACHMENT_KEY get passed to servlet context.setAttribute(name, value)[18:35:01] <baileyje> bobmcw: There is a way to get things into your servlet context[18:35:03] <bbrowning> probably not The Way™ to do it[18:35:11] <baileyje> bbrowning: got there first.[18:35:43] <bobmcw> would you suggest putting the ServiceRegistry there, and doing a lookup from within the Filter#init?[18:35:54] <bobmcw> or putting an Injector<T> there, and getValue() on that?[18:36:05] <bobmcw> or some other methodology[18:36:14] <baileyje> I would say an injectedvalue in the context[18:36:15] <bobmcw> since the thing-we-inject might start later than the Filter itself[18:36:27] <bobmcw> will getValue() block until available?[18:36:55] <baileyje> They key is to make sure your deployment will have a dep on the service you needed[18:37:09] <baileyje> then an InjectedValue in the context[18:37:17] <bobmcw> the service is part of this same deployment[18:37:38] <bobmcw> but somehow express that dep on the JBossWebMetaData for the web-stuff as-a-whole?[18:37:46] <bobmcw> or some way to add the dep to the specific Filter?[18:38:04] <baileyje> bobmcw: Let me explore something for a minute[18:38:12] <bobmcw> baileyje: sure thing![18:38:18] <bobmcw> we appreciate the help, a lot[18:38:25] <bobmcw> did you get some TorqueBox stickers in Boston? :)[18:39:23] <baileyje> bobmcw: What phase are you setting up the filter metadata[18:39:23] <baileyje> ?[18:39:41] <bobmcw> PARSE, 0[18:39:56] <bobmcw> we're playing loose with priorities, just trying to jack in early[18:40:03] <bobmcw> this is day #3 of AS7 for us[18:42:18] *** stliu has quit IRC[18:44:00] <baileyje> bobmcw: What phase do you setup your JRubyRuntimePool service?[18:44:10] <bobmcw> INSTALL, I think[18:44:22] <bobmcw> REAL in AS6 terms, I figured[18:48:04] <baileyje> bobmcw: Ok. Is there one RuntimePool service per web module?[18:48:37] <bobmcw> typically, but maybe not always?[18:49:01] <bobmcw> I know it's ServiceName of the one I want[18:49:19] <baileyje> Ok. Great. one more min then[18:51:15] <bobmcw> so, this gets back a null[18:51:16] <bobmcw> this.rackAppPool = (RackApplicationPool) registry.getService( ServiceName.parse( rackAppPoolName ) );[18:51:31] <bobmcw> I dumped the ServiceRegistry into the context attributes, along with the service name[18:51:53] <baileyje> Where are you calling it?[18:52:21] <bobmcw> Filter#init[18:53:09] *** jdcasey has quit IRC[18:53:21] <baileyje> bobmcw: So the key issue is you need a way to set a dependency on your runtime pool for the WebDeployment[18:53:46] <baileyje> Which, there doesn't seem to be a good way to do at this point in time.[18:54:07] *** frainone has joined #jboss-as7[18:54:07] *** ChanServ sets mode: +v frainone[18:54:14] *** asoldano is now known as asoldano_away[18:54:15] <baileyje> This could be added though.[18:55:13] <baileyje> I guess we could update the ServletContextAttribute attachment to allow you to put a dependency on the attribute and use that as a dep for the web deployment[18:55:45] <bobmcw> some sort of ServletContextAttributeInjector[18:55:54] <bobmcw> inject into the named spot, implicit dependency[18:56:23] <bobmcw> so, 7.0.0.CR1 in 3 weeks, eh? :)[18:56:26] <bbrowning> what is builder.addDependencies(deploymentUnit.getAttachmentList(Attachments.WEB_DEPENDENCIES)); ?[18:56:46] <bobmcw> hey hey[18:56:51] <bbrowning> is that a way to set additional dependencies for the ServiceBuilder<Context> ?[18:57:16] <bobmcw> it's a list of ServiceNames[18:57:17] <bbrowning> line 216 of WarDeploymentProcessor[18:57:36] *** pmuir has quit IRC[18:57:59] <bobmcw> trying[18:58:39] <bobmcw> hrm[18:58:51] <bobmcw> I think it affected startup order of services'n'such, but still caught a null on the getService(...)[18:58:56] <bobmcw> I wonder if my lookup sucks[18:59:50] <bobmcw> definitely affects ordering[19:02:36] <dmlloyd> stuartdouglas / Jaikiran: do you guys think we can merge this week?[19:02:46] <Jaikiran> dmlloyd: yes, that's the plan[19:03:00] <Jaikiran> dmlloyd: smoke tests are passing and the integration part looks good[19:03:11] <Jaikiran> however, we'll need to fix thta duplicate binding stuff too[19:03:28] <dmlloyd> ah I see[19:03:38] <dmlloyd> is that necessary to merge do you think?[19:03:43] <dmlloyd> is it a regression?[19:03:45] <Jaikiran> btw, once merged, i still expect some impl level changes including a deterministic ordering of interceptors and configurators[19:03:53] <dmlloyd> okay[19:03:57] <Jaikiran> i see failures in testsuite/integration module[19:04:06] <dmlloyd> okay so it's not really a regression though[19:04:13] <Jaikiran> i am not sure if someone introduced new tests in there or if they were there all along[19:05:52] <dmlloyd> well we never had support for duplicate bindings[19:05:56] <dmlloyd> so I don't see why we'd regress due to that[19:07:03] <Jaikiran> so yeah, it's a new one i guess[19:07:12] <Jaikiran> stuartdouglas is working on weld/ejb integration[19:07:23] <Jaikiran> i don't know how far he is on that one[19:07:36] *** jamezp has quit IRC[19:10:37] *** jamezp has joined #jboss-as7[19:11:53] <baileyje> bobmcw: Your easiest solution would be to add a dependency to the web deployment using the WEB_DEPENDENCIES attachments list[19:13:10] <baileyje> but I am hacking out a possibly better sollution.[19:13:28] <dmlloyd> jamezp: hey I have one more change for you...[19:13:47] <jamezp> No problem.[19:14:29] <dmlloyd> jamezp: we should have one more flag for classpath mode: "-class" if specified, there's no CLI classpath and instead the CLASSPATH env var should be used. "-class" and "-cp" are mutually exclusive[19:15:02] <dmlloyd> oh and lastly - we need to change the java.class.path sys prop to be equal to our replacement class path.[19:15:04] <dmlloyd> so two changes :)[19:15:58] <jamezp> Okay so if -class is specified we use the system class path, correct?[19:18:42] <bbrowning> hmm - what's the expected ServiceName of ServiceName.parse("torquebox.web.rack.pool.\\"simple.knob\\"")[19:19:17] <bbrowning> I'm getting torquebox.web.rack.pool."simple.knob"."simple.knob"[19:19:26] <bbrowning> but I'd expect torquebox.web.rack.pool."simple.knob"[19:21:21] <jamezp> dmlloyd: I forgot to ask too. Is thread safety a concern in the ModuleLoader, specifically the ClassPathModuleLoader? My guess is not, but I thought I should ask.[19:23:39] *** darranl has quit IRC[19:24:24] <dmlloyd> well we should be concerned with it, but ModuleLoader mostly takes care of it for you[19:24:53] *** pferraro has joined #jboss-as7[19:24:53] *** ChanServ sets mode: +v pferraro[19:25:09] <jamezp> That was my thought. My only real concern is my set of directories, but the more I think about it's probably not really an issue.[19:25:12] <pferraro> Nihility: question[19:28:05] <baileyje> bobmcw: Can you cherry-pick a change from my jboss-as master?[19:28:23] <baileyje> bobmcw: https://github.com/baileyje/jboss-as/commit/58046c4de7f84296476d5ad2b387de48a3d6344e[19:28:24] <jbossbot> git [jboss-as] 58046c4.. John E. Bailey Allow servlet context attributes to declare dependencies[19:31:02] *** kkhan has quit IRC[19:33:16] *** fnasser has quit IRC[19:34:06] <bobmcw> baileyje: working with a hudson build at the moment, but I'll get setup and working with your source tree yah[19:35:00] <bobmcw> looks great, though[19:35:45] <bobmcw> though, I'd instantiate the Injector m'self for arg4?[19:37:04] <baileyje> then. you could just say... deploymentUnit.addToAttachmentList(ServletContextAttribute.ATTACHMENT_KEY, new ServletContextAttribute("servletContextAttributeName", runtimePoolServiceName, new InjectedValue<Object>()));[19:37:55] <baileyje> and the value should show up in your SC[19:40:16] * dmlloyd bbiab[19:40:22] <pferraro> Nihility: question - why was the infinispan subsystem section removed from standalone.xml?[19:49:39] <bobmcw> MSC puts the value into that InjectedValue<T>, and your new injector service shuffles it to the context?[19:49:42] <bobmcw> like magic[19:49:48] <Nihility> pferraro: it was added in a secutiry update, which later switched to not using infinispan for the default case, so i just removed it[19:50:04] <Nihility> pferraro: we can add it back, but nothing was using it[19:50:36] <pferraro> Nihility: I thought Scott was going to use it for the default JPA 2LC[19:51:18] <Nihility> pferraro: yeah good point[19:52:00] <pferraro> Nihility: so, the intent was to use a local-mode cache, instead of the default hibernate hashmap 2lc which lacks any support for eviction/expiration[19:52:13] <baileyje> bobmcw: That is the plan[19:52:38] <pferraro> Nihility: there's no jgroups dependency for local-only caches[19:54:29] *** Nihility has quit IRC[19:54:55] <jpederse> jamezp: any logging docs ?[19:55:29] <jamezp> jpederse: I started, but I'm not sure where to put them yet.[19:55:45] <jpederse> jamezp: k[19:56:06] <jpederse> jamezp: I think the rest is just under the top-level wiki thing[19:56:39] <jamezp> jperderse: That's probably where I should put it then. This is what I have so far https://docs.google.com/document/d/1pc5YrO71viUeexWQbjZTBVRLcb8PJPB6PP_v1nUWo8w/edit?hl=en[19:56:41] *** Jaikiran has quit IRC[19:57:27] <jamezp> I've mainly just copied what dmlloyd had already written. I need to give more details and probably some examples would be nice too.[19:57:52] *** bstansberry has quit IRC[19:57:56] <smarlow> pferraro: even if we don't default to using infinispan as the 2lc, it should still be available in standalone.xml[19:58:01] *** mmoyses_ is now known as mmoyses[19:58:44] <jpederse> jamezp: sounds good[19:59:01] <pferraro> Nihility: can you revert that commit?[19:59:32] <jamezp> jpederse: Now I probably just need to figure out how to add pages to the wiki :-) Probably pretty easy if I would just look.[20:00:08] <bobmcw> 'k, we just got a simple Hello World ruby app up on AS7[20:00:10] <jpederse> jamezp: must be a "Create article" on the top right...[20:00:28] <bobmcw> muchly appreciate the help, will certain be seeking more[20:00:31] <jpederse> bobmcw: kick ass[20:00:39] <bobmcw> baileyje: and we'll try out your commit on pushing the dependencies[20:01:21] <smarlow> smcgowan: I think pferraro found the cause of the http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-testSuite-sun16/lastCompletedBuild/testReport/ failures, someone removed Infinispan from standalone.xml, oops[20:01:59] <smcgowan> smarlow: i just noted that changing my tck config to sync with that, was that intentional?[20:02:06] <jamezp> jpederse: Looks right to be. I'll get something started soon.[20:02:45] <smarlow> smcgowan: it was an intentional mistake :)[20:04:59] <smarlow> smcgowan: it looks like we just need to revert https://github.com/jbossas/jboss-as/commit/68b6a48ef5cdc5f8b3b908e4e216281adf20ecf1[20:04:59] <jbossbot> git [jboss-as] 68b6a48.. Jason T. Greene Remove infinispan config[20:06:16] <smcgowan> smarlow: i don't actually need it - so does JPA have a dependency on that?[20:06:46] <smarlow> smcgowan: yes, we support Infinispan for the second level cache[20:09:00] <smcgowan> smarlow: is that *support* or *require*?[20:10:05] *** mbg has quit IRC[20:10:56] <smarlow> smcgowan: in terms of which contract do you mean? if you ask a customer, they would say "required". The JPA spec is "optional"[20:20:38] *** sannegrinovero has quit IRC[20:24:39] *** frainone is now known as frainone_beright[20:24:56] *** frainone_beright is now known as frainone_away[20:26:56] *** jdcasey has joined #jboss-as7[20:28:52] *** frainone_away is now known as frainone[20:32:50] *** smcgowan is now known as smcgowan_lunch[20:54:48] *** clebert has quit IRC[20:55:10] *** clebert has joined #jboss-as7[20:55:10] *** ChanServ sets mode: +v clebert[20:59:24] *** fnasser_ has joined #jboss-as7[20:59:25] *** ChanServ sets mode: +v fnasser_[21:00:35] *** jamezp is now known as jamezp_afk[21:25:03] *** bstansberry has joined #jboss-as7[21:25:03] *** ChanServ sets mode: +v bstansberry[21:26:29] *** pil-dinner has quit IRC[21:28:31] *** Nihility has joined #jboss-as7[21:28:32] *** Nihility has joined #jboss-as7[21:28:32] *** ChanServ sets mode: +v Nihility[21:28:47] *** smcgowan_lunch is now known as smcgowan[21:29:10] *** clebert has quit IRC[21:29:28] *** maeste has quit IRC[21:29:30] *** clebert has joined #jboss-as7[21:29:31] *** ChanServ sets mode: +v clebert[21:31:50] <bbrowning> Does the new CLI and web management consoles replace jmx-console.war or is that expected to also work with AS7?[21:31:53] *** irooskov has joined #jboss-as7[21:32:03] *** jc3 has joined #jboss-as7[21:32:03] *** ChanServ sets mode: +v jc3[21:32:47] *** tcrawley has joined #jboss-as7[21:32:47] *** ChanServ sets mode: +v tcrawley[21:36:38] <bobmcw> dmlloyd: I'm seeing again where when we deploy myapp.knob (our archive), it apparently deploys, but my <subsystem> tag gets removed from standalone.xml[21:37:27] <bobmcw> https://github.com/torquebox/torquebox/tree/tb2/modules/core/src/main/java/org/torquebox/core/as[21:41:40] <bobmcw> ugh, too many places to register the same parser[21:41:50] *** alesj has joined #jboss-as7[21:42:43] *** maxandersen has joined #jboss-as7[21:42:44] *** ChanServ sets mode: +v maxandersen[21:42:50] *** maxandersen has quit IRC[21:42:54] *** maxandersen1 has joined #jboss-as7[21:44:37] <baileyje> bobmcw: Do you have the correct write method in place?[21:44:39] <Nihility> bobmcw: did you write the serialization bit[21:45:35] <bobmcw> I had initializeParsers(ExtParsingContext) but missed registration.registerXMLElementWriter(BaseSubsystemParser.getInstance());[21:45:48] <bobmcw> seems sorta repeat-ish[21:46:08] <smcgowan> mmoyses, rmaucher: could one of you take a look a the latest standalone config attachment in JBCTS-1102[21:46:25] <mmoyses> smcgowan: i replied with a jira comment[21:46:49] <mmoyses> smcgowan: try adding ../standalone/configuration to the file path of the login module options[21:47:15] <smcgowan> that's working for everything except the user/role properties[21:48:14] *** maeste has joined #jboss-as7[21:48:15] *** ChanServ sets mode: +v maeste[21:48:21] <smcgowan> mmoyses: http://pastebin.com/HXTEGJ9c but I'm not sure your latest pull request is upstream[21:48:33] <mmoyses> it was pulled yesterday[21:49:24] <mmoyses> smcgowan: have you tried with the full path name?[21:49:39] <smcgowan> mmoyses: i'll do some more testing[21:50:04] <mmoyses> smcgowan: how is the server started? maybe the current path is not JBOSS_HOME/bin as i assumed[21:50:47] <smcgowan> from $JBOSS_HOME/bin ./standalone.sh[21:51:12] <Nihility> bobmcw: the intention was to allow a separate writer and reader, but the reality is that everyone uses the same class[21:51:53] <bobmcw> k[21:52:12] <Nihility> bobmcw: so consider it an API oddity :)[21:52:45] <smcgowan> mmoyses: i did find a typo in the path, retesting[21:53:08] <smcgowan> well, not a typo, but the props were in a directory[21:56:17] <smcgowan> mmoyses: it's working now -[21:56:54] <mmoyses> ;)[21:58:26] <mmoyses> bstansberry: got a few minutes?[21:59:35] <rmaucher> pull request: https://github.com/rmaucher/jboss-as/commit/a8ec8be5472459879321c9220a8c70157cca8d11 and https://github.com/rmaucher/jboss-as/commit/1d895655a3e56920a9a55c676f6a652dfab3d6c6 thanks[21:59:36] <jbossbot> git [jboss-as] a8ec8be.. Rémy Maucherat Fir redirect-port attribute handling.[21:59:37] <jbossbot> git [jboss-as] 1d89565.. Rémy Maucherat Improve descriptions.[21:59:50] *** jamezp_afk is now known as jamezp[22:02:10] *** fnasser_ has quit IRC[22:05:53] *** slaboure has quit IRC[22:06:13] <Nihility> stuartdouglas: hey you around[22:08:39] <bobmcw> Nihility: s'allgood, we're happy to find stuff we can complain about[22:08:47] <bobmcw> helps our frustration of learning a new codebase[22:08:53] <bobmcw> <whinge/>[22:09:15] <bbrowning> bobmcw: well, you could have done like me and just refrained from learning AS6 ;)[22:09:29] <bbrowning> makes AS7 easier![22:10:18] <jbossbot> git [jboss-as] push master b21a580.. Paul Ferraro AS7-749 Expose useSynchronization/recovery from infinispan subsystem schema[22:10:18] <bobmcw> Nihility: if we miss the 7.0.0 bus in terms of everything TorqueBox needs, you anticipate a 7.1, 7.2 over the summer?[22:10:19] <jbossbot> jira [AS7-749] Expose useSynchronization/recovery from infinispan subsystem schema [Coding In Progress (Unresolved) Enhancement, Major, Paul Ferraro] https://issues.jboss.org/browse/AS7-749[22:10:19] <jbossbot> git [jboss-as] push master 6bb395c.. Jason T. Greene Fix trailing WS[22:10:19] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/afe17a4...6bb395c[22:11:15] <Nihility> bobmcw: we are moving the 7.0 date by about 3 weeks to accommodate a change in spec/cert strategy[22:11:27] <bobmcw> so we have ~6wks?[22:11:33] <bobmcw> but still, 7.x over the summer?[22:11:47] <Nihility> bobmcw: 7.1 is fall[22:11:52] <Nihility> septemberish[22:12:16] <bobmcw> EAP on 7.latest?[22:12:29] <Nihility> 6 on 7.1[22:12:32] <bobmcw> just trying to figure out my timeline[22:12:44] <bobmcw> so, conceivably, we have until fall to get AS7 happy for TorqueBox[22:12:49] <Nihility> right[22:12:50] <bobmcw> 7.1 is our drop-dead[22:12:53] <bobmcw> *whew*[22:12:59] <Nihility> ideally if you want 7.0, you need to be in by CR1[22:13:02] <Nihility> or at least mostly there[22:13:05] <bobmcw> right right[22:13:22] <Nihility> it can wiat for 7.1 though[22:13:24] <bobmcw> Nihility: also, not today, but want to discuss having torquebox extensions in jboss-as-dist.zip[22:13:25] <Nihility> imo[22:13:33] <bobmcw> vs us assembling our own torquebox-as-dist.zip[22:13:38] <Nihility> ok[22:13:45] <bobmcw> dmlloyd suggested it, blame him[22:14:01] <Nihility> well the only thing is to keep the distro size[22:14:27] <bobmcw> we expect users to bring their own jruby.zip[22:14:37] <bobmcw> so just our handful (hah!) of simple (hah!) classes[22:15:02] <Nihility> we can also do multiple distros too[22:15:21] <Nihility> like i dont mind having jboss-as-the-world[22:15:26] <Nihility> and jboss-as-tiny-tim[22:16:46] <bobmcw> coolbeans[22:19:19] <jpederse> Nihility: CR1 is still May 31 ?[22:19:34] <jpederse> Nihility: or Final[22:19:57] <Nihility> jpederse: we are shifting it later[22:20:24] <jpederse> Nihility: k[22:20:50] <Nihility> jpederse: adding 3 weeks or so the original May 23rd date to allow for us to do the strict profile, and to fix some last minute things[22:21:10] <Nihility> so June 15th (not final yet)[22:21:38] <jpederse> Nihility: k, just let us know when you want the component update - at the latest[22:24:23] <bobmcw> Nihility: btw, please do publish a jboss-as-distribution.zip as a maven artifact for CR1[22:24:58] <Nihility> we do that already[22:25:06] <bobmcw> I only found a pom, not a zip[22:25:07] <rmaucher> would it be possible to do my pull request ? missing security related config for shelly[22:25:11] <rmaucher> thanks[22:25:24] <Nihility> rmaucher: im doing it right now, just running tests on it[22:25:54] <Nihility> bobmcw: it has a funny name, due to the way maven does artifacts its jboss-as-build-ver.zip[22:26:14] <rmaucher> cool :)[22:29:20] <jbossbot> git [jboss-as] push master 4cd0c59.. Rémy Maucherat Fir redirect-port attribute handling.[22:29:21] <jbossbot> git [jboss-as] push master 339afe7.. Rémy Maucherat Improve descriptions.[22:29:21] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/6bb395c...339afe7[22:33:09] <jbossbot> git [jboss-as] push master edcf64b.. Scott Marlow JBCTS-1109 add unit test for relative datasource name[22:33:10] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/339afe7...edcf64b[22:36:12] <Nihility> jpederse: oh hey we need some way[22:36:20] <Nihility> to "break" JCA[22:36:29] <Nihility> for our strict web profile config[22:36:29] <jpederse> Nihility: what ?[22:36:37] <Nihility> e.g. disable rars[22:36:39] <jpederse> Nihility: just rip it out[22:37:30] <jpederse> Nihility: better discuss with maeste tomorrow - I'm deep into our new cache impl[22:37:38] <Nihility> yeah maybe sthe solution is to remove it entirely[22:37:46] <Nihility> i guess the question is[22:37:55] <maeste> Nihility, jpederse : if you want I'm here[22:37:56] <Nihility> do we want datasources that are not dsd[22:38:05] <maeste> and I'm working, so shot if you need me[22:38:15] <Nihility> maeste: well let me just give you food for thought[22:38:32] <jpederse> Nihility: no[22:38:32] <Nihility> maeste: 7.0 will have a strict profile config[22:38:40] <Nihility> strict web that is[22:38:40] <jpederse> Nihility: WP is @DSD only[22:38:50] <Nihility> ok so we go with that then[22:38:57] <Nihility> or plan on that[22:38:58] <jpederse> Nihility: our "real" profile will go with JCA[22:39:19] <Nihility> yes our ee6 full preview will include it :)[22:39:24] <Nihility> aka[22:39:27] <Nihility> "useful profile"[22:39:28] <Nihility> :)[22:39:34] <maeste> lol[22:40:14] <Nihility> ok well if you guys talk to folks that are building stuff on jca[22:40:25] <Nihility> be sure to remind them to keep it optional so we can support ripping it out[22:40:32] <jpederse> Nihility: sure, HQ only[22:40:52] <jpederse> Nihility: I believe that Ike's stuff is dynamic[22:41:39] <stuartdouglas> morning[22:42:13] <Nihility> stuartdouglas: hey i asked you yesterday but forgot your answer[22:42:23] <Nihility> stuartdouglas: is cdi + ejb working in the ejb branch?[22:42:48] <stuartdouglas> mostly, there is still some outstanding stuff[22:43:09] <stuartdouglas> but it is more complete than what is in master[22:43:39] <Nihility> stuartdouglas: ok any timeframe you think to complete it?[22:43:44] <Nihility> any blockers?[22:44:32] <stuartdouglas> I started looking at the TCK yesterday, there are two main things outstanding[22:44:41] <stuartdouglas> the ability to get two different views of the same rjb[22:44:46] <stuartdouglas> ejb[22:45:07] <stuartdouglas> and ejb destruction[22:45:22] <jbossbot> git [jboss-as] push master 15d827a.. Alexey Loubyansky AS7-710[22:45:23] <jbossbot> jira [AS7-710] CLI deploy command doesn't allow deploying from a path containing space [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/AS7-710[22:45:23] <jbossbot> git [jboss-as] push master b972cd8.. Alexey Loubyansky AS7-710 use '/' as the separator for all platforms to make escaping special characters easier[22:45:23] <jbossbot> git [jboss-as] push master e58e55d.. Alexey Loubyansky AS7-710 fixed path index in tab-completion for windows[22:45:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/edcf64b...e58e55d[22:45:26] *** wolfc has quit IRC[22:45:32] *** aloubyansky has joined #jboss-as7[22:46:42] <smcgowan> jpederse, nihility: what does it mean: WP is @DSD only?[22:47:02] <Nihility> @DataSourceDefinition[22:47:16] <Nihility> the EE6 stuff for datasources that refs jdbc directly[22:47:18] <Nihility> hmmmm[22:47:22] <Nihility> i just realized a problem[22:47:34] <Nihility> smarlow: the wp tck requires global config datasources right?[22:47:40] <Nihility> so we cant use @DSD[22:48:07] <Nihility> oops[22:48:12] <Nihility> smcgowan: that was meant for you[22:49:11] <smcgowan> nihility: i'm looking at the spec now, but i think we will need more than that[22:49:38] <Nihility> its wierd because the spec doesnt require jca but i think you linked me tests that require global datasources[22:49:39] <smcgowan> JPA needs a global datasource[22:50:21] *** maxandersen1 has quit IRC[22:51:58] <Nihility> ohhh[22:52:03] <Nihility> dmlloyd has a solution![22:52:23] <dmlloyd> just drop in a deployment which has @DSD bound to a global name[22:52:31] <Nihility> thats our "configuration"[22:52:33] <Nihility> hahahahahahahahahaha[22:52:44] <dmlloyd> it's a really really dumb ds.xml :)[22:53:11] <jc3> will jmx-console be available in AS7, or some sort of REST-ish control interface?[22:53:17] *** lazarotti has joined #jboss-as7[22:53:32] *** lazarotti has quit IRC[22:54:28] <stuartdouglas> dmlloyd: We do have support for duplicate bindings in master[22:54:38] <dmlloyd> asking that is akin to walking in to a high-rise office building which is 90% constructed and then saying "so will this place have bathrooms or what?"[22:54:39] <dmlloyd> :)[22:54:43] <dmlloyd> stuartdouglas: no[22:54:46] <dmlloyd> oh wait[22:54:47] <dmlloyd> we do?[22:55:08] <dmlloyd> how[22:55:17] *** maxandersen has joined #jboss-as7[22:55:18] *** ChanServ sets mode: +v maxandersen[22:55:22] <stuartdouglas> the module level BindingsContainer[22:55:37] <dmlloyd> oh yeah, that's right[22:55:41] <dmlloyd> it was added on[22:55:43] <dmlloyd> hmmm[22:55:51] <dmlloyd> yeah so I guess we really don't want to regress on that[22:56:18] <stuartdouglas> also we need a way to override bindings based on DD[22:56:23] *** misty has joined #jboss-as7[22:56:37] *** misty has quit IRC[22:56:42] <Nihility> jc3: no jmx-console, instead we have a domain management facility which is accessable via http(json), java api, cli, and an admin console[22:56:50] *** misty has joined #jboss-as7[22:57:16] <dmlloyd> stuartdouglas, yeah I was hoping that the division EEModuleClassDescr and ComponentDescr would allow us to do that cleanly[22:57:38] <dmlloyd> and iirc EEModuleDescr for those goofy module-level ones[22:57:46] <jc3> Nihility: cool. link to docs describing http/json payload, please?[22:58:23] <stuartdouglas> I am not really sure, the same class can have different bindings, e.g. an interceptor class used in two ejb's can have two different overrides in the DD[22:59:45] <dmlloyd> yeah but the overrides are on the component[22:59:53] <dmlloyd> any annotations are on the class[23:00:00] <Nihility> http://community.jboss.org/wiki/FormatOfADetypedOperationRequest[23:00:03] <dmlloyd> theoretically[23:00:09] <Nihility> http://community.jboss.org/wiki/FormatOfADetypedOperationResponse[23:00:23] <Nihility> that describes the native format[23:00:29] <Nihility> json is a direct mapping[23:00:34] <Nihility> one more link coming:[23:02:30] <Nihility> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-February/000585.html[23:02:40] <jpederse> Nihility: neat-o, we now have prepared statement cache based on BoundedConcurrentHashMap, thanks ![23:02:53] <Nihility> jpederse: cool np[23:03:30] <jc3> Nihility: thanks for the links! :)[23:04:54] <smarlow> jpederse: if we add another 2lc, we can fork your improved BCHM, thanks![23:05:33] *** clebert has quit IRC[23:08:13] *** rmaucher has quit IRC[23:09:16] <maeste> bstansberry: a question: what is adding module-slot information in InstalledDriver?[23:09:36] <maeste> bstansberry: isn't the name sufffcient, since it is the only thing user are setting in xml?[23:09:59] <maeste> bstansberry: or in model, when adding the driver?[23:10:01] <bstansberry> maeste: I put it in simply because it exists[23:10:48] <maeste> bstansberry: oki. Since adding driver just use the name, I'de like to remove it to don't confuse users[23:11:42] <dmlloyd> a module is identified by name and slot[23:11:43] <Nihility> maeste: slot is optional[23:11:45] <dmlloyd> the slot defaults to "main"[23:11:49] <dmlloyd> but you have to support it[23:12:15] <maeste> dmlloyd: oki so I'll put slot also into the add operation[23:12:42] <maeste> dmlloyd: I'm just saying that if it is supported it have to be supported in both direction[23:13:38] <Nihility> oh right[23:13:40] <Nihility> totally agree[23:23:51] <bobmcw> Nihility: oddly, if I depend on jboss-as-build.zip, transitive deps mean I download every jar required to build it, apparently[23:24:13] *** jwulf has joined #jboss-as7[23:24:54] *** alesj has quit IRC[23:25:32] <bobmcw> CI would appreciate it if somehow we could avoid that...[23:25:51] <jamezp> dmlloyd: My tests are passing, but something feels wrong about it. https://github.com/jamezp/jboss-modules/commit/17405d7961ff1bfd01bf9b76ca59230e6f0bda72[23:25:52] <jbossbot> git [jboss-modules] 17405d7.. James Perkins MODULES-85 Add classpath module loader and CLI processing.[23:25:55] <jbossbot> jira [MODULES-85] Add support for class path bootstrap [Open (Unresolved) Enhancement, Major, James Perkins] https://issues.jboss.org/browse/MODULES-85[23:26:01] <smarlow> Nihility: thanks for the JPA commit![23:27:08] <smarlow> Nihility: could you also revert https://github.com/jbossas/jboss-as/commit/68b6a48ef5cdc5f8b3b908e4e216281adf20ecf1 (the removal of infinispan from standalone.xml which hurts our effort to use infinispan as a local cache)[23:27:08] <jbossbot> git [jboss-as] 68b6a48.. Jason T. Greene Remove infinispan config[23:29:01] <dmlloyd> jamezp: https://github.com/jamezp/jboss-modules/commit/17405d7961ff1bfd01bf9b76ca59230e6f0bda72#L0R73[23:29:02] <jbossbot> git [jboss-modules] 17405d7.. James Perkins MODULES-85 Add classpath module loader and CLI processing.[23:29:03] <jbossbot> jira [MODULES-85] Add support for class path bootstrap [Open (Unresolved) Enhancement, Major, James Perkins] https://issues.jboss.org/browse/MODULES-85[23:29:10] <dmlloyd> I don't think you need the extra if check[23:30:37] <jamezp> dmlloyd: So no need to for the delegate?[23:31:03] <dmlloyd> it was added on[23:31:05] <dmlloyd> er[23:31:06] <dmlloyd> well[23:31:17] *** clebert has joined #jboss-as7[23:31:17] *** ChanServ sets mode: +v clebert[23:31:24] *** mmoyses has quit IRC[23:31:25] <dmlloyd> I'm not so sure we want to bother supporting nested modules in the CP ML[23:31:39] <dmlloyd> it's one thing to support them in a runnable jar[23:31:41] <dmlloyd> but on the CP...[23:31:42] <dmlloyd> maybe not[23:32:17] <dmlloyd> https://github.com/jamezp/jboss-modules/commit/17405d7961ff1bfd01bf9b76ca59230e6f0bda72#L0R140 <- module paths always use / regardless of platform[23:32:18] <jbossbot> git [jboss-modules] 17405d7.. James Perkins MODULES-85 Add classpath module loader and CLI processing.[23:32:20] <jbossbot> jira [MODULES-85] Add support for class path bootstrap [Open (Unresolved) Enhancement, Major, James Perkins] https://issues.jboss.org/browse/MODULES-85[23:33:08] <jamezp> Okay, that's an easy change.[23:35:09] <dmlloyd> https://github.com/jamezp/jboss-modules/commit/17405d7961ff1bfd01bf9b76ca59230e6f0bda72#L3R0 <- should not be public[23:35:10] <jbossbot> git [jboss-modules] 17405d7.. James Perkins MODULES-85 Add classpath module loader and CLI processing.[23:35:11] <jbossbot> jira [MODULES-85] Add support for class path bootstrap [Open (Unresolved) Enhancement, Major, James Perkins] https://issues.jboss.org/browse/MODULES-85[23:35:54] <dmlloyd> oaky so back to ClassPathModuleLoader[23:36:00] <dmlloyd> I'd make the following changes:[23:36:51] <dmlloyd> 1. use System.getenv().get("CLASSPATH") in the constructor if nothing else specifies a CP[23:37:05] <dmlloyd> 2. forget about all the stuff which loads modules from the class path[23:37:20] <dmlloyd> then that separator change[23:37:23] <dmlloyd> that should do[23:38:13] <jamezp> So no need to search for the modules.xml file?[23:39:02] <smarlow> <smcgowan> so, if there is a dep on Infinispan, how can this be a *spec* test: org.jboss.as.test.spec.jpa.RelativeDataSourceNameTestCase[23:39:15] *** kkhan has joined #jboss-as7[23:39:16] *** ChanServ sets mode: +v kkhan[23:39:52] <smarlow> smcgowan: its kind of both[23:39:53] *** kkhan has quit IRC[23:40:18] <smarlow> smcgowan: the JPA spec does include the use of a 2lc[23:40:56] <smarlow> I'm not actually using the 2lc in that test[23:41:19] *** aloubyansky has quit IRC[23:42:07] *** jpederse has quit IRC[23:42:07] *** jpederse has joined #jboss-as7[23:43:18] <smcgowan> smarlow: can you provide a spec reference, just curious about that[23:43:32] <smarlow> sure[23:43:34] <smcgowan> re: use of a 2lc[23:45:02] <smarlow> smcgowan: 7.4[23:45:11] <smarlow> first paragraph[23:45:20] <smarlow> "This includes access to the second level cache that is maintained by the persis-[23:45:20] <smarlow> tence provider[23:45:20] <smarlow> "[23:45:34] <jamezp> dmlloyd: I'm a bit confused on #2. "forget about all the stuff which loads modules from the class path". Is that this https://github.com/jamezp/jboss-modules/commit/17405d7961ff1bfd01bf9b76ca59230e6f0bda72#L0R101[23:45:34] <smarlow> in jpa 2.0 spec[23:45:35] <jbossbot> git [jboss-modules] 17405d7.. James Perkins MODULES-85 Add classpath module loader and CLI processing.[23:45:36] <jbossbot> jira [MODULES-85] Add support for class path bootstrap [Open (Unresolved) Enhancement, Major, James Perkins] https://issues.jboss.org/browse/MODULES-85[23:46:50] *** jpederse has quit IRC[23:48:45] <smarlow> smcgowan: I'm walking away for a bit, but to be honest, I'm not sure we want to pull in the 2nd cache dependency for applications that don't need it.[23:49:03] *** maxandersen has quit IRC[23:49:07] <smarlow> but its still spec :)[23:49:44] <smcgowan> smarlow: but that's what the test is doing[23:50:39] <dmlloyd> jamezp: yeah[23:50:51] <smcgowan> funny, i had a diff spec version and it wasnt in it[23:51:53] <smcgowan> smarlow: 7.10[23:52:14] <jamezp> dmlloyd: When I do that module.relink(); fails. I could be misunderstanding something though.[23:52:25] *** irooskov has quit IRC[23:53:36] *** maxandersen has joined #jboss-as7[23:53:36] *** ChanServ sets mode: +v maxandersen[23:57:17] *** irooskov has joined #jboss-as7[23:58:33] *** clebert has quit IRC[23:59:56] *** kcbabo has quit IRC