March 27, 2011 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 27, 2011 NOTICE: This channel is no longer actively logged.
[00:17:03] *** ALR has quit IRC[00:36:31] *** smarlow has joined #jboss-as7[00:36:32] *** ChanServ sets mode: +v smarlow[00:36:41] *** jamezp has joined #jboss-as7[01:14:54] *** aslak has quit IRC[01:45:45] *** jamezp has quit IRC[03:14:41] <dmlloyd> that seems reasonable stuartdouglas[03:15:21] <dmlloyd> I'll have to review the patch later though[03:45:14] *** Nihility has joined #jboss-as7[03:45:14] *** Nihility has joined #jboss-as7[03:45:14] *** ChanServ sets mode: +v Nihility[03:50:02] *** Nihility has quit IRC[04:06:36] *** Nihility has joined #jboss-as7[04:06:36] *** Nihility has joined #jboss-as7[04:06:36] *** ChanServ sets mode: +v Nihility[04:19:57] <smarlow> Nihility: Looks like I should be able to use our annotation index with Hibernate after all. The answer to your question last night, AS6 sets the "hibernate.ejb.resource_scanner" to HackTLScanner[04:20:21] <Nihility> what does HackTLScanner do[04:20:21] <Nihility> ?[04:20:25] <smarlow> I'm working on doing the something similar only with the jandex index[04:21:55] <smarlow> org.jboss.as.jpa.scanner.HackTLScanner implements the Hibernate scanner interface and handles a callback from Hibernate getClassesInJar(URL jartoScan, Set<Class<? extends Annotation>> annotationsToLookFor)[04:23:20] <smarlow> I'll pass myself the jandex index and try to handle the above callback with it.[04:26:56] <Nihility> do you know when this callback happens?[04:27:03] <Nihility> is it during deployment[04:27:04] <Nihility> ?[04:27:22] <Nihility> just going to warn you we toss the indexes after deployment[04:28:49] <smarlow> Yes, I was a little worried about that as baileyje mentioned that to me before. But, I only need it during the deployment of the PU service. I'll clear my reference to it after that[04:29:34] <Nihility> ok sounds reasonable[04:34:15] <smarlow> dmlloyd: awesome "services missing dependencies" message![04:35:26] <smarlow> not that I don't appreciate the msc mbean dump services to string function :)[04:37:24] *** jwulf has joined #jboss-as7[04:43:34] *** jclingan has joined #jboss-as7[05:05:23] *** echelog-2 has joined #jboss-as7[05:16:13] <Nihility> dmlloyd: big surprise jaxb doesnt do factory discovery correct either[05:16:46] <Nihility> dmlloyd: i think we are going to have to audit every api[06:53:11] *** jwulf has quit IRC[07:08:11] *** Nihility has quit IRC[07:15:14] *** jclingan has quit IRC[07:38:06] *** smarlow has quit IRC[12:53:06] *** aslak has joined #jboss-as7[12:53:06] *** aslak has joined #jboss-as7[12:53:06] *** ChanServ sets mode: +v aslak[13:37:06] *** pferraro has joined #jboss-as7[13:37:06] *** ChanServ sets mode: +v pferraro[13:37:08] *** pferraro has quit IRC[15:05:15] *** jpearlin has joined #jboss-as7[15:10:49] *** jfclere has joined #jboss-as7[15:59:54] *** smarlow has joined #jboss-as7[15:59:54] *** ChanServ sets mode: +v smarlow[16:08:50] *** jfclere has quit IRC[16:24:15] <dmlloyd> stuartdouglas: Okay I've checked over the patch, and I'm not happy with it...[16:24:42] <dmlloyd> BindingDescription is a last-stage binding only, it's not a description of the @Resource annotation or a descriptor or anything else.[16:24:57] <dmlloyd> it's only used at the end of processing to create the bindings[16:25:10] <dmlloyd> having classes with too many purposes is what made the AS 6 stuff impossible to use.[16:25:50] <dmlloyd> and the whole bindings container thing is too complex[16:26:24] <dmlloyd> have you discovered a case where bindings can be created without a component present?[16:27:28] <dmlloyd> JndiInjectionPointStore and JndiInjectedValue duplicate functionality that already exists[16:29:02] <dmlloyd> if we do want to represent stuff from the DD then there should be a separate representation for that which is transformed into the component description. Since DDs are parsed first I think that the annotation processors should be the ones to do the combination[16:29:18] <dmlloyd> they can read the annotations and merge with the DD info to emit the component descriptions[16:36:11] *** aslak has quit IRC[17:35:09] *** jfclere has joined #jboss-as7[17:52:46] *** mbg has joined #jboss-as7[17:52:46] *** ChanServ sets mode: +v mbg[17:53:32] *** aslak has joined #jboss-as7[17:53:32] *** aslak has joined #jboss-as7[17:53:32] *** ChanServ sets mode: +v aslak[18:06:28] *** jfclere has quit IRC[18:12:07] <mbg> dmlloyd: ping[18:14:18] <dmlloyd> mbg: I onily have a minute, what's up?[18:17:40] <mbg> dmlloyd: is there a doc on the CL model of AS7?[18:21:46] *** dimitris_ has joined #jboss-as7[18:21:46] *** ChanServ sets mode: +v dimitris_[18:23:10] <dmlloyd> mbg: no not really[18:23:21] <dmlloyd> every JAR is a CL, they have imports and exports[18:23:24] <dmlloyd> that's about the size of it[18:24:29] <mbg> dmlloyd: ok, thx. I'll try make do with that and http://community.jboss.org/wiki/ClassloadinginJbossAS7[18:26:56] *** smarlow has quit IRC[18:27:30] *** smarlow has joined #jboss-as7[18:27:30] *** ChanServ sets mode: +v smarlow[18:30:50] *** mbg has quit IRC[18:43:36] *** jamezp has joined #jboss-as7[19:21:32] *** tdiesler has joined #jboss-as7[19:21:32] *** ChanServ sets mode: +v tdiesler[19:59:03] *** tdiesler has quit IRC[20:03:52] *** tdiesler has joined #jboss-as7[20:04:00] *** ChanServ sets mode: +v tdiesler[20:07:03] *** dimitris_ has quit IRC[20:10:52] *** tdiesler has quit IRC[20:26:59] *** tdiesler has joined #jboss-as7[20:26:59] *** ChanServ sets mode: +v tdiesler[20:55:20] *** dimitris_ has joined #jboss-as7[20:55:21] *** dimitris_ has joined #jboss-as7[20:55:21] *** ChanServ sets mode: +v dimitris_[21:12:55] *** tdiesler has quit IRC[21:21:54] <bstansberry> dmlloyd, Nihility, baileyje: if anyone can have a look https://github.com/bstansberry/jboss-as/commit/a768088dfe87ebf28f6120b656e8ca548a66a6d6 sometime, I'd appreciate it[21:21:55] <jbossbot> git [jboss-as] a768088.. bstansberry at jboss dot com [JBAS-9070] Support for auto-deployment by the deployment scanner[21:21:56] <jbossbot> jira [JBAS-9070] Support for auto-deployment by the deployment scanner [Open (Unresolved) Task, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9070[21:22:01] <bstansberry> no rush[21:23:06] <dmlloyd> not sure I agree with redeploying an exploded deployment any time any file changes[21:23:21] <dmlloyd> makes it kinda hard to, say, fiddle with HTML[21:23:35] <dmlloyd> we should use a marker file for redeploy imo[21:23:46] <dmlloyd> even in so-called auto-deploy mode[21:27:59] *** tdiesler has joined #jboss-as7[21:27:59] *** ChanServ sets mode: +v tdiesler[21:28:30] <bstansberry> you can raise it on the forum thread :-)[21:29:50] <bstansberry> if you want to fiddle with html, the approach is to put down a .skipdeploy once it's deployed[21:30:03] <bstansberry> or, better, don't turn on auto-deploy[21:30:16] <dmlloyd> does it really make sense to have one mode switch which applies to both exploded and JAR deployments?[21:30:56] <dmlloyd> JAR deployments for example can usually be safely auto-deployed as long as they haven't been modified for, say, 15 seconds[21:31:09] <dmlloyd> but exploded deployments cannot have such detection applied[21:31:33] <dmlloyd> JAR deployments need to be copied, exploded deployments should not be[21:31:38] <bstansberry> the enum can be converted to 2 flags[21:31:48] <bstansberry> same effect[21:36:49] <bstansberry> yeah, the enum is pretty stupid, isn't it?[21:37:19] <bstansberry> it was a quick shorthand to explain the rules in a forum post, but kind of a brainless way to do the actual configuration[21:38:29] <dmlloyd> I can't think of any case where someone would actually want to use auto-deploy mode on an exploded deployment TBH[21:38:42] <dmlloyd> but on a JAR I could see uses for both cases[21:40:38] <bstansberry> I don't really see it either, but it was easier to just do it than to have 5 more pages of forum thread[21:41:03] <bstansberry> well, actually I can see it a little bit[21:41:21] <bstansberry> exploded ear, you drop in a new version of a zipped war or jar[21:41:31] <bstansberry> dev time of course[21:41:43] <dmlloyd> that also means we have to monitor every file in an exploded deployment and track their mod time[21:42:32] <bstansberry> it cheats[21:42:40] <bstansberry> it just tracks the latest[21:43:00] <bstansberry> if you copy in content that older than the latest, oh well[21:46:56] <dimitris_> Hey, how you guys are doing on a Sunday? :-)[21:48:29] <bstansberry> thrilled with FS deployment ;)[21:48:46] <dimitris_> LoL[21:49:05] <dmlloyd> aka Paint That Bikeshed![21:51:27] <dimitris_> BTW, unless there is some easy cheat (as you say) for the exploded case maybe just monitor the .isdeployed marker.[21:51:38] <dmlloyd> aka I like mauve[21:55:39] *** tdiesler has quit IRC[21:55:42] <bstansberry> https://github.com/bstansberry/jboss-as/commit/a768088dfe87ebf28f6120b656e8ca548a66a6d6 is it from me for FS deployment, except right now I'm getting rid of the brain-dead enum[21:55:43] <jbossbot> git [jboss-as] a768088.. bstansberry at jboss dot com [JBAS-9070] Support for auto-deployment by the deployment scanner[21:55:44] <jbossbot> jira [JBAS-9070] Support for auto-deployment by the deployment scanner [Open (Unresolved) Task, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9070[22:01:16] *** alesj has joined #jboss-as7[22:07:32] *** aslak has quit IRC[22:07:38] *** aslak has joined #jboss-as7[22:07:39] *** aslak has joined #jboss-as7[22:07:39] *** ChanServ sets mode: +v aslak[22:16:20] *** jamezp has quit IRC[22:18:13] *** jclingan has joined #jboss-as7[22:29:08] <stuartdouglas> dmlloyd: ping[22:39:14] <dmlloyd> hey stuartdouglas[22:39:46] <stuartdouglas> hey dmlloyd[22:40:07] <stuartdouglas> Got a minute to talk about my bindings patch?[22:42:01] <dmlloyd> sure[22:43:13] *** cs02rm0 has joined #jboss-as7[22:43:34] <stuartdouglas> It is possible to have bindings without components, as bindings set up in web.xml are bound to java:module, and it is also possible to have one binding that injects into multiple components[22:43:55] <stuartdouglas> If the injection-point element represents and interceptor on multiple components say[22:44:02] <stuartdouglas> or a super class of multiple components[22:45:34] <stuartdouglas> so our current model where the bindings are owned by components does not really work[22:47:54] <stuartdouglas> also you said that JndiInjectionPointStore and JndiInjectedValue duplicate functionality that already exists, which functionality is this?[22:48:28] <bstansberry> https://github.com/bstansberry/jboss-as/commit/ca5035c0529e4745c6c88c4950c5cdfb5c7a7535 gets rid of that enum[22:48:29] <jbossbot> git [jboss-as] ca5035c.. bstansberry at jboss dot com Git rid of AutoDeploy enum[22:48:41] <bstansberry> I'll squash it with the other one before pushing anything[22:49:00] <bstansberry> time for a run[22:49:06] *** bstansberry is now known as bstans_afk[23:00:07] <dmlloyd> stuartdouglas, yeah *but* such bindings are still bound to the servlet component even if they end up in module[23:00:54] * dmlloyd double-checks that...[23:01:14] *** irooskov has joined #jboss-as7[23:03:36] <stuartdouglas> no, as you do not specify the component[23:03:45] <stuartdouglas> you can specify the injection point[23:04:35] <stuartdouglas> but you can actually specify multiple injections points[23:05:00] <stuartdouglas> so if you were using that as an indication of the component to bind to it could end up bound to multiple components[23:09:26] <dmlloyd> can you give an example?[23:11:31] *** bobmcw has quit IRC[23:11:58] <stuartdouglas> This is an env-entry with two injection targets: http://pastie.org/1723768[23:12:23] <stuartdouglas> but even if there is only 1 injection target and it is an interceptor class[23:12:35] <stuartdouglas> it could be attached to multiple components[23:13:07] *** dimitris_ has quit IRC[23:13:51] <dmlloyd> well first, you have one interceptor instance per component instance[23:14:06] <dmlloyd> second an env-entry name is relative to the component namespace[23:14:16] <stuartdouglas> yes, but only one binding[23:14:26] <stuartdouglas> and the component namespace is shared in a web module[23:15:14] <dmlloyd> yes but each env-entry must have a unique JNDI name within the deployment[23:15:26] <dmlloyd> so you can't for example fold two together somehow[23:16:16] <stuartdouglas> yea, but that single env-entry can be injected into multiple components[23:18:20] <dmlloyd> so really the collection of servlets appear as a single component instead of one component per servlet[23:18:25] <dmlloyd> from an injection perspective[23:19:00] <stuartdouglas> more from a binding perspective, but it is not just servlets[23:19:15] <stuartdouglas> managed beans are in the same boat[23:19:54] <stuartdouglas> and I am not sure what the expected behaviour is if an interceptor on an EJB is listed as an injection target[23:20:29] <dmlloyd> I expect no different than when @Resource is applied to an interceptor setter or field[23:21:03] <stuartdouglas> yea, but if it is an ejb interceptor then it has it's own java:comp namespace[23:21:28] <stuartdouglas> while the binding is to the java:comp namespace for the web components (really java:module)[23:22:02] <stuartdouglas> I suppose it should probably just inject as normal, even though java:comp lookups won't work[23:22:15] <dmlloyd> where do you read that? about EJB interceptors I mean[23:23:47] *** bobmcw has joined #jboss-as7[23:23:48] *** ChanServ sets mode: +v bobmcw[23:24:20] <stuartdouglas> It is not explicitly mentioned, but as far as I can tell it should still work[23:24:23] *** bobmcw has quit IRC[23:24:30] *** bobmcw has joined #jboss-as7[23:24:31] *** ChanServ sets mode: +v bobmcw[23:24:31] *** aslak has quit IRC[23:24:40] <dmlloyd> afaict an interceptor instance shares its comp namespace with the component to which it is attached[23:24:48] <stuartdouglas> the spec seems kinda vauge on exactly what types of objects are allowed to be injection targets[23:25:02] <stuartdouglas> but I would think anything that can use @Resource[23:25:25] <stuartdouglas> yes, which will be different to the namespace that the binding was defined in[23:26:44] <dmlloyd> I don't think so, I think that the namespace is shared both for binding as well as lookup[23:26:50] <dmlloyd> for interceptors attached to EJBs[23:26:53] <dmlloyd> it's all one component[23:27:03] <dmlloyd> same for interceptors attached to MBs[23:29:35] <stuartdouglas> so if you have an env-entry that mentions an interceptor injection point[23:30:00] <stuartdouglas> you would expect it to bind into java:comp for the ejb as well as the normal web java:comp ?[23:30:37] <dmlloyd> if you're talking about EJBs in a web deployment, those share the module-wide comp space afaik[23:31:25] <stuartdouglas> oh, I did not realise that[23:31:31] <stuartdouglas> will that makes more sense then[23:31:35] <dmlloyd> EE.5.2.2 - Except for components in a web module, each component gets its own java:comp namespace, not shared with any other component. Components in a web module do not have their own private component namespace.[23:32:21] <stuartdouglas> but even so, the main issue is that the bindings do not belong to any particular component[23:32:45] <dmlloyd> well the binding belongs to all of the components, really[23:32:57] <dmlloyd> all the components which use the class into which the binding is injected[23:33:22] <dmlloyd> because all of the components will then need a dependency on it[23:33:32] <stuartdouglas> I would say all components, as the bindings still have to be available for lookup even if they are not injected[23:34:25] <dmlloyd> unless the component can't see the binding anyway...[23:34:54] <dmlloyd> that might be a fine hair to split but when we have dependencies which are module-wide we're going to have circular dep problems[23:35:25] <dmlloyd> well, maybe the two-phase comp startup will help with that I guess[23:36:05] <stuartdouglas> I think two phase startup should be enough to handle it, otherwise we will get circular dep problems anyway[23:41:23] <dmlloyd> okay so logically at a module level we really need a map of bindings by JNDI name->original source, and a map of injections by class+property->source (possibly original, possibly from the previous JNDI map)[23:41:54] <dmlloyd> then each component really depends on every single aforementioned source[23:42:33] <stuartdouglas> that is very close to what I did in my patch, although I did not to the every component dependends on every binding thing[23:42:56] <dmlloyd> the thing is we should be able to do this without substantially increasing the number of classes in that mass[23:42:57] <dmlloyd> mess[23:43:00] <dmlloyd> mass of mess[23:43:06] <stuartdouglas> AbstractBindingsContainer is the map of binding name -> BindingDescription[23:43:18] <dmlloyd> but why a whole class hierarchy for it?[23:43:42] <stuartdouglas> and JndiInjectionPointStore is the map of class name -> injections[23:44:46] <stuartdouglas> it does a thing where as bindings are added to the component, if the component cannot handle them they propagate up to the module level, which gave the component a chance to add any deps[23:45:07] <stuartdouglas> but in hindsight this is probably not what we need anyway[23:57:09] *** bstans_afk is now known as bstansberry