March 3, 2011 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 3, 2011 NOTICE: This channel is no longer actively logged.
[00:24:47] *** bstansberry is now known as bstans_afk[00:32:29] *** mbg is now known as mbg|away[00:34:44] *** smcgowan is now known as smcgowan_dinner[00:44:32] *** rmaucher has quit IRC[00:47:51] <dmlloyd> okay I'm back[00:48:02] <dmlloyd> stuartdouglas, are you going to change that demo to deploy an ear instead?[00:48:18] <dmlloyd> if not I'm going to try to get it to bind a thing into global[00:49:35] <stuartdouglas> I can give it a go, I was not sure if you were still changing stuff[00:49:45] <dmlloyd> no I was afk[00:50:14] <dmlloyd> soon comes the dinner-thru-kids-bedtime break[00:50:50] <stuartdouglas> Are all your changes pushed?[00:50:55] <dmlloyd> yeah I think so[00:50:56] * dmlloyd checks[00:51:09] <dmlloyd> yeah[00:51:25] <dmlloyd> the newest IDEA seems way more aggressive about changing copyright dates[00:51:33] <dmlloyd> like you just open the file and sometimes it does it[00:51:35] <dmlloyd> annoying[00:53:08] <dmlloyd> anyway once that demo is working, one way or another, and I finish this naming thing I'm squishing this thing and pushing it[00:53:24] <stuartdouglas> ok, I have been looking at CDI injection[00:55:29] *** bstans_afk is now known as bstansberry[00:57:17] *** pgier has quit IRC[00:58:09] *** pgier has joined #jboss-as7[00:58:09] *** ChanServ sets mode: +v pgier[01:04:50] *** jpearlin has joined #jboss-as7[01:08:26] *** bgeorges has quit IRC[01:16:12] *** smarlow has joined #jboss-as7[01:16:12] *** ChanServ sets mode: +v smarlow[01:22:16] *** kkhan has quit IRC[01:23:59] <stuartdouglas> dmlloyd: I am getting some really weird behaviour at the moment, where some deployments are not going through all the deployers in the INSTALL phase[01:24:10] <stuartdouglas> so this make take longer than anticipated :-)[01:24:58] <dmlloyd> it's ok, I'm still trying to figure out why this is trying to inject into a field named "java:module/TempRemoveMeLater" :-)[01:27:41] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/8d1a1ac[01:27:41] <jbossbot> git [jboss-as] 8d1a1ac.. David M. Lloyd Fix injection locations[01:27:44] <dmlloyd> seems to work![01:27:55] <dmlloyd> I'm using java:module/env/ for now[01:27:59] <dmlloyd> we can change it if it's a problem[01:28:07] <dmlloyd> it bases the injection location on naming mode[01:28:29] <stuartdouglas> ok, I am getting some kind of missing dep in my ear deployment, so it never hits INSTALL[01:32:17] *** dmlloyd has quit IRC[01:33:37] *** Guest51553 has joined #jboss-as7[01:37:32] *** asaldhan has left #jboss-as7[01:55:21] <Guest51553> man this znc bouncer kinda sucks[01:56:12] *** Guest51553 has quit IRC[01:56:12] *** Guest51553 has joined #jboss-as7[01:56:15] *** Guest51553 is now known as dmlloyd[01:59:53] <dmlloyd> stuartdouglas: you should have a look in the MSC mbean to see what the dep graph looks like[02:00:08] <dmlloyd> if you're still stuck on that[02:00:21] <stuartdouglas> I got that sorted out, there was a dep on the other deployment in the manifest[02:00:22] <dmlloyd> kids are all headed for bed so it's quieting down here[02:00:29] <dmlloyd> ah, cool[02:00:38] <dmlloyd> we're gonna need better error reporting[02:00:44] * dmlloyd notes that for later...[02:00:46] <stuartdouglas> I thought that some of my ear code was adding a dep with the wrong name for a bit, but sorted it out now[02:01:07] <stuartdouglas> I think I nearly have it working[02:01:15] <dmlloyd> ok cool[02:01:20] <dmlloyd> so close![02:01:25] <stuartdouglas> but LookupService.bean is null[02:01:51] <stuartdouglas> (I only just got to this point when you pinged me)[02:01:57] <stuartdouglas> so it may be something simple[02:02:00] <dmlloyd> ah it was that way before too, I figured it was because they're in different DUs though[02:02:22] <dmlloyd> the MSC service dump will also tell you what JNDI services are active[02:03:18] <stuartdouglas> I can see what is wrong[02:03:47] <dmlloyd> is it binding to app like it should, btw?[02:03:56] * dmlloyd doesn't remember if he tested that[02:04:18] <stuartdouglas> although if it is bound to app[02:04:25] <stuartdouglas> we won't need lookupservice[02:04:42] <dmlloyd> well we still need some kind of service because we're testing from a SAR which doesn't have EE injection[02:07:45] <stuartdouglas> actually it looks like the component service is not coming up[02:07:51] <dmlloyd> what I don't understand is, why is bean null[02:07:56] <dmlloyd> shouldn't it be waiting for the service?[02:07:58] <dmlloyd> like blocking[02:08:20] <stuartdouglas> It does not look like it was written that way :-)[02:08:48] <dmlloyd> if not then it was pure luck that it ever worked[02:11:02] <dmlloyd> yeah I see nothing to ever hint that there was any kind of dep here[02:11:13] <dmlloyd> maybe it relies on deployment order or something[02:12:44] <stuartdouglas> for most of its life there would have been a sleep() in there as well[02:12:44] <stuartdouglas> so SimpleManagedBean is coming up[02:12:44] <stuartdouglas> but the START service for ManagedBeanWithInjected is not[02:13:27] <stuartdouglas> I think it was always just a fluke[02:13:50] <stuartdouglas> did you fix the removeMeLater thing?[02:14:17] <stuartdouglas> cause that is causing me problems[02:14:43] <dmlloyd> no it's still using that to bind to a global context[02:14:49] <dmlloyd> well it's still there I should say[02:14:54] <dmlloyd> it's all working in my ee[02:14:59] <dmlloyd> pushed out[02:15:26] <dmlloyd> hm it is invalid though[02:15:38] <dmlloyd> you can remove the name= from that[02:16:05] *** pferraro has joined #jboss-as7[02:16:05] *** ChanServ sets mode: +v pferraro[02:16:17] *** bgeorges has joined #jboss-as7[02:16:18] *** ChanServ sets mode: +v bgeorges[02:18:40] <dmlloyd> it should be binding to java:module/env/org.jboss.as.demos.managedbean.archive.BeanWithSimpleInjected/simple[02:18:43] <dmlloyd> if you remove name=[02:19:07] <stuartdouglas> at the moment it looks like a different problem[02:20:05] <stuartdouglas> It depends on jboss.naming.context.java.module."managedbean-example.ear"."managedbean-example.jar".module.SimpleManagedBean, I think it needs a CREATE on the end[02:22:08] <dmlloyd> CREATE is just for the component[02:22:15] <dmlloyd> "module" is a giveaway that it's not a component service[02:22:21] <dmlloyd> that'd be a view service I believe[02:22:24] <stuartdouglas> ah[02:22:36] <dmlloyd> if so though it should have a VIEW in there[02:22:42] <dmlloyd> before "module"[02:22:43] <dmlloyd> I think[02:22:45] * dmlloyd goes to look[02:22:50] <stuartdouglas> It would be neat if MSC could just ell me what services where missing[02:24:20] <dmlloyd> ah okay that's the service for the binding: java:module/SimpleManagedBean[02:24:26] <dmlloyd> so those bindings *are* missing[02:24:29] <dmlloyd> one sec...[02:25:16] <stuartdouglas> you cam merge this from my ee branch btw[02:25:36] <dmlloyd> okay will do so before I try to fix this[02:25:47] <stuartdouglas> I got rid of name[02:25:50] <stuartdouglas> and now jboss.naming.context.java.module."managedbean-example.ear"."managedbean-example.jar".module.SimpleManagedBean[02:25:52] <stuartdouglas> is missing[02:25:54] <dmlloyd> rebase needed[02:26:11] <dmlloyd> yeah makes sense[02:26:20] <dmlloyd> I forgot to do the MB.2.1.2 bindings[02:26:27] <stuartdouglas> I need some kind of notification for when you push :-)[02:26:49] <dmlloyd> I post the URL in here whenever I do[02:27:08] <stuartdouglas> ok, try now[02:28:11] <dmlloyd> Thread.sleep(60000);[02:28:11] <dmlloyd> lol[02:28:17] <stuartdouglas> oops[02:28:27] <stuartdouglas> I wanted it to hang around for a bit so I could connect jconsole[02:28:48] <stuartdouglas> now it just blocks anyway[02:29:33] *** jpearlin has left #jboss-as7[02:31:27] <dmlloyd> BindingDescription is overloaded past the breaking point[02:32:05] <dmlloyd> there's no real mechanism for actually binding the component views[02:32:16] <dmlloyd> of which managed beans only have one[02:33:04] <dmlloyd> view bindings depend on the VIEW service which depends on the CREATE service[02:33:20] <dmlloyd> resource bindings depend on what they inject (if anything), and are depended on by the START service[02:33:31] <dmlloyd> resource bindings are always relative to the environment namespace[02:33:40] <dmlloyd> (though perhaps they should not be...)[02:33:56] *** emuckenhuber has quit IRC[02:34:12] <Nihility> Ok so anything that comes from @Resource should go into env of the default namespace (module or comp)[02:34:25] <dmlloyd> yeah, that part works[02:34:33] <Nihility> same for @EJB[02:34:44] <Nihility> And any other ref type[02:34:45] <dmlloyd> just observing that my general-purpose binding mechanism isn't general-purpose enough to actually bind views into their rightful spots[02:35:07] *** smcgowan_dinner has quit IRC[02:35:09] <dmlloyd> running through the scenarios "out loud" to trigger my brain into working[02:35:24] <Nihility> name, depending on the component type may or may not allow specifying global jndi names[02:35:30] <Nihility> Ejb it does not[02:35:39] <Nihility> Datasources do allow it though[02:35:40] <dmlloyd> MB does not[02:35:48] <dmlloyd> really?[02:35:54] <dmlloyd> but you don't specify those with @Resource[02:36:01] <dmlloyd> that's gotta be dependent on the annotation right?[02:36:03] <Nihility> right @datasource[02:36:15] <dmlloyd> right now we don't have support for any of those[02:36:20] <dmlloyd> just @Resource[02:37:13] <Nihility> mb has that dumb vague section but I say make it consistent[02:37:27] <dmlloyd> okay so if datasource allows absolute names then BindingService should have that as an option at least[02:37:31] <dmlloyd> that's an easy change[02:37:44] <Nihility> I couldnt find another example[02:38:34] *** jpearlin1 has joined #jboss-as7[02:38:40] <Nihility> As to defaults[02:39:15] <Nihility> Everything uses defining class/fieldorprop name[02:39:45] <Nihility> (reference types)[02:39:52] <dmlloyd> good[02:40:00] <dmlloyd> at least that's correct then[02:40:05] <dmlloyd> that's how I have it now[02:40:29] <Nihility> so the pattern for exposing an ejb into a custom global location[02:40:41] <Nihility> Is to put @ejb on the actual ejb[02:41:50] <Nihility> @ejb(name="java:global/env/blahblah") @stateless(name="foo")[02:41:56] <dmlloyd> interesting[02:42:17] <Nihility> the important thing is that it's additive[02:42:33] <dmlloyd> okay so no matter what you get the view bindings?[02:42:34] <Nihility> there is Always a portable deterministic name[02:42:42] <dmlloyd> what view does that actually bind?[02:42:48] <Nihility> you only define aliases[02:43:05] <Nihility> the ejb annotation specifies the view[02:43:15] <dmlloyd> oh you give the class name to bind?[02:43:29] <Nihility> Yes and it has some default rules[02:44:41] <Nihility> amazing that users are expected to grok this[02:44:43] <Nihility> Hahaha[02:45:13] <stuartdouglas> I would say that 90% of users think that all @EJB does is inject an EJB[02:45:36] *** emuckenhuber has joined #jboss-as7[02:45:36] *** emuckenhuber has joined #jboss-as7[02:45:36] *** ChanServ sets mode: +v emuckenhuber[02:46:17] <Nihility> I reread the eg ml and it wasn't even really clear what we all decided on various things, I hadnto refer back and forth between emails specs and the ri before I could make sense of all of it[02:48:52] <Nihility> Oh one other goofy thing that requires further looking into[02:49:12] <dmlloyd> where is the thing that gives the binding rules for views[02:49:14] <dmlloyd> in EJB[02:49:44] <Nihility> Is there is a beanName on @ejb that iirc is synonymous with ejb-link[02:50:08] <Nihility> so in addition to jndi we need to support ejb-link refs[02:50:24] <dmlloyd> should be easy enough since we already have MSC namespaces for stuff[02:50:54] <Nihility> the rules are in the ejb3 spec and EE[02:51:00] <Nihility> For views[02:51:27] <dmlloyd> yeah I'm looking in ejb and not finding it[02:51:34] <dmlloyd> but it's a huge spec[02:51:56] <Nihility> THe ejb3 spec also defines names for the default bindings of all views[02:52:01] <Nihility> It uses ! Marks[02:52:04] <dmlloyd> that's what I'm looking for[02:52:05] <dmlloyd> where is that[02:52:19] <Nihility> Don't have it ha dy one sec[02:52:26] <dmlloyd> ah I found it[02:52:27] <dmlloyd> 4.4[02:52:28] <dmlloyd> never mind :)[02:52:46] <dmlloyd> ok great it looks at least somewhat consistent with MBs[02:52:53] <dmlloyd> though I don't think MBs are bound to global by default[02:53:35] <Nihility> Global/module/ is an alias of nodu[02:53:42] <Nihility> Module pretty much[02:53:51] <dmlloyd> really[02:53:57] *** pferraro has quit IRC[02:53:57] <Nihility> e.g. glob a[02:54:08] <dmlloyd> heh you and your ipad![02:54:17] <Nihility> e.g. Global/foo.jar/[02:55:55] <dmlloyd> we don't have it working that way[02:56:00] <dmlloyd> there's no automatic mapping[02:56:05] <dmlloyd> they're just separate namespaces[02:57:53] <stuartdouglas> we discussed doing that ages ago[02:58:00] <stuartdouglas> and we decided against it[02:58:24] <stuartdouglas> I think there were security concerns, as it means any deployment can access any other deployments JNDI namespace[02:59:21] <dmlloyd> yeah[02:59:34] <dmlloyd> just today someone in ##java was asking if they should bind passwords into comp/env[02:59:39] * dmlloyd shudder[03:00:01] <dmlloyd> ok testing this fix[03:01:31] <dmlloyd> smoke tests failed, that's a bad sign...[03:01:33] <dmlloyd> trying it by hand[03:04:36] <jpearlin1> Nihility: I think I have everything working with the upload stuff...do we want to just pass the DMR response from the upload handler in the HTTP response? I assume that we really don't know yet what the web console will want back...[03:05:27] <Nihility> since its a form post it probably will be in an iframe[03:05:54] <Nihility> so my guess is that it would want something it can access on a frame[03:06:02] <Nihility> perhaps using dom[03:06:05] <jpearlin1> I assume though that they will want to do something ajax-y to update the page to show that the upload/deployment was a success[03:06:11] <Nihility> or maybe there is a way to use json that way[03:06:29] <jpearlin1> I'm confused...are you talking about the request or the response?[03:06:34] <Nihility> response[03:06:48] <Nihility> i mean that the thing issueing the request has to be a form[03:06:54] <jpearlin1> ok...I guess it doesn't really matter right now, we can always change it[03:06:56] <jpearlin1> right...[03:07:05] <Nihility> so that means its got to be html sitting somewhere[03:07:06] <jpearlin1> but it could be something ajax-y that does a async post[03:07:20] <jpearlin1> and wants just json back to update the page to show success or failure...[03:07:33] <Nihility> well thats just it you cant use XmlHttpRequest[03:07:34] <jpearlin1> or it could navigate to a whole new page in a more traditional manor[03:07:35] <Nihility> to send a file[03:07:48] *** AndyTaylor has joined #jboss-as7[03:07:49] *** ChanServ sets mode: +v AndyTaylor[03:07:52] <Nihility> well not portably anyway[03:08:01] *** AndyTaylor has left #jboss-as7[03:08:04] <jpearlin1> right...I was going to say that you can...but it involves frameworks[03:08:18] <Nihility> mozilla has a special feature[03:08:29] <Nihility> nsFileUpload or something[03:08:38] <jpearlin1> ok...so I guess I should just leave it as is for now (returning the DMR response)?[03:08:56] <jpearlin1> until we know more about the caller[03:09:20] <Nihility> yeah if they wanted to be fancy[03:09:28] <Nihility> they would have the upload be in an iframe[03:09:34] <Nihility> and use ajax to poll the server[03:09:38] <Nihility> and to a progress bar[03:09:53] <Nihility> (that would require something on the server side to do that)[03:10:05] <jpearlin1> every time we open that can of worms at work it ends in tears (polling the progress of a file uploaded via http)[03:10:43] <Nihility> too much network traffic[03:10:44] <Nihility> ?[03:10:57] <jpearlin1> no...its more to do with the fact that you don't really know the size of the file being uploaded[03:11:11] <jpearlin1> or at least there is no easy way to tell unless you do some calculations client side first[03:11:16] <jpearlin1> to give real meaningful progress[03:11:34] <jpearlin1> because you don't get it in chunks on the server side via a form post[03:11:55] <Nihility> yeah if it uses http chunking you wont know for sure[03:12:00] <jpearlin1> right[03:12:05] <jpearlin1> so you can guess[03:12:08] <Nihility> if it sends a content length you do know[03:12:12] <jpearlin1> but it looks weird on small files, etc[03:12:31] <jpearlin1> 0%, 1%, 100%![03:12:34] <Nihility> haha[03:12:39] <jpearlin1> just like windows[03:12:48] <dmlloyd> ok now I'm getting somewhere...[03:12:52] <dmlloyd> it's failing right away :)[03:12:57] <dmlloyd> adn the bindings are at least all there[03:12:58] <Nihility> i wonder how gmail does it[03:13:03] <jpearlin1> javascript[03:13:06] <jpearlin1> lots and lots of javascript[03:13:20] <Nihility> yeah they have the same restrictions on sending though[03:13:31] <jpearlin1> right...but I think they do a lot of stuff client side[03:13:36] <jpearlin1> try logging out before the file is attached[03:13:46] <jpearlin1> you will get a popup warning you it hasnt completed yet[03:14:02] <jpearlin1> so they must break it up into chunks client side[03:14:05] <jpearlin1> or something like that[03:14:24] <jpearlin1> and async push a chunk at a time to store on the server until you hit send[03:14:26] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/ebc63f1[03:14:27] <jbossbot> git [jboss-as] ebc63f1.. David M. Lloyd Almost there[03:14:28] <Nihility> yeah the big problem is you cant access files w ith javascript[03:14:36] <dmlloyd> stuartdouglas: ^^ take note! I have pushed![03:14:44] * dmlloyd waves a couple flags in the air semaphore-style[03:14:47] <jpearlin1> true...hmm[03:15:39] <stuartdouglas> does it work?[03:15:50] <dmlloyd> almost[03:15:56] <dmlloyd> there's a start failure with the binding service[03:16:02] <stuartdouglas> It almost worked before :-)[03:16:07] <dmlloyd> I think it's a dep that needs to be added or something[03:16:14] <dmlloyd> it gets farther than it did![03:17:54] <jpearlin1> Nihility: looks like there are two competing thoughts on how gmail does it: flash or an iframe with ajax[03:18:11] <jpearlin1> or html5 if they detect a newer browser[03:18:53] <stuartdouglas> something screwey is going on: service jboss.naming.context.java.app."managedbean-example.ear".anagedbean-example/BeanWithSimpleInjected[03:19:08] <stuartdouglas> anagedbean is probably not right :-)[03:19:34] <dmlloyd> god dammit[03:19:40] <dmlloyd> one sec[03:20:56] <stuartdouglas> actually that is probably not the problem[03:21:13] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/d4404e1[03:21:13] <jbossbot> git [jboss-as] d4404e1.. David M. Lloyd I CAN DO MATHZ[03:21:33] <dmlloyd> yeah it's *a* problem but not *the* problem[03:24:42] <dmlloyd> wow, I hit something pretty bad this time[03:25:17] <dmlloyd> http://fpaste.org/ZQjc/[03:25:18] <stuartdouglas> that sounds ominous[03:25:47] <stuartdouglas> that looks bad[03:25:51] <dmlloyd> spurious failure[03:25:55] <stuartdouglas> is that a circular dep?[03:26:02] <dmlloyd> I'll have to give this one to flavia to sort out[03:26:12] <dmlloyd> "good news is that it didn't happen again :)[03:26:14] <dmlloyd> "good"[03:28:36] <Nihility> jpearlin1: so it looks like most browsers send content-length on a form post[03:29:26] <Nihility> jpearlin1: you know one trick that might help you at work, is that http 1.0 doesnt support chunking[03:29:51] <stuartdouglas> So now the service name is : jboss.naming.context.java.app."managedbean-example.jar".managedbean-example/SimpleManagedBean:[03:30:01] <stuartdouglas> is that / going to cause problems?[03:30:12] <Nihility> jpearlin1: so you might be able to tell a browser to repost on http/1.0 and then they MUST provide it[03:30:30] <jpearlin1> yeah[03:30:43] <dmlloyd> stuartdouglas: no, that's what it should be[03:30:53] <jpearlin1> I do have one more question...do I need to put anything in the "address" parameter when I call execute on the modelcontroller?[03:30:58] <jpearlin1> right now I just have an empty list[03:31:02] <dmlloyd> stuartdouglas: this is weird though, it didn't bind the VIEW service this time[03:31:06] <dmlloyd> but I swear it did last time[03:31:08] <Nihility> jpearlin1: it depends on the operation[03:31:17] <jpearlin1> the upload doesn't seem to care about it[03:31:27] <jpearlin1> and the empty list allows it to pass the validation[03:31:31] <Nihility> jpearlin1: an empty list refers to the "root" node[03:31:36] <jpearlin1> the upload handler only cares about the "url" param for its validation[03:32:01] <Nihility> the upload operation is likely on the root node[03:32:06] <jpearlin1> it is[03:32:08] <Nihility> erm add to repo[03:32:09] <jpearlin1> from what I can tell[03:33:12] <bstansberry> an empty address is fine[03:33:19] <jpearlin1> thanks[03:33:22] <bstansberry> the handler is on the root node[03:33:32] <jpearlin1> that's what it looked like, but I wanted to make sure[03:33:49] <stuartdouglas> dmlloyd: Are you talking about Service "jboss.deployment.unit."managedbean-example.ear"."managedbean-example.jar".component.BeanWithSimpleInjected.VIEW ?[03:33:49] <jpearlin1> I pulled out the name and display name fields (as well as the validation on those)...is that still okay?[03:33:53] <stuartdouglas> cause that is up for me[03:34:35] <dmlloyd> stuartdouglas: just restarted and it bound the view this time[03:34:43] <dmlloyd> that's about 8 different kinds of "not good"[03:35:18] <bstansberry> jpearlin1: that's fine[03:35:22] <jpearlin1> thanks[03:35:35] <stuartdouglas> hang on[03:35:46] <stuartdouglas> jboss.naming.context.java.app."managedbean-example.jar"[03:35:57] <stuartdouglas> that should probably be .ear rather than .jar[03:36:14] <dmlloyd> maybe but that doesn't explain what's going on here[03:36:15] <bstansberry> jpearlin1: fyi, kkhan added an ability to attach streams to operations, and an upload handler that can access the stream[03:36:19] <bstansberry> https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentUploadStreamAttachmentHandler.java[03:36:21] <dmlloyd> this time I got all services installed correctly[03:36:25] <bstansberry> that's the handler[03:36:28] <dmlloyd> except an ISE on the MB service start[03:36:31] <jpearlin1> should we use that instead?[03:36:38] <jpearlin1> right now, I am just passing the url to the file[03:36:43] <jpearlin1> the temp file that is[03:36:52] <dmlloyd> an injection which wasn't started yet[03:37:23] <bstansberry> it would be interesting to try, if it allows you to skip the temp file[03:37:58] <stuartdouglas> actually I am seeing the same now[03:38:21] <jpearlin1> bstansberry: it would, but I think Nihility wants to avoid holding all of the deployment in memory if possible[03:39:06] <bstansberry> it wouldn't all be in memory[03:39:58] <bstansberry> well, TBH, it would now, but that's just because the impl is as simple as possible until we change out the client/server transport to JBoss Remoting 3[03:40:17] <stuartdouglas> dmlloyd: line 167 of ComponentInstallProcessor, I think resourceValue is not being set[03:40:23] <bstansberry> so maybe sticking with the URL for now makes sense, until that change happens[03:40:31] <jpearlin1> yeah...looking at that code it is just a straight call to the input stream to read the data[03:40:39] <stuartdouglas> as it is the first injection that is failing, and that is the first injection[03:40:41] <jpearlin1> yeah...it wouldn't be much to change on my end[03:41:14] <jpearlin1> thanks for your help[03:41:24] <dmlloyd> stuartdouglas: it must be set to something[03:41:31] <dmlloyd> otherwise there'd be an IlArgEx[03:41:35] <Nihility> there would be some slight complexity in doing tha tin the current server[03:41:47] <Nihility> the webserver is blocking i/o[03:41:48] <bstansberry> jpearlin1: fyi, in https://github.com/jbossas/jboss-as/tree/master/controller-client/src/main/java/org/jboss/as/controller/client[03:41:55] <dmlloyd> brb[03:41:58] <Nihility> and i assume the operation that takes a stream is as well[03:42:00] <stuartdouglas> It is an InjectedValue[03:42:11] <stuartdouglas> but I don't think the injected value is ever set[03:42:14] <Nihility> so you would have to do something like pipedinputstream[03:42:24] <Nihility> and kick off a thread to copy the data[03:42:28] <jpearlin1> yeah...that is what I thought[03:42:35] <jpearlin1> and that could get interesting[03:42:40] <bstansberry> ModelControllerClient has a new method, and ExecutionContentBuilder is how you create the ExecutionContext[03:43:26] <Nihility> hmmm[03:43:28] <Nihility> unless[03:43:41] <bstansberry> remoting will read the stream[03:43:55] <Nihility> you could just pass the http input stream straight to the operation[03:44:02] <jpearlin1> right[03:44:03] <bstansberry> yeah[03:44:06] <Nihility> duh[03:44:17] <jpearlin1> but...its multipart[03:44:30] <jpearlin1> so you would need to get the body or change the upload handler to parse multipart[03:44:34] <jpearlin1> to get the deployment[03:44:36] <Nihility> right so you would have to have a mutlipart decoder stream[03:44:53] <jpearlin1> right...wrap the input stream in a multipart stream[03:45:11] <jpearlin1> but most of the ones I see want you to do separate calls to get the header and body per part[03:45:13] <Nihility> thats that thing i wrote long long ago[03:45:18] <jpearlin1> so we would need one that doesn it in one call[03:45:26] <jpearlin1> i.e. read()[03:45:38] *** pgier has quit IRC[03:45:45] <jpearlin1> in a galaxy far, far away?[03:47:12] <jpearlin1> Nihility: should I do separate commits, one for the changes to the deployment handler to remove those now unused paramters and one for the upload stuff, or can it be just one commit?[03:50:01] <Nihility> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossws/stack/native/trunk/modules/core/src/main/java/org/jboss/ws/core/soap/attachment/BoundaryDelimitedInputStream.java?view=log[03:50:15] <jpearlin1> nice[03:53:31] <jpearlin1> so, should I commit what I have, then try to switch to using the stream handler?[03:53:42] <jpearlin1> or create a separate branch, I suppose[03:54:42] <dmlloyd> stuartdouglas: yeah almost like the dependency isn't injected[03:54:48] <dmlloyd> I think it is the VIEW dep[03:54:53] <stuartdouglas> https://github.com/stuartwdouglas/jboss-as/commit/9d8c116456c49de865bdea5695588ac875b38a1e[03:54:53] <jbossbot> git [jboss-as] 9d8c116.. Stuart Douglas TEMP HACK[03:55:04] <bstansberry> IMO, let's see what you have[03:55:07] <stuartdouglas> I did that, and now I get a completly different failure[03:55:32] <stuartdouglas> http://pastebin.com/7Ww5tDwu[03:55:37] <dmlloyd> so basically you add the same dep again[03:56:03] <bstansberry> "All read() methods will start from the first inner stream, returning -1 when a boundary is reached. Subsequent calls will then advance to the next stream, skipping the boundary. "[03:56:26] <stuartdouglas> actually yea[03:56:33] <stuartdouglas> I totally misread what was going on there[03:57:20] <bstansberry> so that would be an issue with how the ModelControllerClient API works; the client attaches 0..n streams and then they get read in arbitary order[03:58:02] <Nihility> ugh[03:58:10] <Nihility> that last patch that was made to this file[03:58:12] <Nihility> is wrong[03:59:39] <dmlloyd> stuartdouglas: maybe the problem is in addInjectionValue[04:00:05] <Nihility> jpearlin1: so if you use that, take the revision BEFORE the most recent[04:00:26] <jpearlin1> well...it sounds like it may not jive with the model controller api[04:00:40] <stuartdouglas> could well be[04:01:11] <stuartdouglas> yea, I think it is[04:01:25] <stuartdouglas> I change my temp hack so I only add the dep once[04:02:10] <stuartdouglas> https://github.com/stuartwdouglas/jboss-as/commit/f925e6ce9bafac1364eeee33a6d5f6fa6804d926[04:02:11] <jbossbot> git [jboss-as] f925e6c.. Stuart Douglas TEMP HACK2[04:02:19] <stuartdouglas> and I was still getting the same failure as before[04:02:28] <stuartdouglas> with the already bound stuff[04:06:18] <Nihility> jpearlin1:bstansberry: yeah we would need something specific to http which isnt that great[04:06:46] <jpearlin1> and are we really that concerned with the delay of writing the temp file for this?[04:06:55] <Nihility> not really[04:07:05] <jpearlin1> right...that would be my thought too[04:07:16] <jpearlin1> it might be cool to pipe it through, but we don't need racing stripes on this[04:07:29] <bstansberry> if we could skip it, it's just nicer because there's less stuff left around[04:07:36] <bstansberry> but it's not a big deal by any means[04:07:41] <dmlloyd> stuartdouglas: this doesn't make any sense, fyi[04:07:44] <Nihility> yeah its easier from a cleanup and resource management perspective[04:07:48] <stuartdouglas> I know[04:07:49] <Nihility> also if there is a problem[04:07:54] <jpearlin1> right, but I don't think the cleanup will be that big of a deal[04:07:55] <Nihility> the server can abort[04:07:56] <Nihility> faster[04:08:04] <dmlloyd> stuartdouglas: the exact same dep you add is also added in side the resource value method[04:08:11] <stuartdouglas> I know[04:08:28] <dmlloyd> these injectors shouldn't even be running until the service is up[04:08:59] <Nihility> we would need a special sequential nested stream type[04:09:04] <Nihility> one with a friendlier api[04:09:05] <Nihility> :)[04:09:13] <Nihility> but that can be done later[04:09:17] <jpearlin1> we could probably cheat a little[04:09:18] *** pferraro has joined #jboss-as7[04:09:18] *** ChanServ sets mode: +v pferraro[04:11:38] <Nihility> dmlloyd: see 4.4.1 in the ejb spe[04:13:22] <Nihility> so at leatst all ejbs need entries in app, global, and module[04:13:50] <Nihility> mbs require module and app[04:14:33] <jpearlin1> Nihility, bstansberry: thanks for your help...I'll get this cleaned up and get you a patch later this week[04:14:56] <bstansberry> great; thanks for doing this![04:14:59] <Nihility> thanks[04:15:00] <jpearlin1> no problem[04:15:06] <jpearlin1> glad that I can help[04:16:24] *** Nihility has quit IRC[04:18:03] *** jpearlin1 has quit IRC[04:18:43] *** stansilvert has quit IRC[04:22:58] <dmlloyd> hm I have an idea to make this problem go away[04:24:09] *** Nihility has joined #jboss-as7[04:24:09] *** Nihility has joined #jboss-as7[04:24:09] *** ChanServ sets mode: +v Nihility[04:24:49] <dmlloyd> yes! brilliant[04:25:36] <Nihility> did you add support for circular deps!!![04:25:37] <Nihility> :)[04:25:54] <dmlloyd> no, I'm quite close to a clever solution to my immediate problem though[04:27:45] <stuartdouglas> dmlloyd: I think it may be a MSC bug[04:28:23] <stuartdouglas> MSC is attempting to use the value injection before it runs the corresponding dependency type injection[04:28:33] <stuartdouglas> hmm, that last sentence made no sense[04:29:04] <stuartdouglas> basically the injection created with addInjectionValue is attempted first[04:29:18] <stuartdouglas> before the injection created by addDependency()[04:29:24] <stuartdouglas> so the value is null[04:29:35] <stuartdouglas> and we get an IllegalStateException[04:29:55] <dmlloyd> I thought it was something like that....[04:30:07] <stuartdouglas> do you want me to fix it?[04:30:09] <dmlloyd> sure[04:30:20] <dmlloyd> I worked around it by passing an injector in to the resource value thing instead of returning a value[04:30:29] <dmlloyd> it's actually kinda better because it cuts out a "middleman" in the process[04:30:51] <dmlloyd> now I've got Caused by: javax.naming.NameAlreadyBoundException: java:app[04:31:05] <stuartdouglas> yea, that is where I got with my hack[04:31:35] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/a8a090c[04:31:35] <jbossbot> git [jboss-as] a8a090c.. David M. Lloyd FIX-UM INJECTOR[04:32:32] <dmlloyd> 21:28:39,846 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) Completed deployment of "managedbean-mbean.sar" in 274 ms[04:32:32] <dmlloyd> 21:28:39,849 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Completed deployment of "managedbean-example.jar" in 277 ms[04:32:32] <dmlloyd> 21:28:39,850 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Completed deployment of "managedbean-example.ear" in 352 ms[04:32:38] <dmlloyd> I'm glad the timings work[04:32:40] <dmlloyd> at least :)[04:33:31] <dmlloyd> weird that it complains about java:app with java:app/managedbean-example/BeanWithSimpleInjected[04:33:37] <dmlloyd> must be a bug in BinderService...[04:38:07] <Nihility> david do you do something cool with modules and logging[04:38:17] <Nihility> and exceptions[04:38:32] <dmlloyd> everything I do is cool[04:38:34] <dmlloyd> you know that[04:38:36] <Nihility> the jar is the right of each line[04:38:42] <Nihility> i just noticed that[04:38:48] <dmlloyd> oh yeah, that was in jboss-logmanager[04:38:49] <dmlloyd> a while back[04:39:01] <dmlloyd> that's in AS6 too[04:39:03] <Nihility> thats a totally awesome feature[04:39:20] <dmlloyd> it uses code sources and a bunch of really nasty hacks to figure out the JAR[04:39:39] <dmlloyd> I added mainly because log4j had it and people were bitching :)[04:44:32] <dmlloyd> man the naming store API is a bit broken[04:44:48] <dmlloyd> not sure why it does everything in terms of contexts[04:44:58] <stuartdouglas> I try and aviod working with it where possible :-)[04:45:18] <Nihility> visitor pattern[04:45:28] <dmlloyd> ideally on the binding side you'd just say bind(name, thingThatIsNotAContext[04:45:34] <dmlloyd> and that's it[04:45:48] <dmlloyd> guess I'll fix that because it's actually breaking this thing[04:46:51] <stuartdouglas> dmlloyd: can you pull https://github.com/stuartwdouglas/jboss-msc[04:47:07] <stuartdouglas> I just changed the order so dependecy based injections go first[04:47:43] <dmlloyd> okay[04:47:45] <Nihility> stuartdouglas: so how much work do you think integrating weld requires[04:48:35] <stuartdouglas> It is already mostly integrated[04:48:44] <stuartdouglas> the only two major outstanding things are EJB integration[04:48:51] <stuartdouglas> and CDI injections into other components[04:48:58] <stuartdouglas> which may get done today[04:49:04] *** smarlow has quit IRC[04:49:38] <stuartdouglas> the TCK currently passes around 80%[04:50:03] <stuartdouglas> and a good number of those are failing because the TCK uses JSF 1.2 and we have JSF 2[04:50:15] <dmlloyd> heh[04:50:58] <stuartdouglas> CDI injection was supposed to be done by now, but then the managed bean demo came along :-)[04:51:18] * dmlloyd bows[04:52:03] <stuartdouglas> There are a few other performance things I would like to do, like muti threaded startup[04:52:45] <stuartdouglas> but a lot of the idea's that were proposed aren't really practical or don't actually buy much[04:54:43] <stuartdouglas> for instance WELD-793, which basically wants the container to provide all the reflection info to weld[04:54:44] <jbossbot> jira [WELD-793] Make bootstrap more granular [Open (Unresolved) Feature Request, Blocker, Unassigned] https://issues.jboss.org/browse/WELD-793[04:55:20] <stuartdouglas> however the container only builds reflection info for a small number of classes, while weld needs reflection info for all of them[04:55:36] <stuartdouglas> so it would really do is waste more memory by blowing out our reflection cache[04:57:59] *** mbg|away is now known as mbg[04:58:47] <Nihility> yeah i figured weld is going to have to be its own animal[04:59:27] <Nihility> although perhaps the annotation index would be useful[04:59:44] <Nihility> if you have no extensions or something[05:00:22] <stuartdouglas> yea, but then you have two completly different code paths[05:01:24] <stuartdouglas> At the moment it takes around 1s per 1000 classes[05:02:17] <stuartdouglas> and if we go to a multi threaded boot I should be able to reduce that by at least 30%[05:05:47] <stuartdouglas> we will probably need another release of weld soon though, as there are some fairly major bugs in 1.1 final, e.g. deployment time is O(n!) on the number of bean archives[05:06:58] *** bstansberry has quit IRC[05:21:34] * dmlloyd having a tough time wedging into InMemoryNamingStore[05:21:43] <dmlloyd> I'm kinda considering gutting it a bit[05:21:54] <dmlloyd> since we don't need support for most JNDI things... I don't think...[05:22:04] <dmlloyd> if we make Contexts read-only[05:22:29] <stuartdouglas> there are no parts of the TCK that require writable contexts?[05:22:42] <dmlloyd> I don't know, tbh[05:23:11] <dmlloyd> but it would definitely fuck up dependencies if they did write into contexts[05:24:14] <dmlloyd> the hornetq thing is already gonna break some stuff, it's like that on the promise that they're gonna fix it asap[05:24:37] <dmlloyd> the last thing I need is to bite off another refactor though :([05:25:01] <stuartdouglas> did you figure out what was going on with the managed beans demo?[05:25:25] <dmlloyd> yeah it's trying to create parent contexts which already were created by another service[05:25:41] <dmlloyd> the problem is that we even have a service for creating contexts at all, imo[05:26:16] <stuartdouglas> so we should just tell the naming store 'bind here', and it takes care of the rest?[05:26:35] <dmlloyd> that's what I think[05:26:44] <dmlloyd> now making InMemoryNamingStore actually do that is another matter[05:26:52] <stuartdouglas> that sounds a lot better to me[05:27:18] <dmlloyd> the only tricky part is that we have the three contexts, comp module and app, which have to be referency[05:27:56] <stuartdouglas> isn't that just a case of binding a Reference to a Context ?[05:28:34] <dmlloyd> yeah, but it just means that we've got three kinds of things: references, contexts, and jndiinjectables[05:28:35] <stuartdouglas> would that really have to change much from how we do it now?[05:28:47] <dmlloyd> not too much no[05:28:56] <dmlloyd> the problem is that how we do it now is really hard to wedge into[05:40:26] <dmlloyd> hot damn[05:40:26] <dmlloyd> it works[05:40:29] <dmlloyd> IT WORKS[05:40:36] <dmlloyd> __________[05:40:36] <dmlloyd> < IT WORKS >[05:40:36] <dmlloyd> ----------[05:40:36] <dmlloyd> \ ^__^[05:40:36] <dmlloyd> \ (oo)\_______[05:40:36] <dmlloyd> (__)\ )\/\[05:40:38] <dmlloyd> ||----w |[05:40:40] <dmlloyd> || ||[05:40:51] <stuartdouglas> woho :-)[05:40:56] *** irooskov has quit IRC[05:41:41] <stuartdouglas> your cows legs are wonky[05:42:20] <dmlloyd> gotta remove this sleep(60000) someone put in here[05:42:31] <stuartdouglas> hehe[05:42:38] <dmlloyd> :D[05:42:44] <stuartdouglas> It this al coing to be rebased into one big lump?[05:43:02] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/a22f0cb[05:43:03] <jbossbot> git [jboss-as] a22f0cb.. David M. Lloyd Cleanly make some parents in binder service[05:43:04] <dmlloyd> yeah definitely[05:43:10] <dmlloyd> gotta edit out the cussing and whatnot :)[05:43:48] <dmlloyd> looks like unbind isn't working for some reason[05:43:51] <dmlloyd> pooey[05:44:06] <dmlloyd> doing a clean rebuild though because I'm all bit-rotten[05:44:30] <Nihility> speaking of works[05:44:44] <Nihility> my patched xalan and the new redirection stuff solves stans issue[05:45:03] <Nihility> although funny thing i noticed is that we already have a version of xalan in our tree[05:45:11] <Nihility> and its brew-path01[05:45:14] <Nihility> patch[05:45:14] <dmlloyd> heh[05:45:16] <Nihility> lol[05:45:19] <dmlloyd> better look into that :)[05:45:27] <Nihility> yeah wonder what that patch does[05:45:45] <Nihility> its like a) wtf is using xalan[05:45:52] <Nihility> b) why is it a brew jar[05:46:00] <Nihility> c) what is the patch[05:46:04] <Nihility> d) who am i?[05:46:14] <dmlloyd> yeah[05:46:17] <dmlloyd> makes you wonder[05:47:26] <dmlloyd> ah changing that "bean" field to private broke smoke-tests[05:47:26] <Nihility> 5b61a544 (Richard Opalka 2011-02-21 09:54:01 +0100 79) <version.org.apache.xalan>2.7.1.patch01-brew</version.org.apache.xalan>[05:47:26] <dmlloyd> :([05:47:42] <stuartdouglas> need to use getBean instead[05:47:48] <stuartdouglas> cause it waits[05:47:57] <stuartdouglas> but we probably should add a timeout to the wait[05:47:59] <dmlloyd> org.jboss.as.test.embedded.demos.managedbean.ManagedBeanTestCase no longer compiles[05:48:19] <dmlloyd> heh[05:48:20] <dmlloyd> it polls[05:48:26] <dmlloyd> ugggly[05:48:38] <stuartdouglas> no need for that now[05:48:44] <dmlloyd> easy fix at least[05:48:57] <stuartdouglas> I can build in around 55s now that all the sleeps() are gone from the tests[05:50:02] <dmlloyd> damn I'm getting the failures again[05:50:02] <dmlloyd> wtf[05:50:56] <dmlloyd> it's almost like there's some kind of race condition[05:50:57] <dmlloyd> hmmm[05:51:02] <dmlloyd> I bet I know right where it is[05:55:29] <Nihility> http://anonsvn.jboss.org/repos/repository.jboss.org/apache-xalan/2.7.1.patch04-brew/src/[05:55:53] <dmlloyd> doesn't seem to fail now[05:55:55] <Nihility> add some sleeps[05:55:59] <dmlloyd> but the test isn't finishing either[05:57:27] <dmlloyd> 22:54:38,132 WARN [org.jboss.msc.inject] (MSC service thread 1-3) MSC00100:Unexpected failure to uninject public void org.jboss.as.demos.sar.archive.ConfigService.setIntervalSeconds(int): java.lang.IllegalArgumentException[05:57:30] <dmlloyd> not sure what that's about[05:58:23] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/9109f77[05:58:23] <jbossbot> git [jboss-as] 9109f77.. David M. Lloyd Fix race and compile prob; test still does not finish, no idea why[05:58:27] <dmlloyd> what do you make of that, stuartdouglas[05:59:10] * stuartdouglas looks[05:59:48] <dmlloyd> it really looks like the deployment runs correctly[05:59:54] <dmlloyd> but the bean isn't unblocking for some reason[06:00:09] <dmlloyd> otoh it is only deploying managedbean-example.jar, not the whole ear[06:01:08] <stuartdouglas> that would probably do it[06:03:29] <dmlloyd> I'll try copying the code from demos[06:03:48] <stuartdouglas> yea, it just builds an arquillian archive[06:04:20] <stuartdouglas> but you will also need to add the test class itself to the jar[06:04:40] <dmlloyd> yeah just noticing that[06:06:10] <dmlloyd> here goes[06:06:18] <dmlloyd> first ever experience with arq[06:06:55] <dmlloyd> seemed to deploy, weeew[06:07:02] <dmlloyd> test still isn't finishing tho[06:07:34] <stuartdouglas> can you push[06:08:14] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/20c3a2b[06:08:14] <jbossbot> git [jboss-as] 20c3a2b.. David M. Lloyd ShrinkWrap em[06:09:46] <stuartdouglas> I wonder if it is not bundling META-INF/services/org.jboss.msc.service.ServiceActivator[06:10:15] <stuartdouglas> actually no, that should be fine[06:10:31] <Nihility> dmlloyd: tommorow we should do a modules release :)[06:10:56] <Nihility> need to get it to beta20[06:11:52] <stuartdouglas> It is blocking in lookupservice.getBean[06:11:55] <dmlloyd> http://fpaste.org/iVZH/[06:13:18] <stuartdouglas> the demo blocks as well when run standalone[06:13:32] <dmlloyd> Service "jboss.deployment.unit."managedbean-example.ear"."managedbean-example.jar".component.BeanWithSimpleInjected.START" (class org.jboss.as.ee.component.ComponentStartService) mode ACTIVE state DOWN (parent: jboss.deployment.unit."managedbean-example.ear"."managedbean-example.jar".INSTALL) (dependencies: jboss.naming.context.java.app."managedbean-example.ear".managedbean-example/BeanWithSimpleInjected, jboss.naming.conte[06:13:33] <dmlloyd> xt.java.module."managedbean-example.ear"."managedbean-example.jar"."env/org.jboss.as.demos.managedbean.archive.BeanWithSimpleInjected/simple", jboss.naming.context.java.module."managedbean-example.ear"."managedbean-example.jar".BeanWithSimpleInjected, jboss.deployment.unit."managedbean-example.ear"."managedbean-example.jar".component.BeanWithSimpleInjected.CREATE) (has missing dependency)[06:15:25] <stuartdouglas> we need a better way of viewing missing dependencies...[06:16:24] <Nihility> cool the service tracking stuff works though[06:16:51] *** ALR has quit IRC[06:18:44] <stuartdouglas> jboss.naming.context.java.module."managedbean-example.ear"."managedbean-example.jar"."env/org.jboss.as.demos.managedbean.archive.BeanWithSimpleInjected/simple" is the missing dep[06:18:51] <stuartdouglas> it has another missing dep though[06:19:19] <stuartdouglas> jboss.naming.context.java.module."managedbean-example.ear"."managedbean-example.jar".module.SimpleManagedBean[06:19:27] <stuartdouglas> Is the root cause[06:20:53] <stuartdouglas> I think that extra module at the end may be wrong[06:21:13] <dmlloyd> yeah[06:21:15] <dmlloyd> that's the one[06:21:27] <dmlloyd> just gotta figure out where the hell I did that...[06:26:31] <dmlloyd> @Resource(lookup="java:module/SimpleManagedBean") is on the original[06:26:36] <dmlloyd> I must be assembling the name wrong somewhere[06:27:29] *** mbg is now known as mbg|away[06:28:04] <dmlloyd> ah found it[06:28:48] *** mbg|away is now known as mbg[06:30:20] <dmlloyd> Running org.jboss.as.test.embedded.demos.managedbean.ManagedBeanTestCase[06:30:20] <dmlloyd> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.345 sec <<< FAILURE![06:30:25] <dmlloyd> I'm so glad to see a failure :)[06:30:59] <dmlloyd> hm it's that goofy MSC race again...[06:36:23] <dmlloyd> ah now LookupService is not having the context injected...[06:46:55] <dmlloyd> got something stale here[06:47:00] <dmlloyd> time to nuke and rebuild[06:50:49] <dmlloyd> System using 52.00999999999999 Mb of 151.19 Mb after 0 seconds[06:50:49] <dmlloyd> lol[06:50:53] <dmlloyd> just under one byte used there[06:52:00] <stuartdouglas> ?[06:52:15] <dmlloyd> it's a diagnostic I noticed[06:52:33] <dmlloyd> that'd be 52009999.99999999 bytes[06:52:59] <dmlloyd> not quite sure what it's gonna do with .99999999 of a byte, but oh well[06:56:07] <dmlloyd> hmm[06:56:15] <dmlloyd> I don't think the binding is actually making it into JNDI[06:56:24] <dmlloyd> the service is definitely there[06:56:50] <stuartdouglas> A problem with the naming store?[06:56:58] <dmlloyd> could be[06:57:06] <dmlloyd> I might have to attach a debugger to figure this out[06:57:10] <dmlloyd> blarg[06:57:34] <dmlloyd> the services are all there, nothing missing deps[06:57:40] <dmlloyd> I see the service for the binding[06:57:47] <stuartdouglas> but the lookup fails?[06:57:55] <dmlloyd> yeah apparently[06:58:00] <stuartdouglas> I may have cdi injections[06:58:00] <dmlloyd> though the lookup is pretty suspect itself[06:58:12] <stuartdouglas> but I can't test them till we sort this out[06:58:24] <dmlloyd> had to hack org.jboss.as.demos.managedbean.archive.ServiceActivator because the context service is a NamingStore now[06:58:30] <dmlloyd> so I made a little bridge thinger[06:58:43] <dmlloyd> http://fpaste.org/FmsG/[06:58:51] <dmlloyd> I'm not super confident[06:58:57] <dmlloyd> that it's right, that is[06:59:12] <dmlloyd> I do see Service "jboss.naming.context.java.module."managedbean-example.ear"."managedbean-example.jar".BeanWithSimpleInjected"[06:59:25] <stuartdouglas> hmm, can't we just do a normal JNDI lookup now?[06:59:37] <stuartdouglas> as they are all part of the same app[06:59:38] <dmlloyd> hm, of the app one you mean?[06:59:45] <stuartdouglas> yea[06:59:49] <dmlloyd> in theory but service activators don't have a naming context[06:59:56] <stuartdouglas> ah[06:59:58] <dmlloyd> so you can't get the inital context[07:00:08] <stuartdouglas> but in practice arquillian sets one up[07:00:09] <dmlloyd> another thing to fix I guess[07:00:25] <dmlloyd> really? how does it do that[07:00:56] <dmlloyd> no naming context selector even exists[07:01:06] <dmlloyd> so theoretically I guess this shouldn't even work :)[07:01:09] <stuartdouglas> oh, well then it probably doesn't[07:01:34] <dmlloyd> I guess it's not doing lookups with the calling context[07:01:48] <dmlloyd> man, what a pain in the ass this is[07:02:10] <stuartdouglas> Actually I think arq will have the namespace set up[07:02:35] <stuartdouglas> https://github.com/bstansberry/jboss-as/blob/master/ee/src/main/java/org/jboss/as/ee/naming/ModuleContextProcessor.java#L96[07:02:55] <stuartdouglas> idea's github integration thinks I am brian for some reason[07:02:59] <dmlloyd> ah, cute[07:03:09] <dmlloyd> too bad the module context services aren't Context for some reason[07:03:15] <dmlloyd> er[07:03:19] <dmlloyd> nice freudian there[07:03:30] <dmlloyd> read+type = I/O error[07:03:48] <dmlloyd> too bad the module context services aren't Context anymore*[07:04:04] <stuartdouglas> that file is out of date[07:04:17] <stuartdouglas> cause idea thought I was brian[07:04:26] <dmlloyd> https://github.com/dmlloyd/jboss-as/blob/master/ee/src/main/java/org/jboss/as/ee/naming/ModuleContextProcessor.java#L91[07:04:27] <dmlloyd> :-([07:06:05] <stuartdouglas> ah, I was looking in my cdi injectors branch, which is between those two[07:06:11] <stuartdouglas> as I have not rebased it yet[07:07:20] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/5deec7f[07:07:20] <jbossbot> git [jboss-as] 5deec7f.. David M. Lloyd Fix some lookup stuff[07:07:24] <dmlloyd> this is my current state[07:08:27] <maeste> dmlloyd, stuartdouglas : have you an answer about org.jboss.as.server.deployment.Attachments#CLASS_PATH_ENTRIES?[07:08:50] <stuartdouglas> yes[07:08:51] <dmlloyd> I don't even rememner the question[07:08:58] <dmlloyd> been working for 15 hours[07:09:02] <stuartdouglas> we do add msc dependencies[07:09:08] <stuartdouglas> only 10 here[07:09:44] <stuartdouglas> all non-system modules are represented by two MSC sevices, a config service and a load service[07:09:50] <maeste> dmlloyd: yep, you are right...you asked <dmlloyd> stuartdouglas: when you're back on... when we add class-path entries are we also adding a MSC dependency?[07:10:12] <dmlloyd> ah for the two phases[07:10:13] <stuartdouglas> so when you add a class path entry to something[07:10:14] <dmlloyd> good deal[07:10:33] <stuartdouglas> it turns it into a module with those two services[07:11:05] <stuartdouglas> but if you point the class path entry and something in ear/lib this does not happen, as it is already on the CP and it is ignored[07:11:18] <maeste> stuartdouglas, dmlloyd : cool, so I can do that to add jdbc driver to my classpath for jca[07:11:57] <stuartdouglas> where is the driver deployed and where is the jar that is referencing it?[07:12:10] <maeste> stuartdouglas: a bit of context for you: I have a jdbc driver deployed as jar and a rar that want to use it[07:12:27] <maeste> stuartdouglas: I have a service dependency, but I need to put the drivere in cp too[07:13:25] <stuartdouglas> if is is deployed you are better off using extension-list or a jboss modules dep[07:13:28] <maeste> stuartdouglas: in fact I set up that service started in rar is dependending from driver's service[07:14:10] <maeste> stuartdouglas: why? (asking to have deeper understand)[07:14:11] <stuartdouglas> the class-path service will actually be different to the drivers normal module service[07:14:31] <stuartdouglas> as it is outside the deployment it will be treated as an external jar[07:15:02] <stuartdouglas> at the moment there is no good solution to this, as there is no guarentee which one will be deployed first[07:15:29] <maeste> stuartdouglas: oki, have you an example to point me too?[07:15:46] <stuartdouglas> not really :-([07:16:00] <stuartdouglas> so you can use extension-list, but extension-list determines the service name to depend on by looking through the available deployed extensions[07:16:14] <stuartdouglas> so it won't help if the deployment order is wrong[07:16:21] <maeste> stuartdouglas: yep, but having set a service dependency I don't know who is deployed first, but I know who is started first at least[07:16:28] <dmlloyd> well if you have a dep on the driver service and on the module via class path it's probably fine[07:16:30] <maeste> stuartdouglas: does it help?[07:17:24] <stuartdouglas> the problem is that class path does not work that way yet, it only know about cp entries that are inside the deployment, and external cp entries[07:17:39] <dmlloyd> oh it doesn't know about sibling deployments?[07:17:40] <stuartdouglas> it does not (yet) know about cp entries that are outside this deployment and in another deployment[07:18:08] <stuartdouglas> when I implemented it the module as service stuff was not really in place[07:18:08] <dmlloyd> hm[07:18:15] <stuartdouglas> it would actually be pretty easy to do now[07:18:45] <maeste> so it doesn't (yet) possible to implement what I've discussed with dmlloyd yesterday[07:19:06] <stuartdouglas> it will be if I make CP understand sibling deployments[07:19:28] <maeste> exactly it's the sense of "yet" :P[07:21:40] <maeste> stuartdouglas: have you an estimate about that? Without it the current JCA+jdbc deployement impl does not work witout cp workaround (setting in cp in client for example using META-INF Class-Path entry)[07:21:50] <stuartdouglas> give me 10 mintues[07:21:56] <maeste> sure[07:21:58] <stuartdouglas> and I will let you know[07:22:30] <maeste> np, it's just 6 O'clock here...I have all day :)[07:29:43] <dmlloyd> ah I guess I did already fix the selector stuff[07:29:55] <stuartdouglas> https://github.com/stuartwdouglas/jboss-as/commit/41a4f8611e18202410c85d89733edcee0b50e7fd[07:29:56] <jbossbot> git [jboss-as] 41a4f86.. Stuart Douglas Allow CP entries to point to top level deployments[07:30:00] <stuartdouglas> That may fix it[07:32:06] <stuartdouglas> dmlloyd: if you get a sec could you push my master to upstream master[07:33:06] <jbossbot> git [jboss-as] push master 41a4f86.. Stuart Douglas Allow CP entries to point to top level deployments[07:33:06] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/26d15df...41a4f86[07:33:24] <stuartdouglas> maeste: it should work now[07:33:39] <maeste> stuartdouglas: coooool! Thanks. So Can I just use CLASS_PATH_ENTRIES?[07:33:56] <maeste> stuartdouglas: or there are more proper method you suggest[07:34:02] <stuartdouglas> yea, just put a Class-Path: ../otherjar.jar[07:34:11] <stuartdouglas> and that should work[07:35:06] <maeste> stuartdouglas: cool[07:36:02] <maeste> stuartdouglas: thank you very much[07:36:09] <stuartdouglas> np[07:41:34] <dmlloyd> ah weird[07:41:50] <dmlloyd> some of the names are being bound as java:module/Blah inside the naming store[07:41:52] <dmlloyd> and some are just Blah[07:42:02] <dmlloyd> gotta find out what the difference is[07:51:12] *** miclorb has quit IRC[07:54:06] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/685c0d9[07:54:07] <jbossbot> git [jboss-as] 685c0d9.. David M. Lloyd Clean up more binding crap[07:54:15] <dmlloyd> now it's an NPE on naming context selector something or other[07:54:58] <dmlloyd> lack of namespace context has come to bite me[07:56:28] <dmlloyd> it worked[07:56:30] <dmlloyd> yay[07:56:53] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/902bd5f[07:56:53] <jbossbot> git [jboss-as] 902bd5f.. David M. Lloyd Yep[07:56:56] <dmlloyd> stuartdouglas: what do you think[07:57:27] <dmlloyd> argh[07:57:30] <dmlloyd> the test still fails :)[07:57:48] <stuartdouglas> mine just hangs[07:58:00] <dmlloyd> got that last commit?[07:58:05] <dmlloyd> you'll probably need a clean rebuild[07:58:37] <dmlloyd> no indication of any problem in the log[07:59:08] <dmlloyd> ah some junit class failed to load[07:59:10] <dmlloyd> lame[08:01:11] <stuartdouglas> I wonder what CL it is using for the deserialization[08:02:02] <dmlloyd> * Returns the first non-null class loader (not counting class loaders of[08:02:02] <dmlloyd> * generated reflection implementation classes) up the execution stack, or[08:02:02] <dmlloyd> * null if only code from the null class loader is on the stack. This[08:02:02] <dmlloyd> * method is also called via reflection by the following RMI-IIOP class:[08:02:33] <dmlloyd> so it should be using org.jboss.arquillian.protocol.jmx.Utils.class.getClassLoader()[08:03:06] <stuartdouglas> which has access to bugger all[08:03:13] <stuartdouglas> I wonder what that ever worked[08:03:22] <stuartdouglas> why that ever worked[08:03:34] <dmlloyd> well it's the app CL, probably[08:03:39] <dmlloyd> so it's just the big flat everything[08:03:50] <dmlloyd> maybe[08:03:55] <dmlloyd> maybe not[08:03:59] <dmlloyd> I guess it's within a module[08:04:34] <dmlloyd> dunno[08:05:06] *** pferraro has quit IRC[08:05:10] <dmlloyd> ¯\(°_o)/¯[08:06:47] <dmlloyd> this is like, the last issue[08:06:55] <dmlloyd> the ultimate, final, terminal, last issue[08:08:17] <stuartdouglas> it is using the jmx protocol module[08:08:25] <stuartdouglas> so if we add a junit dep on that[08:08:34] <stuartdouglas> we can find the next problem[08:08:34] * dmlloyd tries it[08:08:39] <dmlloyd> no next problem![08:08:39] <dmlloyd> no![08:09:58] <dmlloyd> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.579 sec <<< FAILURE![08:09:59] <dmlloyd> dammit[08:10:25] <dmlloyd> junit.framework.ComparisonFailure: null expected:<[#InterceptorBean##OtherInterceptorBean##BeanParent##BeanWithSimpleInjected#]Hello> but was:<[]Hello>[08:10:29] <dmlloyd> that's a little goofy[08:10:41] <stuartdouglas> so, no interceptors[08:11:09] <dmlloyd> oh[08:11:15] <dmlloyd> yeah kinda looks that way :([08:11:30] <stuartdouglas> better than more jndi crap :-)[08:11:38] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/044568e[08:11:38] <jbossbot> git [jboss-as] 044568e.. David M. Lloyd Put the thing on the thing[08:11:40] <dmlloyd> there's that[08:11:51] <dmlloyd> so the method succeeded at least[08:12:20] <stuartdouglas> do the smoke tests fail for you if you try and run just one/[08:12:21] <stuartdouglas> ?[08:12:32] <dmlloyd> dunno never tried taht[08:13:22] <dmlloyd> yeah seems to get all confused[08:13:24] <dmlloyd> some init problem[08:14:55] <dmlloyd> well I'm going to have to look at this tomorrow[08:14:57] <dmlloyd> I'm tired as hell[08:15:14] <stuartdouglas> I should be able to sort out the interceptors tonight[08:15:17] <dmlloyd> everything I have is pushed out, if you get inspired[08:15:19] <dmlloyd> ok cool[08:15:44] <dmlloyd> just leave me a note with the news if any[08:15:44] <stuartdouglas> It's only 6pm here, the day is still young :-)[08:15:50] <dmlloyd> ha[08:15:55] <dmlloyd> later dude[08:22:52] *** opalka has joined #jboss-as7[08:22:52] *** opalka has joined #jboss-as7[08:22:52] *** ChanServ sets mode: +v opalka[08:48:14] *** irooskov has joined #jboss-as7[08:48:49] *** irooskov has left #jboss-as7[08:59:36] *** pil-afk has joined #jboss-as7[09:04:02] *** bgeorges has quit IRC[09:14:46] *** irooskov has joined #jboss-as7[09:21:59] <stuartdouglas> dmlloyd: It works[09:23:48] <stuartdouglas> however I had to change the name of the parent managed beans @AroundInvoke method so it was not overrien by the subclass[09:24:34] <stuartdouglas> I also might have CDI injection working, but I will wait to test it tomorrow before I push[09:25:17] <stuartdouglas> if you merge my ee branch the tests should pass, although I have hit that msc bug a few times[09:34:28] *** asoldano has joined #jboss-as7[09:34:36] *** ChanServ sets mode: +v asoldano[09:36:38] *** torben has joined #jboss-as7[09:36:38] *** ChanServ sets mode: +v torben[09:36:43] *** miclorb has joined #jboss-as7[09:42:23] *** irooskov has quit IRC[09:45:48] *** emuckenhuber has quit IRC[09:48:51] <opalka> stuartdouglas, Does AS7 deployment works for U? I'm getting http://fpaste.org/GjyN/ on jboss-as master :([09:49:19] <opalka> stuartdouglas, all I know it's related to Kabir refactoring steps[10:05:00] *** aloubyansky has joined #jboss-as7[10:05:01] *** alesj has joined #jboss-as7[10:12:19] *** emmanuel has joined #jboss-as7[10:12:19] *** ChanServ sets mode: +v emmanuel[10:12:19] *** emuckenhuber has joined #jboss-as7[10:12:19] *** emuckenhuber has joined #jboss-as7[10:12:19] *** ChanServ sets mode: +v emuckenhuber[10:15:39] *** stalep has joined #jboss-as7[10:27:59] *** kkhan has joined #jboss-as7[10:27:59] *** ChanServ sets mode: +v kkhan[10:43:19] <stuartdouglas> opalka: I am also getting that on master[10:43:36] <stuartdouglas> I have been working on a different branch today so I did not notice[10:44:18] <opalka> stuartdouglas, yes, I'm creating custom branch too now to workaround this problem. I thought I'll fix it locally, but changes set is too huge to track down the real issue :([10:45:50] <stuartdouglas> opalka: Is it just the demo's that are failing for you?[10:48:56] <opalka> stuartdouglas, yes[10:49:17] <stuartdouglas> which is kinda odd cause the arquillian smoke tests pass[10:49:27] <stuartdouglas> maybe something got updated in one but not the other[10:51:47] <kkhan> They both use the same deployment mechanism so that is strange[10:52:55] <kkhan> But I can reproduce the problem as well[10:53:10] <opalka> kkhan, stuartdouglas I was little debugging this problem (hoped I'll fix it and be proactive)[10:53:23] <opalka> kkhan, stuartdouglas but the change set is too huge and I'm not familiar with protocol code[10:53:30] <stuartdouglas> It looks like the deployment mechanism is slightly different[10:53:43] <stuartdouglas> builder = builder.add(archive.getName(), input).andDeploy();[10:53:46] <stuartdouglas> vs[10:54:12] <opalka> stuartdouglas, kkhan The connection is closed with deployment client[10:54:14] <stuartdouglas> builder = deployment.addDeployment(manager, builder);[10:55:27] <kkhan> I'll be offline most of the day but plan to take a look, if you guys do anything please leave a message here since I can check those easily from my phone[10:58:54] <kkhan> Right so we have builder.add(deployment, getRealArchive()).deploy(deployment); in demos[10:59:06] <kkhan> and builder.add(archive.getName(), input).andDeploy(); in arquillian[11:00:27] <opalka> kkhan, our org.jboss.as.webservices.deployer.RemoteDeployer also uses deploymentManager.newDeploymentPlan().add(url).andDeploy();[11:02:58] *** wolfc has joined #jboss-as7[11:02:59] *** ChanServ sets mode: +v wolfc[11:07:20] <kkhan> I think the problem is that the input stream being created in add(File) or add(URL) gets closed right away: http://pastebin.com/k92BxkCY[11:07:29] <kkhan> so there is nothing to send to the server[11:08:13] <kkhan> That file was DeploymentPlanBuilderImpl[11:08:59] <kkhan> And then in arquillian AbstractDeployableContainer we have http://pastebin.com/1jnXUVWV which keeps the stream open[11:09:21] <kkhan> I should be able to fix this on my way to the airport[11:28:39] *** AndyTaylor has joined #jboss-as7[11:28:39] *** ChanServ sets mode: +v AndyTaylor[11:35:10] *** jhalliday has joined #jboss-as7[11:35:32] *** miclorb has quit IRC[11:39:38] *** kkhan has quit IRC[11:57:58] *** torben has quit IRC[12:04:19] *** torben has joined #jboss-as7[12:04:19] *** torben has joined #jboss-as7[12:04:19] *** ChanServ sets mode: +v torben[12:04:33] *** emmanuel has quit IRC[12:24:27] *** darranl has joined #jboss-as7[12:24:37] *** darranl has joined #jboss-as7[12:24:37] *** ChanServ sets mode: +v darranl[12:26:02] *** epbernard has joined #jboss-as7[12:26:02] *** epbernard is now known as emmanuel[12:26:02] *** ChanServ sets mode: +v emmanuel[12:28:27] *** emmanuel has quit IRC[12:28:30] *** epbernard has joined #jboss-as7[12:28:30] *** epbernard is now known as emmanuel[12:28:30] *** ChanServ sets mode: +v emmanuel[12:35:50] *** jcosta has joined #jboss-as7[12:35:50] *** ChanServ sets mode: +v jcosta[13:19:33] *** emmanuel has quit IRC[13:22:04] *** epbernard has joined #jboss-as7[13:22:04] *** epbernard is now known as emmanuel[13:22:04] *** ChanServ sets mode: +v emmanuel[13:24:41] *** torben has quit IRC[13:26:39] *** emmanuel has quit IRC[13:27:36] *** smarlow has joined #jboss-as7[13:27:36] *** ChanServ sets mode: +v smarlow[13:30:32] *** kkhan has joined #jboss-as7[13:30:32] *** ChanServ sets mode: +v kkhan[13:34:03] *** bgeorges has joined #jboss-as7[13:34:50] *** bgeorges has joined #jboss-as7[13:37:20] <kkhan> opalka: My deployment branch contains a fix to make demos work. It is likely to change a fair bit, so up to you is you want it or not...[13:37:58] <opalka> kkhan, I'll wait until it's applied upstream. I set up local (working) branch in the mean time. Thanks for fixing that![13:38:41] *** kkhan has quit IRC[13:38:41] <opalka> kkhan, Anyway I'll have a look to the fix ;)[13:44:32] *** stansilvert has joined #jboss-as7[13:47:10] *** torben has joined #jboss-as7[13:47:10] *** ChanServ sets mode: +v torben[14:01:35] *** epbernard has joined #jboss-as7[14:01:35] *** epbernard is now known as emmanuel[14:01:35] *** ChanServ sets mode: +v emmanuel[14:04:53] *** balunasj_away is now known as balunasj_mtg[14:06:25] *** pil-afk is now known as pilhuhn[14:06:29] *** pilhuhn has joined #jboss-as7[14:08:59] *** smcgowan has joined #jboss-as7[14:08:59] *** ChanServ sets mode: +v smcgowan[14:09:14] *** mmoyses has joined #jboss-as7[14:09:14] *** ChanServ sets mode: +v mmoyses[14:10:24] *** jpederse has joined #jboss-as7[14:10:29] *** jpederse has joined #jboss-as7[14:12:09] *** AndyTaylor has quit IRC[14:31:35] *** davidbos has joined #jboss-as7[14:39:28] *** smarlow has quit IRC[14:50:52] *** bstansberry has joined #jboss-as7[14:50:52] *** ChanServ sets mode: +v bstansberry[14:57:37] *** rmaucher has joined #jboss-as7[14:59:14] *** smarlow has joined #jboss-as7[14:59:14] *** ChanServ sets mode: +v smarlow[14:59:38] *** AndyTaylor has joined #jboss-as7[14:59:38] *** ChanServ sets mode: +v AndyTaylor[15:11:27] *** echelog-2` has joined #jboss-as7[15:12:18] <dmlloyd> awesome.[15:12:58] <rmaucher> Add cross context (enabled by default) and a flag to disable it: https://github.com/rmaucher/jboss-as/commit/839fde8e4857fac09f5c0976715c2489d611aba5[15:12:59] <jbossbot> git [jboss-as] 839fde8.. Rémy Maucherat Add cross context, with a jboss-web.xml element to disable it per context[15:14:31] <jbossbot> git [jboss-as] push master 839fde8.. Rémy Maucherat Add cross context, with a jboss-web.xml element to disable it per context[15:14:31] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/41a4f86...839fde8[15:15:03] <rmaucher> hum, that was fast ;)[15:15:58] <dmlloyd> :)[15:16:05] <emuckenhuber> bstansberry: hey, can you look at the commits at: https://github.com/emuckenhuber/jboss-as/commits/wildcards2[15:16:58] <bstansberry> sure; will do[15:17:18] <emuckenhuber> thanks![15:17:44] *** pferraro has joined #jboss-as7[15:17:44] *** ChanServ sets mode: +v pferraro[15:18:15] <dmlloyd> https://github.com/dmlloyd/jboss-as/tree/ee-merge[15:18:37] <dmlloyd> https://github.com/dmlloyd/jboss-as/commit/407c2f14d12[15:18:38] <jbossbot> git [jboss-as] 407c2f1.. David M. Lloyd Rework EE Component model for extensibility into EJBs and beyond[15:19:34] <dmlloyd> gonna merge that if I can get a thumbs-up[15:19:45] *** stansilvert has quit IRC[15:20:15] *** pgier has joined #jboss-as7[15:20:15] *** ChanServ sets mode: +v pgier[15:27:14] <jbossbot> git [jboss-as] push master 5c1a470.. David M. Lloyd Fix use of newFactory()[15:27:14] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/839fde8...5c1a470[15:33:38] <jbossbot> git [jboss-as] push master 796149c.. Richard Opalka use dynamic aspects ordering (algorithms is O(1) complexity) and switch to aggregation module instead of hardcoded paths in source code[15:33:39] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/5c1a470...796149c[15:34:06] <dmlloyd> opalka: I rebased that on a couple of trivial commits[15:34:15] <opalka> dmlloyd, Thanks David[15:35:47] <davidbos> Hi - Would someone have a moment to pull my rebased version of Thomas' changes? See pull request email with title 'Update OSGi framework to modules Beta14, fix most smoke tests'.[15:37:05] <dmlloyd> which branch, davidbos?[15:37:30] <davidbos> dmlloyd: branch jbosgi_to_modules_b14 on https://github.com/bosschaert/jboss-as/commits/jbosgi_to_modules_b14[15:38:19] <dmlloyd> ok testing now (I rebased it again on above chages)[15:38:42] <davidbos> dmlloyd: many thanks ![15:39:55] <wolfc> I'm close to done with bringing in pool impls. Then I'll dig through the ee branch.[15:40:14] <dmlloyd> I'm going to merge the ee branch into master in about 25 minutes, wolfc[15:40:17] <dmlloyd> (finally)[15:40:38] <dmlloyd> just want to get everyone else's stuff in first[15:40:49] <wolfc> Yeah, probably best to just push forward. I would say no regression = commit.[15:41:33] <dmlloyd> unfortunately it seems to expose a bug in MSC, but it's sporadic, so hopefully we can live with it until I get a chance to investigate that[15:42:01] *** maeste has quit IRC[15:42:03] <jbossbot> git [jboss-as] push master b6590a2.. David Bosschaert Rebase and squash of Thomas' OSGi changes to move up to Modules Beta14...[15:42:03] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/796149c...b6590a2[15:44:17] <davidbos> dmlloyd: thanks again[15:44:44] <dmlloyd> no prob.[15:45:06] <dmlloyd> btw, davidbos, did you see our earlier discussion about OSGi and how it affects EE deployments?[15:45:38] <davidbos> dmlloyd: no, where was it held?[15:45:46] <dmlloyd> here I think[15:46:10] <dmlloyd> basically what happens is, if someone has e.g. a JDBC driver deployment that happens to have OSGi annotations on it, nothing in EE can "see" it[15:46:26] <dmlloyd> ultimately we'd like to at least try to get OSGi using approximately the same module processing as everything else, so that something can be deployed and be visible to OSGi and also EE[15:46:39] <davidbos> dmlloyd: yes, that would make sense[15:46:44] <dmlloyd> I may be oversimplifying the problem statement a little ;)[15:47:10] <dmlloyd> anyway it's not a show-stopper (at least I don't think it is) but it's something to think about[15:47:42] <dmlloyd> the tricky question is, is it possible to conform to both the OSGi class loading rules and the EE class loading rules?[15:47:59] <davidbos> It's a good question.[15:48:22] <davidbos> But ultimately an OSGi module gets mapped to a jboss-module[15:48:45] <davidbos> so in *theory* it should be possible to depend on that module from anything that runs in EE[15:48:53] <davidbos> as long as it can depend on another jboss-module[15:49:28] <davidbos> dmlloyd: let's have this conversation with Thomas when he's back (next week I think). I know he also has some good ideas about this.[15:49:42] <dmlloyd> okay.[15:49:57] <davidbos> but the whole point about OSGi in AS7 is that it can cross borders with EE and integrate with it[15:50:01] <dmlloyd> yes[15:50:04] <davidbos> and vice versa[15:50:09] <davidbos> so this is a good use-case[15:50:28] <dmlloyd> I think it was the H2 driver which first brought up the problem[15:51:30] <davidbos> Is there a JIRA for this by any chance?[15:51:44] <dmlloyd> hmm probably not[15:54:21] *** mbg has joined #jboss-as7[15:54:22] *** ChanServ sets mode: +v mbg[15:55:00] *** AndyTaylor has quit IRC[16:03:46] <Nihility> The problem is that jars include osgi manifest entries just so they are runnable on an osgi env, so they aren't *true* bundles per se[16:03:59] <dmlloyd> ok guys, so the EE stuff works most of the time[16:04:02] <dmlloyd> so I'm gonna push it[16:04:05] <dmlloyd> 30 seconds to object![16:04:16] <Nihility> No objections[16:04:34] <dmlloyd> time's up![16:04:41] <Nihility> and my opinion counts twice![16:04:46] <Nihility> Hahahahha[16:04:47] <jbossbot> git [jboss-as] push master 98592f3.. David M. Lloyd Rework EE Component model for extensibility into EJBs and beyond[16:04:47] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/b6590a2...98592f3[16:04:51] <dmlloyd> there it is[16:04:59] <dmlloyd> now everyone can suffer like I have[16:05:27] <dmlloyd> it's not shown on there but that owes a huge thanks to stuartdouglas and baileyje who worked really hard on getting this done[16:05:36] *** torben is now known as torben|brb[16:06:02] <Nihility> I think a good temporary workaround for the h2 issue is to have some kind of way to ignore osgi or strip osgi stuff on a config basis[16:06:15] <davidbos> Nihility: any jar with a Bundle-SymbolicName manifest header is a valid OSGi bundle[16:06:29] <Nihility> Right I don't mean it's invalid[16:06:39] <davidbos> you see quite often that projects put the OSGi headers in to make it work both in plain JRE and in OSGi[16:07:12] <Nihility> I just mean that they are just supporting osgi, not requiring it[16:07:20] <davidbos> yes[16:07:43] <Nihility> Unfortunately it's impossible to know the difference[16:08:02] <davidbos> I think it's a great use case exposes exactly what we should be able to support with OSGi in AS7[16:08:37] <Nihility> Yeah in theory we should just support mixing and it should just work[16:08:49] <davidbos> yep, that is definitely the goal[16:09:03] <jbossbot> git [jboss-as] push master 9e0af27.. Emanuel Muckenhuber use the actual server name instead of process name[16:09:04] <jbossbot> git [jboss-as] push master 94dac08.. Emanuel Muckenhuber basic wildcard handling[16:09:04] <jbossbot> git [jboss-as] push master d1e04d9.. Emanuel Muckenhuber include address in operation result[16:09:04] <jbossbot> git [jboss-as] push master d90ca72.. Emanuel Muckenhuber basic operations smoke test[16:09:04] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/98592f3...d90ca72[16:12:02] <wolfc> dmlloyd, so what's needed next?[16:12:18] <dmlloyd> next, we need to merge EJB :)[16:12:25] <wolfc> Cool[16:12:32] <dmlloyd> getting that rebased will be a trick[16:12:45] <dmlloyd> iirc some of your commits will come right over but some will need to be almost completely changed[16:12:47] <wolfc> Maybe we should start again from scratch[16:13:09] <dmlloyd> do not say such depressing things :)[16:13:16] <wolfc> hehe[16:14:14] <dmlloyd> first would be https://github.com/wolfc/jboss-as/commit/e24a3f6964a[16:14:15] <jbossbot> git [jboss-as] e24a3f6.. jaikiran Introduce a ContextComponentProcessor for setting up Service for java:comp[16:14:26] *** emuckenhuber is now known as emuckenh_afk[16:14:41] <dmlloyd> this one could be ported over but I don't think we should bother with the NamespaceSelectorService[16:14:50] <dmlloyd> the selector could just be built up right on the Component[16:15:03] <dmlloyd> it's only ever going to be used within a component interceptor anyway[16:15:30] <wolfc> yup[16:15:52] <dmlloyd> I actually removed it (mostly) from MBs because they have no use for it[16:16:17] <wolfc> Keep also https://github.com/wolfc/jboss-as/commit/296e4aaf652c7e0983d25346f15cdaa3b83c72be in mind[16:16:17] <jbossbot> git [jboss-as] 296e4aa.. Carlo de Wolf Allow injection on the component itself[16:16:40] <dmlloyd> we shouldn't need that anymore, but we can discuss that when we get to it[16:18:00] <wolfc> Yeah, I need to read through the code to see where the namespaces are now hidden :-)[16:19:38] <wolfc> Where do you now setup the env ref group that is associated with a MB?[16:19:51] <dmlloyd> it's in MSC[16:19:59] <dmlloyd> the MB doesn't actually do any lookups from it[16:20:11] <dmlloyd> so no context is needed, theoretically[16:20:20] <dmlloyd> er[16:20:24] <dmlloyd> no namespaceselector[16:22:03] <wolfc> how do you deal with a jar containing only MBs?[16:22:29] <dmlloyd> they just kinda sit out there[16:22:48] <dmlloyd> unless you do something like we do in smoke tests where you hack in something to look one up from java:module[16:22:51] <dmlloyd> or java:app[16:23:12] <dmlloyd> it uses the caller's namespace selector then[16:23:38] <dmlloyd> the dep wiring is a little funny but as long as you only use it within the same module or app it's probably ok[16:23:40] <dmlloyd> most of the time[16:24:06] <wolfc> Yeah, I'm not going to think about it for the moment :-)[16:24:16] <dmlloyd> :)[16:24:33] <dmlloyd> EJB makes much more sense[16:27:32] <Nihility> you only are supposed to use them in the same app[16:27:52] <Nihility> at least today that is[16:27:55] <wolfc> Which still leaves cross module a bit icky[16:27:58] <dmlloyd> even in the same app it's a *little* sketchy right now[16:27:59] <dmlloyd> yeah[16:28:03] <dmlloyd> just don't think about it[16:28:09] <wolfc> Exactly :-)[16:28:16] <Nihility> but technically someone can bind a ref to it in the global ns[16:28:20] <dmlloyd> shhh[16:28:34] <Nihility> You just do @resource on your mb[16:28:42] <Nihility> And give it a name in global[16:28:54] <dmlloyd> name is always relative, thankfully[16:28:55] <wolfc> I still see a NamespaceSelectorService in ModuleContextProcessor.[16:29:11] <dmlloyd> yeah the thing still exists, wolfc, it's just not really wired up right now[16:29:17] <Nihility> Sure th mb name is relative[16:29:23] <wolfc> I think the question is how do we setup the relationship of Component to the namespaces?[16:29:30] <Nihility> But the resource name that creates the alias isn't[16:30:02] <dmlloyd> wolfc, in terms of binding, you don't need to worry about it because it's automatic (just set naming mode to CREATE to make sure you have a comp: namespace)[16:30:30] <dmlloyd> wolfc: that also covers injection and MSC deps[16:30:43] <Nihility> on the plus side no one is probably ever going to know you can do that or expect it to work[16:30:53] <dmlloyd> in terms of getting a selector for your interceptor for lookups, that's something we need to add, but it's pretty small[16:30:54] <wolfc> Well I'm looking at https://github.com/wolfc/jboss-as/commit/e24a3f6964a4f01d42676e940c7c09db719f6281#L2R43[16:30:55] <jbossbot> git [jboss-as] e24a3f6.. jaikiran Introduce a ContextComponentProcessor for setting up Service for java:comp[16:31:13] <wolfc> Either a NSS is injected into Component or the three separate namespaces[16:31:50] <dmlloyd> hmm, yeah, that should be part of the component install processor[16:32:12] <dmlloyd> because the other two namespaces will already exist[16:32:20] <dmlloyd> so we just need one comp per, uh, comp[16:32:26] <dmlloyd> (if the naming mode == CREATE)[16:32:32] <dmlloyd> (which it won't be in a servlet)[16:32:37] <dmlloyd> (before you ask that:)[16:33:36] *** opalka has quit IRC[16:34:36] *** bgeorges has quit IRC[16:44:08] <wolfc> Okay, so the actual injection of either NSS of namespaces is now gone from ComponentInstallProcessor[16:44:38] <dmlloyd> yeah but I'm looking at it again right now[16:45:05] <dmlloyd> even though some component types don't have them it might be better to just have a general thing for dealing with namespaces...[16:45:16] <wolfc> while you're there we need to think about injecting other services, like TransactionManager and RarDeploymentRegistry and such[16:47:06] <dmlloyd> yeah those should definitely be deps, but not reflective[16:47:33] <dmlloyd> those are generally system wide right?[16:47:43] <dmlloyd> you're not going to have some EJBs with a txn interceptor and some not?[16:48:03] <wolfc> true. I don't think we want to allow that.[16:48:14] <wolfc> https://github.com/wolfc/jboss-as/commit/296e4aaf652c7e0983d25346f15cdaa3b83c72be#L0R69 is just ugly[16:48:15] <jbossbot> git [jboss-as] 296e4aa.. Carlo de Wolf Allow injection on the component itself[16:49:11] *** mmoyses is now known as mmoyses_[16:49:12] <wolfc> but we can have it cleaner by using a MSC Injector[16:49:15] <dmlloyd> we probably want to have a single service which assembles all that stuff, with optional dependencies on the other subsystems[16:49:29] <wolfc> why not the component start?[16:49:34] <dmlloyd> then every component would simply inject that service's value with all the stuff pre-assembled[16:49:43] <wolfc> ah[16:49:59] <wolfc> In that case an EJBContainer service[16:50:03] <dmlloyd> and all your cross-subsystem logic, or at least a lot of it, is in one place[16:52:30] <wolfc> Note that EJBContainer is a loaded name, http://download.oracle.com/javaee/6/api/javax/ejb/embeddable/EJBContainer.html[16:53:56] <wolfc> So we can go for EJBService instead, but I do see a conceptual similarity. In theory you could boot up an EJBContainer without JCA and one with for example (not spec).[16:54:05] <wolfc> s/with/without/[17:01:08] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/f61db31[17:01:09] <jbossbot> git [jboss-as] f61db31.. David M. Lloyd Give every component a namespace selector, even if it is not gonna use it[17:01:15] <dmlloyd> that should take care of that part of it at least[17:01:33] <dmlloyd> namespace selector is available after start[17:02:03] *** torben|brb is now known as torben[17:13:32] <wolfc> dmlloyd, to be on the safe side, maybe return moduleContext if compContext == null[17:15:27] <dmlloyd> if that's the case then a different naming mode should be used[17:16:24] <wolfc> then we might be missing some safe guards, but that's a secondary concern[17:23:21] <dmlloyd> so next is https://github.com/wolfc/jboss-as/commit/01992a3ce I guess[17:23:21] <jbossbot> git [jboss-as] 01992a3.. Carlo de Wolf Single element domain parser[17:24:12] <wolfc> The goal here is two-fold, we may want to split it[17:24:23] <wolfc> 1. get something in domain.xml[17:24:23] *** mbg has quit IRC[17:24:36] <wolfc> 2. cache configuration via domain[17:25:52] <dmlloyd> well, neither of which is as important as getting EJBs deployed[17:25:55] <dmlloyd> to be frank[17:26:05] <wolfc> exactly, we already got a subsystem element[17:26:17] <wolfc> skip this till later[17:26:20] <dmlloyd> we could have no config at all and we'd satisfy the Beta1 requirement if all the EJB types can be deployed and injection works[17:26:30] <dmlloyd> ok this is getting easier :)[17:26:52] <dmlloyd> https://github.com/wolfc/jboss-as/commit/20e7edf84a8749c9[17:26:52] <jbossbot> git [jboss-as] 20e7edf.. Carlo de Wolf Fixed extension imports[17:26:57] <wolfc> next :-)[17:26:59] <dmlloyd> looks like a simple build fixup[17:27:09] <Nihility> great work guys![17:27:21] <dmlloyd> do you want to start a new branch and start cherry-picking these, wolfc?[17:27:31] <dmlloyd> or do you want me to?[17:27:55] <wolfc> whatever gets stuff as fast as possible in master[17:28:17] <dmlloyd> ok well I can do it, the result might just be a bit rougher :)[17:28:27] <wolfc> Dinner is up on my end[17:28:38] <wolfc> The next one is ejb-jar parsing, that one is important.[17:29:13] <wolfc> It also includes the xerces ban :-)[17:29:49] <wolfc> I'm first going to get some grub[17:30:29] <alesj> wolfc: and some bacos ;-)[17:30:30] <Nihility> wolfc: i have made major progress in xml hell[17:31:09] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/9d6ab25[17:31:10] <jbossbot> git [jboss-as] 9d6ab25.. David M. Lloyd Fixed extension imports[17:31:56] <dmlloyd> I'll simply skip the xerces parts on https://github.com/wolfc/jboss-as/commit/dcbb3c4691 I think[17:31:57] <jbossbot> git [jboss-as] dcbb3c4.. jaikiran Initial work on ejb-jar.xml parsing deployment unit processor...[17:32:02] <dmlloyd> and hope for the best after the modules release[17:32:24] *** smcgowan has quit IRC[17:32:33] <Nihility> isnt it funny how we call cpus 64 bit[17:33:07] <Nihility> has there ever been a mainstream cpu that did not have a byte multiplier register size?[17:33:11] <wolfc> just make sure the smoke-tests pass[17:33:20] * wolfc is running away for food now[17:33:47] <Nihility> cough dmlloyd[17:33:48] <Nihility> :)[17:34:01] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/115a4d2[17:34:01] <jbossbot> git [jboss-as] 115a4d2.. David M. Lloyd Initial work on ejb-jar.xml parsing deployment unit processor - jaikiran, carlo[17:34:14] <dmlloyd> not that I know of Nihility[17:34:20] <dmlloyd> not since the 70s anyway[17:34:21] <Nihility> there is a conflict in that patch[17:34:33] <dmlloyd> really, thought I found em all[17:34:34] <dmlloyd> dammit[17:34:59] <Nihility> thats one thing i noticed about git vs svn[17:35:07] <Nihility> if you tell it a file is resolved[17:35:09] <Nihility> it believes you[17:35:22] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/94eaf25[17:35:23] <jbossbot> git [jboss-as] 94eaf25.. David M. Lloyd Initial work on ejb-jar.xml parsing deployment unit processor - jaikiran, carlo[17:36:09] <dmlloyd> the adding of the jboss-metadata-ejb thing has a few problems[17:36:11] <dmlloyd> 1) it's a snapshot[17:36:19] <dmlloyd> 2) the version isn't managed in the parent pom[17:36:22] <dmlloyd> 3) jbossxb, eesh[17:36:30] <dmlloyd> so that's a todo item[17:37:58] <dmlloyd> .. and https://github.com/wolfc/jboss-as/commit/ae844e775 fixes two of those three problems...[17:37:59] <jbossbot> git [jboss-as] ae844e7.. Carlo de Wolf Moved jboss-metadata-ejb version to dependency management[17:39:15] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/9824ba1[17:39:16] <jbossbot> git [jboss-as] 9824ba1.. David M. Lloyd Moved jboss-metadata-ejb version to dependency management - jaikiran[17:39:28] *** asoldano is now known as asoldano_away[17:39:41] <Nihility> it uses xb?[17:40:03] <dmlloyd> it's a transitive dep of the metadata lib[17:40:09] <dmlloyd> not new with this patch[17:40:24] <Nihility> oh so its not jfcs new metadata lib[17:40:28] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/6d3fc93 came over clean[17:40:29] <jbossbot> git [jboss-as] 6d3fc93.. Carlo de Wolf Created ejb3 demo[17:40:51] *** maxandersen has joined #jboss-as7[17:40:51] *** ChanServ sets mode: +v maxandersen[17:41:17] <maxandersen> bstansberry: just saw your post ;) can't wait to have a build somehow...[17:42:09] <bstansberry> http://community.jboss.org/wiki/HackingonAS7 ;)[17:42:40] <maxandersen> bstansberry: yeah I know but i'm not the one to work on this right now ;)[17:43:29] <maxandersen> so any challenges found in it or was it "straightforward" ?[17:46:16] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/7abf5ba[17:46:17] <jbossbot> git [jboss-as] 7abf5ba.. David M. Lloyd Enabled EjbJarParsingDeploymentUnitProcessor - wolfc[17:46:57] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/82fc4f0[17:46:58] <jbossbot> git [jboss-as] 82fc4f0.. jaikiran Change the version of xml to 1.1 to prevent the javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,39] Message: Premature end of file.[17:47:25] *** balunasj_mtg is now known as balunasj_busy[17:47:41] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/41de561[17:47:42] <jbossbot> git [jboss-as] 41de561.. Carlo de Wolf Cleanup module dependencies[17:50:31] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/9601989[17:50:31] <jbossbot> git [jboss-as] 9601989.. David M. Lloyd Initial attempt at StatelessEJBComponent for deploying/processing SLSBs - ed. by dmlloyd, remove the EJB-specific processor for future integration with the EE component processor[17:50:36] <dmlloyd> and here is where stuff starts to break[17:50:39] <dmlloyd> oops, more conflicts...[17:50:46] *** mmoyses_ is now known as mmoyses[17:51:58] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/1c5326a[17:51:58] <jbossbot> git [jboss-as] 1c5326a.. David M. Lloyd Initial attempt at StatelessEJBComponent for deploying/processing SLSBs - ed. by dmlloyd, remove the EJB-specific processor for future integration with the EE component processor[17:52:36] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/c048691[17:52:37] <jbossbot> git [jboss-as] c048691.. Carlo de Wolf Add a dependency on jboss-modules[17:53:14] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/5a619a9[17:53:23] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/5a619a9[17:53:23] <jbossbot> git [jboss-as] 5a619a9.. Carlo de Wolf Configured the modules to allow EjbComponentDeploymentUnitProcessor to function[17:54:17] *** emuckenh_afk is now known as emuckenhuber[17:55:11] <jbossbot> git [jboss-as] push master 42bc19e.. bstansberry at jboss dot com Don't call the messaging sockets 'netty'[17:55:11] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/d90ca72...42bc19e[17:55:31] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/a224911[17:55:31] <jbossbot> git [jboss-as] a224911.. jaikiran Bring in the latest from upstream and fix the compilation issues[17:55:41] * dmlloyd just figured out how to preserve authors on commits ;)[17:57:53] <wolfc> note that jboss-ejb3-effigy:0.2.0 is deprecated. an upcoming commit will put in a snapshot on jboss-ejb3[17:59:35] *** Nihility has quit IRC[18:01:49] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/3013ebe[18:01:50] <jbossbot> git [jboss-as] 3013ebe.. jaikiran Move the EjbComponentDeploymentUnitProcessor to PARSE phase[18:01:53] <dmlloyd> getting more and more interesting[18:02:10] *** davidbos1 has joined #jboss-as7[18:02:11] <wolfc> That bit is negated later on[18:02:21] <dmlloyd> great :)[18:02:22] *** davidbos has quit IRC[18:02:28] <dmlloyd> more conflicts![18:03:06] *** davidbos1 has quit IRC[18:03:07] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/68bba8f[18:03:08] <jbossbot> git [jboss-as] 68bba8f.. jaikiran Move away from Managed Bean based EJB components....[18:04:04] *** ALR has joined #jboss-as7[18:04:04] *** ChanServ sets mode: +v ALR[18:04:25] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/a9a9805[18:04:26] <jbossbot> git [jboss-as] a9a9805.. jaikiran Add DEPENDENCIES_EJB phase[18:04:50] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/779ed46[18:04:50] <jbossbot> git [jboss-as] 779ed46.. jaikiran Setup correct module dependenices[18:04:52] *** pilhuhn is now known as pil-afk[18:05:05] <dmlloyd> only about 6 left...[18:06:42] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/b153752[18:06:42] <jbossbot> git [jboss-as] b153752.. jaikiran Include EjbDependencyDeploymentUnitProcessor in the Ejb3Subsytem[18:07:38] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/76a4d85[18:07:38] <jbossbot> git [jboss-as] 76a4d85.. jaikiran Setup the system interceptor through the component configuration[18:08:25] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/434d7dc32[18:08:25] <jbossbot> git [jboss-as] 434d7dc.. Carlo de Wolf Setup java:global binding (wip)[18:08:50] <dmlloyd> 434d7dc is our first ambiguous 7-digit sha1![18:08:56] * dmlloyd applause[18:09:08] <dmlloyd> 434d7dc3 is also ambiguous[18:09:11] <wolfc> oh oh happy birthday attack[18:09:13] <wolfc> :-)[18:09:16] <dmlloyd> :)[18:10:57] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/207ebc8[18:10:58] <jbossbot> git [jboss-as] 207ebc8.. Carlo de Wolf Properly bind local business views (wip)[18:11:50] <dmlloyd> skipping http://github.com/wolfc/jboss-as/commit/0bb3c69642183182c73a[18:11:53] <jbossbot> git [jboss-as] 0bb3c69.. jaikiran Introduce a ContextComponentProcessor for setting up Service for java:comp[18:12:30] <wolfc> Yeah, that is a duplicate[18:12:38] <wolfc> Which was rebased into nothingness[18:12:40] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/4af5ec3[18:12:41] <jbossbot> git [jboss-as] 4af5ec3.. jaikiran Final few changes to get the ejb3 demo working[18:13:25] <wolfc> From that point on the ejb3 demo should be working for each commit[18:13:25] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/9b56602[18:13:26] <jbossbot> git [jboss-as] 9b56602.. Carlo de Wolf Initial work on interceptors (wip)[18:13:39] <dmlloyd> yeah, it won't be though because the EJB-specific DUP is nuked[18:13:44] <dmlloyd> among other things[18:13:46] <wolfc> ah[18:13:48] <dmlloyd> like, services with new names[18:13:51] <dmlloyd> and stuff like that[18:13:57] <dmlloyd> but, at least some of the work will be preserved :)[18:13:58] <wolfc> I want to get to a smoke test a.s.a.p.[18:14:05] <dmlloyd> there will be smoke![18:14:09] <wolfc> :-)[18:14:21] <dmlloyd> and it's like they say: where there's smoke, there's dmlloyd[18:15:01] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/e69af9f[18:15:02] <jbossbot> git [jboss-as] e69af9f.. Carlo de Wolf Initial work on stateful session beans (wip)[18:15:04] <dmlloyd> and there it is[18:15:24] <dmlloyd> a paltry hour's worth of work! :)[18:15:37] *** jcosta has quit IRC[18:16:28] <wolfc> Cool[18:17:09] <dmlloyd> http://github.com/dmlloyd/jboss-as/tree/ejb3-domain[18:17:27] <dmlloyd> so next we need to change all the parsing deployers to construct the new component configs[18:18:45] <wolfc> hold on it doesn't compile[18:19:06] <dmlloyd> yeah it probably won't[18:19:08] <dmlloyd> :)[18:19:27] <wolfc> Ah, I ran the smoke-tests after each commit[18:19:30] <dmlloyd> the component install API is mostly different[18:19:39] <wolfc> the base pom is now invalid[18:19:48] <dmlloyd> we could go back and redo every commit but it wouldn't be worth it[18:19:55] <dmlloyd> I'll check the base pom[18:20:25] <wolfc> Well, that was the bit which took me the most time.[18:20:35] <dmlloyd> looks ok to me[18:20:52] <wolfc> the closing tag of version.org.jboss.metadata.ejb is ear[18:20:52] <dmlloyd> http://fpaste.org/fUhO/[18:20:58] <dmlloyd> oh lol[18:21:56] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/ac3ffef[18:21:57] <jbossbot> git [jboss-as] ac3ffef.. David M. Lloyd Fix merge error on closing tag[18:23:09] <wolfc> I squashed those into the offensive commit. Was a hell of a job.[18:23:48] *** aloubyansky has quit IRC[18:24:45] *** jkoder has joined #jboss-as7[18:24:56] <jkoder> hi all[18:25:04] <jkoder> it's regarding my jboss post: Can anybody let me know, what will be the configuration change...more I need to to do, fo rit to work ?[18:25:31] <jkoder> Jboss community post url: http://community.jboss.org/message/588187#588187[18:26:48] <wolfc> jkoder, you are in the JBoss Application Server 7 development channel. You probably want to try some JBoss Portal channel instead.[18:28:07] <jkoder> wolfc: I don't find any channel related to jboss portal specifically...can you plz let me know...if specifc channel for portal exists ?[18:30:29] <dmlloyd> none that I know of[18:31:03] *** alesj has left #jboss-as7[18:31:45] <dmlloyd> jkoder: also spamming multiple channels with the same question is extremely bad etiquette[18:32:24] <dmlloyd> especially when none of the channels has anything to do with what you're asking[18:32:48] *** jkoder has left #jboss-as7[18:34:26] *** emuckenhuber has quit IRC[18:35:07] *** maxandersen has quit IRC[18:39:49] *** AndyTaylor has joined #jboss-as7[18:39:49] *** ChanServ sets mode: +v AndyTaylor[18:50:33] *** rmaucher has quit IRC[18:51:54] *** rmaucher has joined #jboss-as7[18:52:50] *** rmaucher has quit IRC[18:53:00] *** rmaucher has joined #jboss-as7[19:01:54] *** Nihility has joined #jboss-as7[19:01:54] *** ChanServ sets mode: +v Nihility[19:02:02] <Nihility> hopefully thats the last time i have to reboot for the next month[19:04:45] *** darranl has quit IRC[19:08:06] *** pferraro has quit IRC[19:08:06] *** smarlow has quit IRC[19:08:33] *** pferraro has joined #jboss-as7[19:08:34] *** ChanServ sets mode: +v pferraro[19:08:40] *** smarlow has joined #jboss-as7[19:08:40] *** ChanServ sets mode: +v smarlow[19:08:49] *** AndyTaylor has quit IRC[19:09:35] *** AndyTaylor has joined #jboss-as7[19:09:39] *** AndyTaylor has quit IRC[19:09:39] *** AndyTaylor has joined #jboss-as7[19:09:39] *** ChanServ sets mode: +v AndyTaylor[19:16:29] *** emmanuel has quit IRC[19:17:08] *** epbernard has joined #jboss-as7[19:17:08] *** ChanServ sets mode: +v epbernard[19:18:54] *** epbernard is now known as emmanuel[19:25:55] *** balunasj_busy has quit IRC[19:26:49] *** ccrouch has quit IRC[19:29:43] *** AndyTaylor has quit IRC[19:38:03] *** asoldano_away is now known as asoldano[19:38:33] *** kkhan has joined #jboss-as7[19:38:34] *** ChanServ sets mode: +v kkhan[19:43:08] <kkhan> bstansberry: A few commits in my https://github.com/kabir/jboss-as/commits/deployment. https://github.com/kabir/jboss-as/commit/b884d6e5b03f0a3f129e33d94371bc02f07e1581 and https://github.com/kabir/jboss-as/commit/c78c3d5952f2f834c57220b6d6715b0809b41c8d[19:43:09] <jbossbot> git [jboss-as] b884d6e.. kabir Test the deployment api[19:43:10] <jbossbot> git [jboss-as] c78c3d5.. kabir Don't close the streams created from the file and URL varieties of DeploymentPlanBuilder.add()...[19:44:35] *** bstansberry has quit IRC[19:44:48] *** jhalliday has quit IRC[19:50:52] *** bstansberry_ has joined #jboss-as7[19:50:52] <bstansberry_> kkhan: ok, i'll push after lunch[19:50:52] *** bstansberry_ has quit IRC[19:50:52] *** bstansberry_ has joined #jboss-as7[19:50:52] *** ChanServ sets mode: +v bstansberry_[19:50:52] <bstansberry_> kkhan: does that fix ropalka's problem?[19:50:53] *** bstansberry_ is now known as bstansberry[19:51:17] <kkhan> Actually, hold the test commit that does not work following a rebase[19:51:31] <kkhan> It fixed opalkas problem[19:51:42] <kkhan> I'll revise a bit later and let you know[19:51:46] <bstansberry> k[19:57:21] *** mmoyses has quit IRC[19:57:30] *** asoldano has quit IRC[19:57:30] *** pil-afk has quit IRC[20:04:50] *** pil-afk has joined #jboss-as7[20:12:38] *** torben has quit IRC[20:15:10] *** mbg has joined #jboss-as7[20:15:10] *** ChanServ sets mode: +v mbg[20:21:41] *** torben has joined #jboss-as7[20:21:42] *** torben has joined #jboss-as7[20:21:42] *** ChanServ sets mode: +v torben[20:31:33] *** opalka has joined #jboss-as7[20:31:33] *** ChanServ sets mode: +v opalka[20:49:36] *** pil-afk has quit IRC[20:59:29] *** alesj has joined #jboss-as7[21:06:06] *** asaldhan has joined #jboss-as7[21:06:07] *** ChanServ sets mode: +v asaldhan[21:16:02] *** torben has quit IRC[21:19:57] *** torben has joined #jboss-as7[21:19:57] *** torben has joined #jboss-as7[21:19:57] *** ChanServ sets mode: +v torben[21:22:44] *** mmoyses has joined #jboss-as7[21:22:44] *** ChanServ sets mode: +v mmoyses[21:23:15] *** emmanuel has quit IRC[21:26:38] *** pretec has joined #jboss-as7[21:27:57] <dmlloyd> jpederse, do you guys have support for @Datasource yet?[21:28:48] <kkhan> bstansberry: My https://github.com/kabir/jboss-as/commits/deployment is ready[21:28:58] <kkhan> I'll be on PTO tomorrow by the way[21:29:22] <bstansberry> ok, thanks[21:30:51] <jpederse> dmlloyd: as in ?[21:31:18] <dmlloyd> jpederse: as in any deployers which detect it and try to deal with it in any way[21:31:34] <jpederse> dmlloyd: nope[21:39:02] *** maeste has joined #jboss-as7[21:39:03] *** ChanServ sets mode: +v maeste[21:47:24] *** mmoyses has quit IRC[21:55:57] *** miclorb_ has joined #jboss-as7[21:56:42] *** emuckenhuber has joined #jboss-as7[21:56:43] *** emuckenhuber has joined #jboss-as7[21:56:43] *** ChanServ sets mode: +v emuckenhuber[21:56:45] <smarlow> dmlloyd: did EJB3 merge into master also? or is that a ways away? I have some standalone testing with my lame SFSB (cough) container but need to hack it up more to continue JPA integration in parallel.[21:57:00] <dmlloyd> it's not fully merged[21:57:03] <dmlloyd> but the EE stuff is[21:58:16] <smarlow> nice! I might try to hack a way to get a DU from my standalone SFSB container (for standalone testing). Once the real thing shows up, I'll switch to it.[21:58:19] <dmlloyd> most of the integration stuff around resource injection and so on can be done without specific EJB support[21:58:58] <dmlloyd> EJB is just a specific case of what we call a "component" (that's what the EE spec calls it so we're striving for consistency)[21:59:23] <dmlloyd> a component is something that may have one or more JNDI bindings, and may utilize @Resource and CDI injection[21:59:36] <dmlloyd> and usually supports interceptors of various stripes[21:59:59] <dmlloyd> and often has a java:comp JNDI namespace as well[22:00:24] <dmlloyd> this includes EJBs, MBs, servlets, filters, and other stuff along those lines[22:01:02] *** irooskov has joined #jboss-as7[22:03:20] <smarlow> dmlloyd: does the injector (magic) access to the DU come in through one of Injector implementations? Or something else?[22:03:57] <dmlloyd> it depends on where you're using it[22:08:40] <stuartdouglas> morning all[22:14:00] <smarlow> stuartdouglas: hi, thanks for your help yesterday, adding a JPA dependency processor, helped get my test working. Its a lame little test that just invokes a mock SFSB bean method but its a start. :)[22:15:22] <stuartdouglas> no problem :-)[22:16:53] <smarlow> dmlloyd: what do I need to do for getting a JPA injector together that could be used with EJB3 components? I'll need one for WEB components as well.[22:17:27] <stuartdouglas> dmlloyd: unless there is something else you want me to work on I am going to look at making servlet's etc components[22:18:58] <dmlloyd> stuartdouglas: go ahead[22:19:21] <dmlloyd> smarlow: what kind of injector? annotation-driven?[22:19:55] <smarlow> dmlloyd: yes annotation-driven, wolfc mentioned using EnvironmentRefsGroupMetaData before but I'm not sure if that fits in still[22:20:10] <dmlloyd> no, that will no longer be used[22:20:49] <dmlloyd> all you really need is a DUP which runs during, say, parse phase, and then detects your annotation type[22:21:11] <dmlloyd> read the annotation data and use it to create BindingDescriptions for your dependencies that need to be injected[22:23:39] *** aloubyansky has joined #jboss-as7[22:25:01] <aloubyansky> bstansberry: ping[22:25:31] <bstansberry> pong[22:25:54] <smarlow> dmlloyd: read the annotation data from any component archives (EJB3/WEB) that might contain them? I assume that would be done using jandex?[22:26:21] <dmlloyd> smarlow: yeah. For an example of how it could work, look at org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor[22:26:26] <dmlloyd> that's what implements @Resource[22:27:45] <smarlow> dmlloyd: my next question is how do I get invoked at injection time but maybe that answer is in the above code?[22:27:48] * smarlow looking[22:28:00] <dmlloyd> yeah the answer is all there[22:28:07] <dmlloyd> basically you can inject from JNDI or from MSC services[22:28:08] <wolfc> if we go for annotation driven, how do we do metadata-complete then? plus everybody who does metadata transformation?[22:28:42] <dmlloyd> we're not "annotation-driven", it's just that the annotation processors are separate from the descriptor parsers[22:29:35] <dmlloyd> because descriptors override annotations the annotation processors will have to defer to the descriptor processors[22:29:44] <dmlloyd> their structures differ too[22:29:46] <wolfc> but you don't want to duplicate the logic for setting up for example a PU env ref entry[22:30:05] <bstansberry> aloubyansky: ???[22:30:19] <aloubyansky> bstansberry: i am kind of ready with the cli for the next pull... but rebase resulted in lots of conflicts...[22:30:21] <dmlloyd> well in either case it's just "create a binding source from the PU", there's not really much duplication[22:30:41] <aloubyansky> the only thing i did outside cli was JBAS-8919[22:30:42] <jbossbot> jira [JBAS-8919] add read-children-types operation [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-8919[22:31:14] <bstansberry> that will be good to have[22:31:32] <bstansberry> were conflicts from kkhan's stuff?[22:31:33] <aloubyansky> yes, i need it[22:32:36] <bstansberry> ExecutionContext[22:33:00] <wolfc> I think we're not in sync there yet, but first I need some sleep.[22:33:22] <aloubyansky> i'm looking...[22:33:39] <dmlloyd> I have no doubt it will need some changes to be as elegant as it can be[22:33:45] <dmlloyd> but right now it should work and that counts for a lot :)[22:35:03] <wolfc> I don't care too much for elegance as long as it works. But to me it looks like we're still talking apples vs bananas when it comes to some bits.[22:36:04] <aloubyansky> bstansberry: anyway... i'm gonna merge it anyway... but should i still do rebase or just merge?[22:36:41] <bstansberry> rebase is preferable[22:37:09] <aloubyansky> ok, i'll do that then[22:38:10] *** aloubyansky has quit IRC[22:43:18] *** wolfc has quit IRC[22:51:58] *** jamezp has joined #jboss-as7[22:55:30] *** AndyTaylor has joined #jboss-as7[22:55:31] *** ChanServ sets mode: +v AndyTaylor[22:56:17] *** maxandersen has joined #jboss-as7[22:56:17] *** ChanServ sets mode: +v maxandersen[23:01:31] *** maeste has quit IRC[23:10:34] *** emuckenhuber has quit IRC[23:15:32] *** epbernard has joined #jboss-as7[23:15:32] *** epbernard is now known as emmanuel[23:15:33] *** ChanServ sets mode: +v emmanuel[23:18:01] <dmlloyd> http://weblogs.java.net/blog/kohsuke/archive/2009/03/my_project_of_t.html[23:18:05] <dmlloyd> clever little program[23:18:18] <dmlloyd> not sure if it was someone here who linked that to me[23:19:25] *** AndyTaylor has quit IRC[23:19:59] *** torben has quit IRC[23:21:41] *** mbg has quit IRC[23:22:55] <alesj> dmlloyd: cool stuff[23:23:10] <alesj> and he has a good point, why isn't this part of JDK ...[23:23:32] <dmlloyd> such a simple thing to do too[23:24:17] <alesj> yup[23:24:23] <alesj> do we use it?[23:24:29] <dmlloyd> I could picture a whole range of annotations to do stuff like seal packages, add manifest entries etc.[23:24:45] <dmlloyd> at compile time[23:27:18] <alesj> i think Arq dev time with this plugin would be reduced to 2 days :-)[23:27:36] <dmlloyd> ha[23:47:11] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/193ce9bdf6ede84edad493b6847480de020d1341[23:47:11] <jbossbot> git [jboss-as] 193ce9b.. David M. Lloyd Differentiate between bindings made for dependencies and bindings made for exposing views[23:47:32] <dmlloyd> stuartdouglas: would you mind glancing over that one[23:47:42] <stuartdouglas> sure[23:48:27] <stuartdouglas> looks fine to me[23:48:55] <jbossbot> git [jboss-as] push master 3a7d824.. David M. Lloyd Unused class[23:48:55] <jbossbot> git [jboss-as] push master 5d32981.. David M. Lloyd Differentiate between bindings made for dependencies and bindings made for exposing views[23:48:55] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/42bc19e...5d32981[23:49:08] <dmlloyd> had to rebase it[23:49:21] *** pretec has quit IRC[23:56:12] *** opalka has quit IRC[23:59:10] *** asoldano has joined #jboss-as7[23:59:41] *** kkhan has quit IRC[23:59:58] <Nihility> https://github.com/n1hility/jboss-as/commit/f6cbd2a8ad5e62d77f273ce1ca5a3fb3347dc7a8[23:59:58] <jbossbot> git [jboss-as] f6cbd2a.. Jason T. Greene Fix xalan, use the new jaxp module, fix JBAS-8909