March 6, 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 6, 2011 NOTICE: This channel is no longer actively logged.
[00:00:46] <Nihility> hmmm[00:01:16] <Nihility> im thinking about this registry lookup lazy load[00:02:23] *** mbg has quit IRC[00:03:40] <Nihility> i suppose we know for sure the dep exists right[00:03:54] <stuartdouglas> yea[00:04:18] <stuartdouglas> the instantators provide a list of services they depend upon[00:04:31] <Nihility> oh i missed that[00:04:42] <stuartdouglas> and then the main web service depends on that[00:05:08] <stuartdouglas> thinking about it making the instantiators services would probably be a better approach[00:05:33] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/653a5d9[00:05:48] <dmlloyd> hmm wehere's jbossbot[00:05:56] <Nihility> hes been gone since yesterday[00:05:57] *** jamezp has quit IRC[00:06:04] <Nihility> dmlloyd: looks good[00:06:11] *** jbossbot has joined #jboss-as7[00:06:11] *** ChanServ sets mode: +v jbossbot[00:06:13] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/653a5d9[00:06:15] <jbossbot> git [jboss-as] 653a5d9.. David M. Lloyd Provide a mechanism to attach arbitrary data to proxy invocation handlers[00:06:21] <dmlloyd> stuartdouglas: what do you think[00:06:28] <dmlloyd> fixes all your probs? :)[00:06:33] <Nihility> stuartdouglas: yeah although it seems we have a bunch of stuff doing the pattern you are doing[00:06:47] <stuartdouglas> no, as I can't proxy the servlets :-)[00:06:51] <Nihility> dmlloyd: nope[00:07:16] <dmlloyd> yes it does![00:07:22] <Nihility> haha[00:07:42] *** jamezp has joined #jboss-as7[00:07:44] <dmlloyd> two cases, right? With @ManagedBean and without[00:07:49] <Nihility> the problem is the hooks in jbweb just operate on the servlet instance[00:07:59] <stuartdouglas> yea[00:07:59] <dmlloyd> well, fuck jbweb[00:08:09] <Nihility> so it needs to be enhanced imo[00:08:13] <dmlloyd> right on[00:08:36] <Nihility> but we might have to do a crappy association map as a stopgap[00:08:38] <dmlloyd> if you're doing @ManagedBean you have a proxy and JndiInjectable will be passed in the proxy to destroy so we have to have some way to get the original stuff off of there[00:08:54] <dmlloyd> this solves that[00:08:59] <Nihility> well im not so sure[00:09:03] <dmlloyd> that's general across all component types[00:09:06] <Nihility> beause i think[00:09:18] <Nihility> you can get the servlet instance[00:09:23] <Nihility> via servlet apis[00:09:32] <Nihility> and tomcat would have the "wrong" servlet[00:09:34] <stuartdouglas> hang on, why is there only one invocation handler ?[00:09:40] <dmlloyd> why not?[00:09:41] *** jamezp has quit IRC[00:09:56] <dmlloyd> it doesn't really have any state other than to attach the initial private data map[00:10:23] <stuartdouglas> don't it need to know the instance it is delegating to?[00:11:20] <dmlloyd> yes, but not at creation time[00:11:25] <dmlloyd> consider a SLSB proxy[00:11:31] <dmlloyd> it could have a different instance on every invocation[00:11:39] <dmlloyd> only an interceptor can do the association[00:11:49] <dmlloyd> the interceptor's only source of information is the private data map[00:12:02] <dmlloyd> so that map has to contain all the information necessary to make the association[00:13:00] <stuartdouglas> so how does that work with managed beans?[00:14:57] <dmlloyd> well managed beans are simple because you create a new instance every time and just tack it on to the proxy[00:15:37] <dmlloyd> that'd be the first interceptor which does that upon construction[00:15:41] <Nihility> ok it looks like they removed all of the methods[00:15:46] <Nihility> that can return a servlet instance[00:15:49] <Nihility> in the servlet apis[00:15:50] <Nihility> thats good[00:15:53] <Nihility> (security flaw)[00:18:14] <stuartdouglas> how do you tack the instance onto the proxy?[00:18:30] <stuartdouglas> with an extra field?[00:19:43] <dmlloyd> private data[00:20:21] <Nihility> dmlloyd: can you glance at stuarts patch[00:21:26] <dmlloyd> it occurs to me that there's no way to see the original proxy from the interceptor[00:21:29] * dmlloyd can fix that quick...[00:22:31] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/d4d1ef2[00:22:31] <jbossbot> git [jboss-as] d4d1ef2.. David M. Lloyd Provide a mechanism to attach arbitrary data to proxy invocation handlers[00:22:54] <dmlloyd> once you have the proxy you can get the inv handler, once you have that you can get at the template private data[00:23:19] <stuartdouglas> ok, I am following now :-)[00:23:23] <stuartdouglas> looks good[00:23:56] <stuartdouglas> will the synchronisation cause performance problems?[00:25:28] <stuartdouglas> It may be better to make the map volatile and immutable, and then replace it at write time instead of modifying it[00:30:58] <Nihility> yeah otherwise you can never do parellel ejb invocations on the same component[00:31:17] <Nihility> well thats not entirely true[00:31:44] <stuartdouglas> but if you had a lot of invokations they could pile up behind the sync block[00:31:51] <Nihility> totally[00:31:59] <Nihility> i agree a copy-on-write is better here[00:32:31] <Nihility> the sync block in aop invocation was one of the bottlenecks of ejb[00:33:28] <Nihility> but something tells me dmlloyd is very busy right now, and wrote that in like 5 seconds[00:33:30] <Nihility> :)[00:33:37] <dmlloyd> it doesn't block on invocation[00:33:48] <dmlloyd> well it does I guess[00:33:55] <Nihility> yeah it blocks IN invocation[00:33:58] <dmlloyd> yeah just changed two diapers[00:33:58] <Nihility> not on[00:33:59] <Nihility> :)[00:34:36] <Nihility> the lock duration is very small though[00:34:49] <Nihility> but its enough that if there is contention it would probably show up[00:34:50] <dmlloyd> yeah but stuart may be right - these maps rarely change[00:34:55] <dmlloyd> so COW might be better[00:35:14] <Nihility> FCHM would fit this nicely[00:35:49] <stuartdouglas> what is FCHM? (I take it the CHM is concurrent hash map)[00:36:45] <Nihility> fast copy hash map[00:37:43] <Nihility> its a map i wrote thats clone operation is table[].clone()[00:37:48] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/96f4c9e[00:37:49] <jbossbot> git [jboss-as] 96f4c9e.. David M. Lloyd Provide a mechanism to attach arbitrary data to proxy invocation handlers[00:38:01] <dmlloyd> FCHM would fit this nicely if it were an identity map[00:38:20] <stuartdouglas> why does it need to be identity if you are using Class as the key?[00:38:46] <dmlloyd> because it's already optimized for having identity keys (doesn't rehash)[00:39:33] <Nihility> oh i didnt realize it was identiy[00:39:35] <dmlloyd> really performs better than anything else[00:39:42] <dmlloyd> for its particular use case anyway[00:39:42] <Nihility> idhm is just as fast[00:39:46] <Nihility> at copies[00:39:59] <Nihility> so there is no need for an identity fast copy[00:40:23] <Nihility> idhm is also more memory efficient[00:40:29] <Nihility> no entry object[00:40:42] <dmlloyd> yeah[00:40:52] <dmlloyd> it iterates faster too[00:40:59] <dmlloyd> because it reuses the same Entry[00:41:10] <dmlloyd> which in other circumstances causes problems :)[00:41:12] <dmlloyd> but not here[00:41:32] <Nihility> ideally we should be able to eliminate all locking on an invocation[00:41:41] <Nihility> not sure we have anywhere else[00:41:47] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/96f4c9e should do it[00:41:48] <jbossbot> git [jboss-as] 96f4c9e.. David M. Lloyd Provide a mechanism to attach arbitrary data to proxy invocation handlers[00:42:05] <Nihility> yeah i mean we could have other subtle areas[00:42:12] <Nihility> like say an interceptor[00:42:13] <dmlloyd> maybe[00:42:16] <dmlloyd> a profiler will tell is[00:42:17] <dmlloyd> us[00:42:20] <Nihility> right[00:42:26] <Nihility> i just meant we should keep that as a goal[00:42:27] <dmlloyd> anyway I'm gonna push this[00:42:31] <Nihility> yeah looks good[00:42:40] <jbossbot> git [jboss-as] push master 96f4c9e.. David M. Lloyd Provide a mechanism to attach arbitrary data to proxy invocation handlers[00:42:40] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c8d686e...96f4c9e[00:42:48] <Nihility> like i said that aop interceptor lock[00:42:52] <Nihility> was one of the big things[00:42:56] <Nihility> that popped out on ejb[00:47:31] <stuartdouglas> anyway, back to the servlet predestroy thing, for now I think I might just use a map to associate the instance -> ComponentInstance, until we can fix the web code[00:47:42] <Nihility> ok[00:49:28] *** jpearlin has joined #jboss-as7[00:56:24] <stuartdouglas> hmm, actually it looks like this will need slightly more work than just adding map, as ComponentView does not provide any way to get the ComponentInstance[00:58:43] <stuartdouglas> dmlloyd: after your change managed beans are now singleton objects[00:59:47] <stuartdouglas> cause only one instance of the managed bean client interceptor is created[01:00:06] <Nihility> it looks like the proxy is supposed to be the associated view[01:02:07] <Nihility> stuartdouglas: well from the servlet perspective, a new component instance should be created by the web code right[01:03:12] <Nihility> i guess in CDI's case it should not[01:03:52] <stuartdouglas> yea, the web code should trigger the instance creation[01:04:00] <dmlloyd> stuartdouglas: really? it should be using the embedded interceptor factory....[01:04:07] <stuartdouglas> my WebComponent components don't have views[01:04:31] <stuartdouglas> but it is only called once, in the ProxyInvocationHandler constructor[01:04:55] <stuartdouglas> which means there is only one instance of the Client interceptor[01:05:02] <stuartdouglas> and therefore, only one component[01:06:07] *** maxandersen has joined #jboss-as7[01:06:07] *** ChanServ sets mode: +v maxandersen[01:06:14] <dmlloyd> hm well I guess constructing multiple instances is ok[01:06:16] * dmlloyd fix...[01:07:22] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/b3cee44[01:07:22] <jbossbot> git [jboss-as] b3cee44.. David M. Lloyd Create a new invocation handler per proxy[01:07:31] <dmlloyd> ok?[01:07:51] *** emuckenhuber has quit IRC[01:08:26] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/88dd4d2 <- same but with a whitespace fix[01:08:27] <jbossbot> git [jboss-as] 88dd4d2.. David M. Lloyd Create a new invocation handler per proxy[01:08:30] <Nihility> sounds right as long as we always reuse proxies[01:08:41] <Nihility> for components that are singletons[01:08:47] <dmlloyd> we don't, we create new proxies[01:10:21] <stuartdouglas> yea, although now the private data is per proxy instance[01:11:04] <Nihility> it looks like its just a copy[01:11:11] <Nihility> so no real harm[01:11:47] <dmlloyd> yes[01:12:04] <dmlloyd> the private data has to be per-proxy otherwise it defeats the point of associating data with the proxy instance[01:12:14] <dmlloyd> which can then be passed to the component association logic[01:12:40] <dmlloyd> with MBs we cheat because we just create a new CI per proxy but that's the only component type that we really would cheat like that[01:12:50] <dmlloyd> well, the only JNDI-bound type[01:13:10] <dmlloyd> it's kinda interesting that every other component type is different[01:13:15] <dmlloyd> SLSB, SFSB, SiSB[01:13:24] <dmlloyd> EBs :)[01:13:41] <stuartdouglas> interesting is not the word I would pick :-)[01:14:18] <Nihility> i would go with "silly"[01:14:35] <Nihility> lests see[01:14:42] <Nihility> one way is doing new Class()[01:15:07] <Nihility> the other is a complex multi step process and a global registry[01:15:08] <dmlloyd> one way of what[01:15:42] <Nihility> so of course users need the complex multi step process to create a javabean![01:15:43] <Nihility> :)[01:15:47] <dmlloyd> :D[01:16:15] <Nihility> the funny thing is[01:16:27] <Nihility> you cant even change the type[01:16:49] <dmlloyd> change the type of what[01:16:55] <Nihility> the managed bean[01:17:03] <stuartdouglas> ?[01:19:03] *** emuckenhuber has joined #jboss-as7[01:19:04] *** emuckenhuber has joined #jboss-as7[01:19:04] *** ChanServ sets mode: +v emuckenhuber[01:19:35] <Nihility> i just mean that one would think the value of avoiding the new class in favor of injection[01:19:42] <Nihility> is hiding implementation details[01:19:57] <Nihility> obviously thats why you dont want a new Class() right?[01:20:34] <Nihility> so you can do an interface on the calling side[01:20:39] *** maxandersen has quit IRC[01:20:41] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/4c3ed47[01:20:42] <jbossbot> git [jboss-as] 4c3ed47.. David M. Lloyd This is much less anti-non-unefficienter[01:21:28] * stuartdouglas feels kinda unefficienter at the moment[01:22:06] <dmlloyd> mmm, dinner[01:22:09] <dmlloyd> o/[01:22:13] <Nihility> i should try eating[01:28:06] *** bstansberry is now known as bstans_food[01:45:33] <Nihility> i was just thinking about @Resource Queue[01:46:23] <Nihility> we cant depend on a specific queue but we can depend on the messaging subsystem as a whole[01:46:27] <Nihility> i wonder if that is worth it though[02:09:15] *** bstans_food is now known as bstansberry[02:27:37] <Nihility> so basically ive determined today[02:28:27] <Nihility> that DataSourceDefinition is going to require creative solutions to implement it right[02:28:44] <Nihility> it refers directly to the jdbc class[02:28:56] <Nihility> by name[02:29:04] <Nihility> so will need to have auto-imports or something[02:41:52] <Nihility> its also in the deployment descriptors[02:42:03] <Nihility> so we dont need a special ds.xml thing[02:42:11] <Nihility> "A DataSource resource may be defined in a web module, EJB module, application client module, or application deployment descriptor using the data- source element."[02:43:03] <Nihility> i figure we can do one of two things[02:43:25] <Nihility> 1) require a module import on a jdbc deployment[02:44:05] <Nihility> 2) make jdbc deployment classes be global unique names (not such a great idea)[02:44:32] <Nihility> well there is also a third option[02:44:52] <Nihility> 3) add a vendor element to say what module name the classname refers to[02:45:35] <stuartdouglas> it would be neat if this could just work, without needing to wire up dependencies[02:46:24] <Nihility> thats 2 basically[02:51:53] <Nihility> hmm[02:51:58] <Nihility> i guess we actually do that[02:52:05] <Nihility> see DriverProcessor.java[02:52:51] <Nihility> so solution i guess is look it up by service[02:53:24] <stuartdouglas> yea, there is not really a use case for having two different versions of the same driver is there?[02:53:48] <Nihility> im more worried about two drivers picking the same class name[02:54:06] <stuartdouglas> unlikely[02:54:18] <Nihility> something like[02:54:28] <Nihility> database.driver[02:54:28] <Nihility> haha[02:54:41] <smarlow> the only case I know of, isn't that strong. if you wanted to apps deployed against two versions of Oracle. You might have a different oracle driver for each version[02:54:44] <stuartdouglas> then they deserve what they get :-)[02:55:13] <Nihility> actually it does have version support[02:55:23] <Nihility> but the annotation does not[02:55:30] <Nihility> so we would have to declare that elsewhere[02:55:39] <Nihility> it trusts the jdbc4 descriptor as to what the version is[02:55:53] <Nihility> smarlow: yeah like thin and fat oracle or something[02:56:16] <Nihility> i guess im being paranoid for no good reason[02:56:23] <Nihility> historically people put drivers in /lib[02:56:30] <Nihility> thats about as global as you can get[02:56:31] <Nihility> :)[02:58:39] <smarlow> seems reasonable to start out with globally unique.[02:58:56] <Nihility> the other thing that bugs me[02:59:05] <Nihility> is that DataSourceDefinition isnt really a component[02:59:36] <Nihility> im about to nuke this description[02:59:40] <Nihility> i just dont think it makes sense[03:01:19] <Nihility> i think this should just be a deployer[03:01:28] <Nihility> that creates a bindingdescription[03:01:50] <Nihility> the only problem is where to put it[03:02:14] <Nihility> eclipse is pissed i deleted code[03:02:26] <Nihility> its now hanging[03:02:42] <stuartdouglas> It does that a lot, I don't miss it at all[03:04:47] <Nihility> lol restarted it[03:04:50] <Nihility> and now its like[03:04:57] <Nihility> "building workspace 0%"[03:06:21] <Nihility> stuartdouglas: my crazy thinking is to treat this like a @Resource, and have it's scope associated witht eh component declaring it[03:07:27] <stuartdouglas> sounds reasonable[03:07:31] <stuartdouglas> brb[03:10:28] * stuartdouglas back[03:13:01] <Nihility> yeah i think it will work like this[03:19:25] *** miclorb_ has joined #jboss-as7[03:35:41] *** smarlow has quit IRC[03:56:16] *** jpearlin has left #jboss-as7[04:06:15] <Nihility> dmlloyd: i think we need to make AbstractInjectableDescription.bindings be a map, if we want a separate annotation and xml phase[04:07:19] <Nihility> although im not totally sure yet[04:07:40] <Nihility> need to verify they are all indexed uniformally[04:11:37] *** smarlow has joined #jboss-as7[04:11:37] *** ChanServ sets mode: +v smarlow[05:03:28] <Nihility> hmm[05:03:33] <Nihility> well it turns out[05:04:13] <Nihility> the className in DSDefinition points to a DataSource type and not a Driver type (duh), and there is no way to go from Driver to DS (more than one possible)[05:05:31] <Nihility> so that means we either have to scan all classes in a driver[05:05:33] <Nihility> and find them[05:05:45] <Nihility> put them in a registry[05:05:51] <Nihility> or import all jdbc drivers[05:06:35] <Nihility> (into connector and potentially the deployment)[05:12:30] <smarlow> does adding new jdbc driver updates influence this at all? Can someone install a new jdbc driver and have the registry update or that driver reimported into which ever connector/deployments consumed it before?[05:14:22] <smarlow> a global registry sounds practical but reimporting into the consuming connector/deployments sounds more modular (if there aren't too many edge cases).[05:36:04] <Nihility> yeah basically a deployment would have deps on a datasource service[05:36:21] <Nihility> and then the driver service would have to create additional services[05:36:37] <Nihility> so yeah in a nutshell[05:36:42] <Nihility> you can deploy new ones[06:26:52] *** bstansberry has quit IRC[06:44:11] *** smarlow has quit IRC[07:21:14] *** miclorb_ has quit IRC[07:21:40] *** wmprice has joined #jboss-as7[07:22:17] <wmprice> So, why is JDBC special, and what does it warrant?[07:27:15] *** wmprice has left #jboss-as7[07:54:03] *** Nihility has quit IRC[07:56:25] *** Nihility has joined #jboss-as7[07:56:25] *** Nihility has joined #jboss-as7[07:56:25] *** ChanServ sets mode: +v Nihility[08:22:28] <Nihility> Ok so it looks like this needs to be wired straight to jdbc[08:24:00] <Nihility> doing it any other way would be a pain and not add a ton of value[08:43:38] *** jfclere has quit IRC[13:50:36] *** maxandersen has joined #jboss-as7[13:50:36] *** ChanServ sets mode: +v maxandersen[14:03:58] *** maxandersen has quit IRC[14:26:25] *** smarlow has joined #jboss-as7[14:26:25] *** ChanServ sets mode: +v smarlow[14:48:27] <smarlow> what should happen if a (transactional) PersistenceContext is injected into a MB? Clearly, only SFSBs will support Extended PersistenceContext but I'm wondering if I could continue my JPA integration with MBs, while waiting for WEB component changes to come in.[14:52:35] <smarlow> Also, for WEB integration, I need a WEB valve/filter in the JPA module that is wired in somehow (via configuration or injection). Suggestions on the best way is welcome (maybe there is a WEB server.xml somewhere I can hack into).[15:21:50] *** pferraro has joined #jboss-as7[15:21:50] *** ChanServ sets mode: +v pferraro[15:26:52] <smarlow> If I could generically, get wired into intercept WEB/EJB3 at the component level, even better. This would be for tracking non-transactional PersistenceContext usage (so we can close PC or discard references to the XPC at invocation end time)[15:31:12] *** pferraro has quit IRC[15:54:47] *** bstansberry has joined #jboss-as7[15:54:47] *** ChanServ sets mode: +v bstansberry[16:10:36] *** jpearlin has joined #jboss-as7[16:25:01] <Nihility> there is a component interceptor layer for all ee components[16:28:41] <Nihility> Web isn't integrated yet stuartdouglas is working on that he has a patch already[16:29:37] <Nihility> But we cant do method interception in all cases because servlets can be final[17:03:04] *** darranl has joined #jboss-as7[17:03:05] *** darranl has joined #jboss-as7[17:03:05] *** ChanServ sets mode: +v darranl[17:31:53] <smarlow> hmm, so I have some choices for integration. I would want to inject PersistenceContexts into final servlets, so maybe a WEB valve/ is best (so we can handle the closing/releasing the PC/XPC respectively after non transactional invocations end). Could even do both, to cover most other cases, include the same case for EJB3.[17:45:58] <jpearlin> Nihility: I pushed the first cut of the deployment upload support in the HTTP API to github: https://github.com/jdpgrailsdev/jboss-as/commit/6f9370c8d0fe589263b6993007180dbcadf31667[17:45:59] <jbossbot> git [jboss-as] 6f9370c.. Jonathan Pearlin Modified HTTP API to support uploading of deployment via form POST....[17:46:26] <Nihility> Awesome[17:46:42] <jpearlin> once you get a chance to look at it, let me know what needs to be fixed/modified[17:46:48] <jpearlin> I made a bunch of assumptions as I went[17:47:03] <jpearlin> right now, it just spits back the DMR string as a response[17:47:15] <jpearlin> so we will certainly need to revisit that at some point when we know more about the management console[17:47:38] <Nihility> I was about to go to the store to buy drinks but I can stick around if this time works better[17:48:29] <jpearlin> I also noticed that the second impl of the base64 stuff never got merged...is there anything else you need me to do on that front?[17:48:58] <Nihility> smarlow: You can still inject at lifecycle boundaries you just can't intercept every servlet call. How did this work in 6?[17:49:26] <Nihility> jpearlin: No I just need to merge it I'll do that one[17:49:28] <Nihility> Now[17:50:28] <Nihility> After I make another espresso :)[17:51:46] <jpearlin> ha...no problem...just wanted to make sure I didn[17:51:51] <jpearlin> oops...didn't miss something[17:52:15] <jpearlin> I'm going to tinker around with making some tests for the upload stuff[17:52:19] <jpearlin> that should buy you some time ;)[17:52:36] <Nihility> With this machine it literally takes 2 mins[17:53:10] <Nihility> The coffee not the merge[17:56:19] <Nihility> Nothing like snowplowing slush snow[17:56:27] <Nihility> Actually snow blowing[17:57:02] <Nihility> I keep wishing summer was here but then I would be mowing.....[18:01:06] *** frainone has joined #jboss-as7[18:01:06] *** ChanServ sets mode: +v frainone[18:13:42] <Nihility> its taking a bit longer to merge this since you have merge commits in here[18:13:50] <Nihility> well luckily just one[18:18:45] <jpearlin> sorry about that[18:27:22] <jbossbot> git [jboss-dmr] push master 07b3200.. Jonathan Pearlin Modified to use new Base64 utility class....[18:27:22] <jbossbot> git [jboss-dmr] push master 59939a0.. Jonathan Pearlin Added close method to stream to not propogate close call to internal stream.[18:27:22] <jbossbot> git [jboss-dmr] push master 27296ff.. Jonathan Pearlin Removed use of DataInputStream and DataOutputStream.[18:27:22] <jbossbot> git [jboss-dmr] push master d0b8463.. Jonathan Pearlin Reversed order of loop in findActualEncodedBlockSize to look from end of array.[18:27:22] <jbossbot> git [jboss-dmr] push master 8e4bc55.. Jonathan Pearlin Changed to only clear buffer for encoding when less than the full block is read....[18:27:23] <jbossbot> git [jboss-dmr] push master 48f6774.. Jonathan Pearlin Modified encode and decode to pass in input and output buffers as parameters....[18:27:23] <jbossbot> git [jboss-dmr] push master URL: http://github.com/jbossas/jboss-dmr/compare/d7ec04c...48f6774[18:27:34] <Nihility> three way rebase saves the day[18:28:06] <Nihility> jpearlin: thanks[18:28:12] <jpearlin> no problem[18:28:50] <Nihility> i preserved your history[18:28:53] <Nihility> instead of squashing it[18:29:07] <Nihility> in case you need to look into a change[18:29:33] <Nihility> ok so the other patch[18:31:51] <Nihility> oh so the boundary stream came in handy[18:31:52] <Nihility> ?[18:31:58] <jpearlin> yes[18:32:04] <jpearlin> I had a bunch of custom code in there at first...[18:32:08] <jpearlin> but was able to replace it with it[18:32:31] <jpearlin> it got rid of about 50 lines[18:32:46] <jbossbot> git [jboss-as] push master 88dd4d2.. David M. Lloyd Create a new invocation handler per proxy[18:32:46] <jbossbot> git [jboss-as] push master 4c3ed47.. David M. Lloyd This is much less anti-non-unefficienter[18:32:47] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/96f4c9e...4c3ed47[18:34:26] <Nihility> i love it when stuff i write years ago becomes handy again[18:34:47] <jpearlin> amazing...right...nothing like avoiding re-inventing the bicycle[18:35:00] <Nihility> i wish i would have saved all kinds of things ive written[18:35:57] *** darranl has quit IRC[18:37:25] <Nihility> jpearlin: ok so did you do like an html test form to verify it works?[18:38:18] <jpearlin> yes...but its not in the patch[18:38:30] <jpearlin> I created a simple web page that posts to the domain-api with the correct operation[18:38:33] <Nihility> doesnt need to be[18:38:37] <Nihility> just wondering[18:38:43] <jpearlin> and uploaded a WAR and verified I could open the WAR under the data folder[18:38:47] <jpearlin> when the domain operation moves it to[18:39:07] <Nihility> ok so i am wondering[18:39:31] <Nihility> where you seeing a multipart post with one part[18:39:33] <Nihility> (the file?)[18:39:35] <jpearlin> yes[18:39:42] <jpearlin> so that could be an issue[18:39:51] <Nihility> ok so i take it there was no other post values right?[18:39:53] <jpearlin> and that's one of the assumptions I was allueding to earlier[18:39:54] <jpearlin> right[18:40:04] <dmlloyd> it'd be simple enough to do something like: className="com.oracle.FooDriver" == latest version available, className="com.oracle.FooDriver:10.0" == version 10.0 exactly[18:40:08] <jpearlin> so we may need to revisit that depending on what the front end is going to do[18:40:56] <jpearlin> Nihility: this all basically goes back to about a week ago when I was asking about the name and display name parameters (if we needed those and if they would be in the post data coming from the console)[18:41:02] <Nihility> dmlloyd: right but the problem is that DataSourceDefinition doesnt take Driver types it takes jdbc implementation specific DataSource types, so the only way we handle that is to type scan all jdbc drivers and maintina a map of everything that implements DataSource[18:41:19] <jpearlin> when we removed those, I went with the assumption that the form post would only have the content as the only param[18:42:17] <Nihility> dmlloyd: if you follow the rest of my incoherent rambling its that we cant use JCA to provide these datasources (well at least reliably)[18:42:29] <Nihility> dmlloyd: so im just going to implement this as direct JDBC[18:43:09] <Nihility> jpearlin: right yeah, this is fine for now, i was just wondering[18:43:39] <jpearlin> Nihility: ok, so yes, the assumption is a multipart/form with one boundary with the content only at this point[18:43:52] <jpearlin> but, that is where your class will come in handy if we have multiple params ;)[18:43:56] <Nihility> jpearlin: IIRC in such a scenario the first part would be the form thing, and the second the file[18:44:16] <dmlloyd> Nihility: okay well tbh I don't have any problem with requiring an explicit Dependency or Class-Path for @DataSourceDef[18:44:50] <Nihility> dmlloyd: i think using jande on jdbc drivers would be fairly efficient, it will notice there is no annotaitons and skip a huge chunk of processing[18:45:10] <jpearlin> Nihility: yes...I believe you are correct...the params would be in one of the multipart sections, followed by a section for the content[18:45:11] <Nihility> dmlloyd: the idea would be to then create services for every DataSource implementing type[18:45:19] <jpearlin> I can modify my test page if you would like me to verify[18:45:19] <dmlloyd> if we're doing something different between @DSDef and domain data sources, that's bad[18:45:36] <Nihility> dmlloyd: and then we can not only wire the module deps, we can wait on the jdbc driver[18:46:26] <Nihility> dmlloyd: the problem is the contracts are fundamentally difference[18:46:30] <Nihility> different[18:46:39] <Nihility> in one case we are implementing DataSource[18:46:49] <Nihility> in the other we are passing along the jdbc's impelementation[18:47:23] <Nihility> jpearlin: yeah if you dont mind seeing what happens[18:47:45] <dmlloyd> hmm[18:47:50] <jpearlin> sure...will do[18:47:59] <dmlloyd> well I still think we should require the user to do the class-path shit...[18:48:03] <Nihility> dmlloyd: i was actually surprised, i couldnt believe i didnt notice this[18:48:37] <Nihility> dmlloyd: funny because i thought i was going to just knock this out[18:49:01] <Nihility> dmlloyd: if we look at the use case, its for rapid development right[18:49:25] <Nihility> dmlloyd: not only is it in the annotation, its also in web.xml, application.xml and ejb-jar.xml[18:49:51] <Nihility> dmlloyd: so we could say, oh just put your jdbc driver in your deployment if you are doing this[18:49:55] <Nihility> (or add a module dep)[18:49:57] <jpearlin> Nihility: Looks like we get a different section for each parameter (i.e. if you have 3 inputs to the form, you get 3 sections in the post data)[18:50:10] <Nihility> oh really didnt realize that[18:50:25] <Nihility> jpearlin: ok maybe this should change to find the upload part and skip the rest[18:50:45] <Nihility> im guessing it could be by content-type?[18:50:55] <Nihility> does it show up ass octet-stream?[18:51:04] <jpearlin> perhaps...or the name of the parameter[18:51:15] <jpearlin> let me see what the content shows up as[18:52:49] <Nihility> dmlloyd: the only thing that sucks about that, is then we have this fancy jdbc driver thing thats not used for these deployments[18:53:15] <Nihility> dmlloyd: if we did the scanning and discovered datasources, we would get the same version management features[18:53:45] <Nihility> however im not sure how that would work with in-jar deployment[18:54:00] <Nihility> but yeah the first pass i was going to do exactly what you suggest[18:56:16] <Nihility> jpearlin: hey btw to prevent those merge commits from happenig, make sure you do git pull --rebase upstream master, or alternatively don't use pull ever, and instead use either merge --ff-only or rebase[18:56:41] <Nihility> this is gaurnteed to always work:[18:56:46] <Nihility> git fetch upstream[18:56:52] <Nihility> git rebase upstream/master[18:57:08] <Nihility> (i mean you never get a merge commit)[18:57:30] <Nihility> i wonder if there is a way to set ff-only to be on always in git with merge[19:02:54] <jpearlin> ok...I have been using fetch[19:02:56] <jpearlin> but not rebase[19:10:51] <Nihility> fetch is right[19:10:59] <Nihility> just need to use rebase instead of merge[19:11:14] <Nihility> basically the only time to use merge is if you do --ff-only[19:11:18] <Nihility> (fast forward)[19:11:40] <Nihility> but rebase does the same step (less pretty output)[19:12:23] <Nihility> some people create an alias to make this simple[19:13:23] <Nihility> git config alias.up pull --rebase upstream master[19:13:31] <Nihility> then you do git up[19:13:33] <Nihility> in your tree[19:13:37] <Nihility> and it will just do the right thing[19:13:53] <jpearlin> ok...I just did the rebase and saw the pain I caused ;)[19:14:34] <Nihility> its not too bad when there is one merge commit[19:14:44] <Nihility> but when you have interleaved ones its a royal pita[19:14:46] <jpearlin> yeah...but its totally avoidable[19:14:48] <jpearlin> yeah[19:15:19] <Nihility> an easy way you can verify it to btw[19:15:23] <Nihility> is to a git log[19:15:29] <Nihility> and see if there is a merge commit in there[19:15:50] *** ccrouch has joined #jboss-as7[19:15:50] *** ChanServ sets mode: +v ccrouch[19:16:53] *** jamezp has joined #jboss-as7[19:17:30] <jpearlin> grr...eclipse[19:17:49] <jpearlin> I love how stop means eventually in eclipse[19:18:11] <jpearlin> its like it is a 4 year old...you need to tell it 5 times to actually get it to stop[19:23:49] <Nihility> yeah[19:23:56] <Nihility> only advice i can give you[19:24:02] <Nihility> is switch to intellij[19:24:08] <Nihility> i plan to[19:24:14] <Nihility> im fed up with eclipse[19:24:17] <jpearlin> ha...we actually used that at work for a while before switching to eclipse[19:24:29] <jpearlin> but that was a long time ago (and many versions ago)[19:24:44] <Nihility> although to be fair most of the problems i have are with m2e and not eclipse[19:24:48] <jpearlin> yes[19:25:08] <Nihility> they have significantly improved idea[19:25:12] <Nihility> its insanely fast[19:25:48] <Nihility> AS6 is practically impossible to use with eclipse[19:25:54] <Nihility> AS7 is better[19:25:54] *** jamezp has quit IRC[19:25:59] <Nihility> but it still struggles[19:26:11] <jpearlin> yeah...one trick is turn off all the auto-building nonsense[19:26:24] <jpearlin> and use cli for actually building[19:27:02] *** jamezp has joined #jboss-as7[19:29:25] <dmlloyd> Nihility: detecting DataSource is fine but if we do it I think we should only use the SPI mechanism rather than doing something funky with jandex[19:29:43] *** maxandersen has joined #jboss-as7[19:29:43] *** ChanServ sets mode: +v maxandersen[19:29:51] <dmlloyd> Nihility: also, I have my thing set to ff-only by default, it is possible[19:29:55] <dmlloyd> it's a branch setting[19:30:05] <Nihility> dmlloyd: there is no SPI unfortunately[19:30:16] <Nihility> dmlloyd: which is insanely annoying![19:30:16] <dmlloyd> well anyone *can* use SPI[19:30:29] <dmlloyd> if they choose not to, then too bad, you have to specify a dep[19:30:59] <Nihility> dmlloyd: no i mean that its not in the spec[19:31:06] <dmlloyd> I'm aware of that[19:31:19] <dmlloyd> I however planned to do Driver SPI whether or not it was in the spec :)[19:31:28] <dmlloyd> anyway once we start auto-detecting data sources, pretty soon we are going to be auto-detecting lots of stuff and that makes it pretty hard to *exclude* things[19:31:41] <dmlloyd> I think we should draw the line at SPI[19:32:57] <Nihility> yeah the alternative is to define our own spi and then provide service files for all common jdbc drivers[19:33:05] <Nihility> and try to get it in the spec[19:34:28] <smarlow> Nihility: I don't think AS6 did the same clean up after servlet invocations but I might of missed it.[19:34:30] <Nihility> but yeah assuming we did scan, the worst case is that someone could write to an internal type that happens to be public and implement datasource[19:35:09] <Nihility> the thing i dont like is pointless scanning[19:35:12] <smarlow> I do want lifecycle boundary interceptions but only for SFSBs (for extended persistence context management).[19:35:25] <Nihility> but yeah im going for explicit import, or in-deployment right now[19:48:39] *** jpearlin has quit IRC[19:52:03] *** jpearlin has joined #jboss-as7[19:52:40] <Nihility> ok im going to run to pick up food and drinks will bbiab[20:00:52] *** Nihility has quit IRC[20:07:01] *** Nihility has joined #jboss-as7[20:07:01] *** ChanServ sets mode: +v Nihility[20:13:44] *** Tashtego has joined #jboss-as7[20:16:20] *** smarlow has quit IRC[20:31:14] <Nihility> Morning stuartdouglas[20:32:05] <Nihility> I'm awaiting Chinese and will be back soon[20:33:12] <Nihility> maxandersen: We found that bug you hit. Tight loop in descriptor parsing[20:33:44] <Nihility> delete the loader repository section to work around[20:34:03] <Nihility> its not used anyway[20:34:34] <jpearlin> Nihility: not sure if I'm going to be able to get that answer for you on how to parse out only the content from the form post...[20:34:45] <jpearlin> running into a ton of failing tests after the rebase[20:43:28] <Nihility> no big deal although are you sure it was real conflicts[20:43:39] <Nihility> or did the rebase not apply cleanly[20:43:54] <Nihility> i can give you tips on how to rebase trees with merge commits[20:44:30] <Nihility> if you have not pushed you can put your work in a branch, restore your last push[20:44:41] *** mbg has joined #jboss-as7[20:44:42] *** ChanServ sets mode: +v mbg[20:44:44] <Nihility> and then cherry-pick each commit after the merge[20:44:46] <Nihility> OR[20:44:49] <Nihility> a three way rebase[20:45:17] <Nihility> git rebase --onto master <merge commit id> your-branch[20:45:22] <Nihility> (while you are in your branch)[20:45:35] <jpearlin> no...it looks like it might have been eclipse[20:45:53] <jpearlin> although eclipse doesn't like the "lookup" attribute in the @Resource annotation in BeanWithSimpleInjected.java[20:46:07] <jpearlin> eclipse was locking some files, causing tests to fail to delete things[20:46:12] <Nihility> thats because the jdk @resource is differnt[20:46:17] <jpearlin> right...[20:46:26] <jpearlin> so I think it just might be my environment causing things to fail[20:46:33] <jpearlin> since everything is compiling properly[20:46:47] <Nihility> you might have to reimport all projects[20:47:01] <Nihility> otherwise what you can do[20:47:03] <jpearlin> well...the tests are failing via the maven cli[20:47:17] <Nihility> is in the project thats using the @Resource[20:47:25] <Nihility> you can add an exclude filter[20:47:33] <Nihility> to your JDK library[20:47:39] <Nihility> and just filter it out[20:47:48] <jpearlin> yeah...im not too concerned about that[20:48:05] <jpearlin> I'm more concerned as to why all of a sudden I can't build via Maven ;)[20:48:20] <Nihility> do a git status[20:48:25] <jpearlin> something keeps locking cal10n-api-0.7.2.jar from delete[20:48:26] <Nihility> see if you have extra files[20:48:26] <jpearlin> ok[20:48:47] <jpearlin> no extra files[20:49:14] <Nihility> you might want to shutdown eclipse and do a clean install[20:49:26] <Nihility> i mean ./build.sh clean install[20:49:29] <Nihility> (or mvn clean install[20:49:29] <jpearlin> right[20:50:02] <Nihility> windows locking blows[20:50:13] <jpearlin> yup[20:50:22] <jpearlin> something is spawning extra java processes[20:50:24] <jpearlin> that it doesn't like[20:50:38] <jpearlin> most likely the tests[20:51:41] <Nihility> yeah you could have found a windows bug[20:51:48] <jpearlin> yup...its always the same...[20:51:49] <Nihility> we still dont have a windows hudson run[20:51:53] <jpearlin> one of the tests freezes[20:52:03] <jpearlin> and then its all over[20:52:10] <Nihility> ah which one[20:52:24] <jpearlin> looks like ExistingConnectionRemoteProxyControllerTestCase[20:52:36] <jpearlin> it gets an EOFException[20:52:38] <jpearlin> then the whole build just hangs[20:53:31] <Nihility> ah well you could just disable that test in your tree[20:54:20] <jpearlin> seems like a total race condition, as some times it gets by it[20:54:24] <jpearlin> if I run it enough times in a row[20:54:40] <Nihility> bstansberry: ^ you seen that one?[20:55:28] <bstansberry> I wonder if that's the one jaikiran reported[20:55:44] <jpearlin> and of course now I can't reproduce it ;)[20:56:47] * bstansberry looks[20:56:48] <jpearlin> Nihility: I'm going to try to at least get you another patch today that takes care of the merging issues (so that my branch should be in sync with master, plus corrections for removing those parameters from the upload operation)[20:57:26] <Nihility> jpearlin: ok whenever its convenient for you. im going to be online all day[20:57:49] <jpearlin> sounds good[20:58:01] <jpearlin> if this every builds for me, I'll also get you the answer on the content-type[20:58:11] <jpearlin> every=ever[20:58:21] <Nihility> oh btw if the tests get in the way[20:58:29] <jpearlin> already tried mvn.skip.tests[20:58:30] <Nihility> you can just do -Dmaven.test.skip.exec[20:58:40] <jpearlin> ah..didn't know about .exec[20:58:44] <Nihility> either will work[20:58:54] <Nihility> the difference is whether or not it compiles them[20:58:58] <jpearlin> yeah...skipping the tests didn't fix the delete problem for some reason[20:59:01] <jpearlin> before[20:59:09] <jpearlin> I think that was eclipse[20:59:39] <jpearlin> woo hoo...build success![21:00:47] <jpearlin> Nihility: Content-Type: application/octet-stream[21:01:04] <jpearlin> we also get the param name and the filename[21:01:12] <jpearlin> so, we could look for any of those, I suppose[21:09:42] <Nihility> hmm interesting file name[21:09:51] <Nihility> i wonder if thats a standard parameter[21:09:56] <Nihility> or if its just in the form[21:10:21] <Nihility> if its standard the combination of fille name + octet stream is a pretty good indicator[21:10:55] <jpearlin> its not part of the form...[21:10:59] <jpearlin> but it could be browser specific[21:11:12] <jpearlin> let me do some digger[21:11:14] <jpearlin> digging[21:11:24] <jpearlin> here is the patch after the merge: https://github.com/jdpgrailsdev/jboss-as/commit/3887ea8b28fca74516a99d0d48f6584b9a075d71[21:11:25] <jbossbot> git [jboss-as] 3887ea8.. Jonathan Pearlin Merged changes from upstream/master....[21:12:54] <jpearlin> ah...filename is not gauranteed, according to w3c[21:13:33] <jpearlin> it could be in a couple of places, depending on how many files are sent in the post[21:14:27] <jpearlin> "The user agent should attempt to supply a file name for each submitted file. The file name may be specified with the "filename" parameter of the 'Content-Disposition: form-data' header, or, in the case of multiple files, in a 'Content-Disposition: file' header of the subpart"[21:15:17] <jpearlin> sounds like your first take was right (using the content type): "If the contents of a file are submitted with a form, the file input should be identified by the appropriate content type (e.g., "application/octet-stream"). If multiple files are to be returned as the result of a single form entry, they should be returned as "multipart/mixed" embedded within the "multipart/form-data"."[21:21:06] <jpearlin> bstansberry: I was able to reproduce that error in ExistingConnectionRemoteProxyControllerTestCase...would you like me to save off the stack trace/log a JIRA issue for it?[21:21:20] <bstansberry> yes, please[21:21:26] <bstansberry> was that in a rebased branch?[21:21:42] <jpearlin> yes...but I was seeing it periodically before the rebase[21:22:20] <bstansberry> sure; I just remember some changes last week that might have fixed it, so wanted to check if you had the latest[21:23:03] <jpearlin> yes...I believe that I have the latest stuff....what would you like me to do with the trace?[21:23:20] <bstansberry> attach to the JIRA[21:23:36] <jpearlin> ok...will do[21:23:37] <jpearlin> thanks[21:29:50] <stuartdouglas> morning Nihility[21:30:11] <stuartdouglas> I have my latest web components patch at https://github.com/stuartwdouglas/jboss-as/tree/webComponents[21:30:19] <jpearlin> bstansberry: https://issues.jboss.org/browse/JBAS-8930[21:30:21] <jbossbot> jira [JBAS-8930] ExistingConnectionRemoteProxyControllerTest periodically freezes during build on Windows [Open (Unresolved) Bug, Minor, Shelly McGowan] https://issues.jboss.org/browse/JBAS-8930[21:31:07] <bstansberry> thanks! yep; that's exactly what Jaikiran saw[21:31:21] <jpearlin> no problem[21:31:38] <jpearlin> its very random...if I kill the build and just rebuild, it usually goes away[21:34:18] <Nihility> hmm[21:34:55] <Nihility> stuartdouglas: looks fine, if it merges and works ill push it (unless dmlloyd objects and wants to review it)[21:35:24] <stuartdouglas> I made some changes to JNDIInjectable[21:35:33] *** FordPrefect has joined #jboss-as7[21:35:46] <Nihility> hmm i missed that[21:35:47] <Nihility> let me see[21:36:04] <stuartdouglas> cause it had a similar problem to the tomcat InstanceManager, in that you need to maintain a map of instance -> component instance[21:36:20] <stuartdouglas> now it returns a reference, that you can call release on[21:37:35] <dmlloyd> I need to think about that a bit[21:37:44] <dmlloyd> there was a really good reason I didn't do it that way to begin with[21:37:48] <dmlloyd> just have to remember what it was...[21:37:53] <stuartdouglas> hehe[21:38:42] <Nihility> it seems like the intent is that everything would have the component instance[21:38:44] <Nihility> right[21:38:46] <Nihility> ?[21:39:15] <dmlloyd> no, there isn't a 1:1 relationship between injected object and component instance[21:39:47] <stuartdouglas> yea, although for some things there is[21:40:11] <stuartdouglas> so for managed beans you can just release to component when the object that is being injected into goes away[21:40:21] <stuartdouglas> for other things it is not that simple[21:40:46] <dmlloyd> for things with proxies you can attach stuff which makes that pretty easy[21:41:02] <dmlloyd> it's things without proxies where the instance is unmanaged where there's a prob[21:41:50] <Nihility> in servlets the instance is managed though[21:42:27] <Nihility> so it seems like this is once again working around the jbweb spi[21:43:11] <dmlloyd> tbh I'm not sure it's needed anyway[21:43:17] <stuartdouglas> not really, it is more of a general sort of problem where if you don't have proxies you can't attach extra data[21:43:20] <dmlloyd> because if it's bound into JNDI then it's a proxy[21:43:24] <dmlloyd> (the servlet I mean)[21:43:40] <dmlloyd> if the servlet isn't bound into JNDI then I don't see why we need JndiInjectable anyway[21:43:50] <Nihility> the only case of an unmanaged proxyless instance that i can think of is a managed bean wtihout interceptors[21:44:08] <dmlloyd> a managed bean without interceptors is still a proxy[21:44:40] <Nihility> ah that must have changed in the ee patch[21:44:49] <Nihility> it was at one point time not[21:45:05] <dmlloyd> a servlet will only ever be bound into JNDI if it is also a @ManagedBean, which is the only time anyone would attempt to manage the servlet lifecycle via JndiInjectable[21:45:12] *** maxandersen has quit IRC[21:45:31] <Nihility> in that case there is really nothing we have that is unmanaged and doesnt have a proxy[21:45:49] <Nihility> well env entires[21:45:57] *** FordPrefect has quit IRC[21:45:57] <stuartdouglas> in that case I will change it back, and attach the ComponentInstance to the private data of the proxy[21:46:19] <stuartdouglas> env entries do not need to be destroyed though[21:46:24] <Nihility> right[21:46:25] <dmlloyd> right[21:47:02] <Nihility> a resource reference perhaps[21:47:14] <Nihility> something with a msc value inejction[21:47:58] <dmlloyd> the returned reference idea may have merit[21:48:10] <dmlloyd> it's just going to need some careful consideration[21:48:20] <dmlloyd> since we need EJBs to work this week and all :)[21:48:27] <Nihility> rofl[21:48:50] <Nihility> do you remember what was wrong with it?[21:48:58] <Nihility> multiple bindings to the same location[21:48:59] <Nihility> ?[21:49:18] <dmlloyd> one problem with requiring the literal instance is that it may be hard to get ahold of - like in the case of injection you might only have the target field to look into for the original value, and it may have been changed by the user so it's not reliable[21:49:21] *** Tashtego has quit IRC[21:49:23] <dmlloyd> no, nothing like that[21:49:32] <dmlloyd> it's all pragmatic issues of tracking the references[21:51:46] *** FordPrefect has joined #jboss-as7[21:51:49] <Nihility> so if each component instance had a list of refs[21:51:50] <stuartdouglas> I don't think it will be any harder that tracking the instances[21:52:01] <stuartdouglas> unless we are going to rely on the user not changing the field[21:52:17] <dmlloyd> we definitely should not rely on that :)[21:52:39] <dmlloyd> yeah I guess the injection target will always be an object associated with a ComponentInstance[21:52:52] <dmlloyd> so if we keep a list of refs on each CI it could be OK[21:53:10] <dmlloyd> yes, ok, I think it can work[21:53:34] <dmlloyd> it _is_ a relatively small change I hope?[21:54:31] <Nihility> it should be[21:54:46] <stuartdouglas> yea, although I actually have JndiInjectable implements ManagedReferenceFactory[21:55:03] <stuartdouglas> as I needed to use references that can be released in a few placed[21:55:04] <dmlloyd> what's that?[21:55:26] <dmlloyd> oh a new interface[21:55:44] <stuartdouglas> yea[21:55:49] <dmlloyd> just make sure the reference release is idempotent[21:55:58] <dmlloyd> don't want to deal with double-uninject problems[21:56:59] <stuartdouglas> ok, it is not at the moment, and is probably something that will have to be address on a per use level[21:57:30] <dmlloyd> yeah if it's at least specified in the javadoc that's a start anyway[21:57:44] * dmlloyd is 100% certain that stuartdouglas has copious amounts of javadoc ;)[22:00:43] *** irooskov has joined #jboss-as7[22:04:36] <Nihility> there is also the injectionfactory thing thats in this patch[22:07:53] <dmlloyd> oh, there's a link[22:07:54] * dmlloyd looks[22:08:18] *** jamezp has quit IRC[22:09:10] <stuartdouglas> I did that to allow CDI to hook injectors in without adding dependencies on the CDI subsystem[22:09:10] <dmlloyd> how does ComponentInjector compare to org.jboss.as.ee.component.ResourceInjection...[22:09:41] <dmlloyd> disinject, heh[22:09:51] <dmlloyd> I think we use "uninject" elsewhere[22:10:06] <Nihility> deject[22:10:13] <dmlloyd> ComponentInjector looks awfully similar to JndiInjectable though[22:10:34] *** smarlow has joined #jboss-as7[22:10:35] *** ChanServ sets mode: +v smarlow[22:10:47] <stuartdouglas> yea, I wrote it back when JndiInjectable was different[22:10:55] *** emuckenhuber has quit IRC[22:10:57] <dmlloyd> which in turn is very similar to ManagedReferenceFactory[22:11:04] <dmlloyd> we should just flatten those all into one[22:11:24] <dmlloyd> ManagedReference could just be Injected or something like that[22:12:37] * dmlloyd brb[22:19:47] <stuartdouglas> Actually I think there is enough difference between ComponentInjector and ManagedReferenceFactory to justify two interfaces[22:22:58] *** emuckenhuber has joined #jboss-as7[22:22:58] *** ChanServ sets mode: +v emuckenhuber[22:25:34] <dmlloyd> I don't understand why you need the service name[22:25:40] <dmlloyd> on ComponentInjector[22:27:22] <stuartdouglas> because the injector was also a service, so the object being injected into needs to set up it's dependencies on the injector[22:27:58] <stuartdouglas> even if the injector was not a service, it would still need a dependency on the BeanManager service[22:28:48] <dmlloyd> yeah but BindingDescription covers pretty much any dependency type[22:29:05] <dmlloyd> even if it doesn't actually bind :)[22:30:03] <stuartdouglas> how does that help with setting up msc deps?[22:30:30] *** opalka has joined #jboss-as7[22:30:30] *** opalka has joined #jboss-as7[22:30:30] *** ChanServ sets mode: +v opalka[22:31:50] <dmlloyd> you use a service source for your dependency[22:34:54] <stuartdouglas> All that seems to be very JNDI resource injection focused[22:37:39] <stuartdouglas> currently it looks like there is no way of cleaning up ResourceInjection when the component is destroyed?[22:38:07] <dmlloyd> not presently, but realistically it should be doing that[22:38:23] <dmlloyd> I expect having a list of injected refs will make that substantially more practical[22:39:58] *** mbg has quit IRC[22:41:18] <Nihility> note that we have to have a way to do that i think with DataSourceDefinition[22:41:37] <stuartdouglas> and extented persistence contexts[22:41:53] <Nihility> well we dont HAVE to[22:41:59] <Nihility> but if we can prevent leaking connections[22:42:02] <Nihility> thats probably a good thig[22:42:03] <Nihility> haha[22:42:12] <dmlloyd> the resource cleanup won't actually uninject from the methods/fields for sure, but we definitely need to cascade cleanup[22:42:45] <Nihility> hmm looks like i catn actually[22:43:00] <Nihility> the only way to do that is if have DataSource be a proxy[22:43:08] <Nihility> for what the jdbc driver provides[22:43:17] <Nihility> and then wrap the connections[22:43:26] <Nihility> future enhancement![22:45:01] <Nihility> im still fuzy about when extendedpresistencecontext is supposed to be cleared[22:47:13] <stuartdouglas> The persistence context is closed by the container when the @Remove method of the stateful session[22:47:13] <stuartdouglas> bean completes (or the stateful session bean instance is otherwise destroyed).[22:47:21] <stuartdouglas> JPA 7.6.2[22:47:42] <Nihility> yeah im aware of that one[22:47:50] <Nihility> but we also try to kill it in other cases[22:48:08] <Nihility> as an example smarlow was talking about a valve earlier[22:48:14] <smarlow> Nihility: yeah, we need to be careful with our references between XPC + sfsb beans[22:48:37] <stuartdouglas> Whats this about a valve?[22:48:55] <smarlow> Nihility: that was for the non-transactional case with a transactional persistence[22:49:51] <Nihility> so the PC is in a servlet?[22:49:55] *** jpearlin1 has joined #jboss-as7[22:50:00] <Nihility> thats the part i didnt follow[22:50:01] <smarlow> stuartdouglas: for tracking non-transactional PC invocations, so we can close/release the PC. I was thinking about the servlet case[22:50:55] <smarlow> if you embed the PC into a servlet, I was thinking that we would want to close/release the pc, like we would for a session bean invocation[22:51:03] <stuartdouglas> can't we just register a transaction synchronization?[22:51:07] <smarlow> release is for the xpc case[22:51:19] <smarlow> yes, for the transactional case[22:51:29] <smarlow> but this is for the non-transactional case[22:51:29] <stuartdouglas> cause the spec says 'If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database[22:51:29] <stuartdouglas> will immediately become detached at the end of the method call.'[22:51:47] <stuartdouglas> so in the PC proxy we can just call close() directly after then method call[22:53:20] <smarlow> stuartdouglas: agreed, for the servlet case, that is something we could do, at the invocation boundaries[22:53:40] <smarlow> definitely, should do for the session bean, as we have done in the past[22:53:42] <stuartdouglas> I don't think the spec lets us do anything else :-)[22:53:49] <Nihility> there is really no other reliable way to do it[22:54:05] *** jpearlin has quit IRC[22:54:06] *** nickarls has quit IRC[22:54:11] <Nihility> the servlet is typically multi threaded[22:54:14] <Nihility> and the PC is not[22:54:38] <stuartdouglas> the underlying PC is not[22:54:41] <stuartdouglas> the proxy can be[22:55:10] <Nihility> yeah logicially a PC cant handle concurrent requests[22:55:12] <stuartdouglas> the proxy can just use thread locals to track PC instances[22:55:15] <Nihility> it would lead to gibeish[22:55:36] <Nihility> right so if you use thread locals then they are only good per-request[22:55:50] <Nihility> no thread to connection association[22:55:52] <stuartdouglas> yea, transactions don't span multiple requests anyway[22:56:06] <smarlow> yup, we have an existing model that is TLS based[22:56:08] <stuartdouglas> extended pc's are different[22:56:37] <Nihility> so that leaves the http session[22:56:40] <smarlow> yeah, but the same PC case, needs to be aware of when its a XPC reference and not close it[22:56:47] <Nihility> but thats would be a mess[22:56:49] <smarlow> :-)[22:56:51] <Nihility> to do anything fancy with[22:57:59] <Nihility> well i guess you could use the session id[22:58:28] <Nihility> and then somehow react to it being expired[22:58:38] <Nihility> but you would need a very clear contract for the user imo[22:58:49] <Nihility> which to me is using something like weld[22:59:00] <Nihility> where you have some kind of scope definitino[22:59:20] <stuartdouglas> where is the bit of the spec where it talks about XPC propegation?[22:59:40] *** miclorb_ has joined #jboss-as7[23:00:34] <smarlow> I was planning on keeping a mapping for xpc propagation (https://github.com/scottmarlow/jboss-as/blob/master/jpa/src/main/java/org/jboss/as/jpa/container/SFSBXPCMap.java) for xpc inheritance[23:00:47] <smarlow> I mean inheritance[23:03:17] <stuartdouglas> found it[23:04:01] <stuartdouglas> heres an interesting one[23:04:37] <stuartdouglas> say I have a thread that calls a SFSB, and the XPC then becomes bound to the current transaction[23:04:56] <stuartdouglas> my SFSB invocation ends, the the XPC is still bound to the current transaction[23:05:24] <stuartdouglas> then another thread calls the SFSB, and now the same XPC is bound to two transactions at once[23:05:55] <stuartdouglas> and will generally get ballsed up when multiple threads modify it at once[23:07:54] <smarlow> stuartdouglas: our old ejb2 container was good about detecting cases like that (from what I remember). at least it tried to[23:08:14] <stuartdouglas> what did it do though? Did it throw an exception?[23:08:58] <smarlow> yeah, sometimes, it threw the exception when it shouldn't of as well. I think we had some thread safety bugs caused false warnings occasionally[23:10:32] <Nihility> so that means ajax applications are impossible with XPC[23:10:33] <Nihility> :)[23:11:59] <smarlow> it seems like we should try to detect if the same XPC gets propagated into more than one transaction and throw a "your fucked" exception[23:12:19] <smarlow> :-)[23:12:59] <Nihility> seriously the only way to prevent that is to ensure that all interaction with the XPC is wrapped with a big fat lock[23:13:07] <stuartdouglas> I had forgotten just how bad the rules for PC propegation were[23:13:33] <Nihility> that or you somehow have an XPC per session[23:13:45] <stuartdouglas> even then you are still kinda fucked, as you will have multiple threads messing with your entities[23:13:49] <Nihility> and then wrap the lock per session[23:14:44] <Nihility> thats a good point because the XPC caches doesnt it?[23:14:47] <smarlow> the XPCs are replicated between session beans, pretty freely. If SFSB1 creates SFSB2, SFSB2 gets to share SFSB1 XPC[23:15:00] <smarlow> inherited is the term they use[23:15:12] <stuartdouglas> yea[23:15:12] <smarlow> at least remote invocations, don't carry the XPC context :)[23:15:22] <Nihility> i guess its not different though to parellel database access[23:15:33] <Nihility> if you really need to ensure your state is correct[23:15:39] <Nihility> you need to flush and or use db locks[23:15:42] <stuartdouglas> Now I remember why I always used application managed PC's :-)[23:16:23] <Nihility> yeah thats what i did back when i wrote applications[23:16:34] <Nihility> right before dropping hibernate for jdbc[23:16:42] <bstansberry> can someone have a look at a couple small things on https://github.com/bstansberry/jboss-as/commits/misc ?[23:18:05] <Nihility> bstansberry: looks good[23:18:11] <bstansberry> thanks[23:18:34] <bstansberry> as I do bigger stuff I keep finding smaller stuff[23:18:53] <stuartdouglas> dmlloyd: back to the injector thing, I am thinking that maybe we should extract an InjectedDescription superclass from BindingDescription, and then I could use that for CDI injections[23:20:06] <jbossbot> git [jboss-as] push master 41dc8dc.. bstansberry at jboss dot com Provide read-config-as-xml op via DC and HC[23:20:06] <jbossbot> git [jboss-as] push master bd4461e.. bstansberry at jboss dot com Add host handlers for server start/stop/restart[23:20:06] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4c3ed47...bd4461e[23:21:42] <Nihility> hmmm[23:21:57] <Nihility> i need to somehow get at the component classloader from an injector[23:23:42] <stuartdouglas> can't you just grab it in the DUP that sets up the component?[23:23:46] <Nihility> actually injection is the wrong word[23:25:47] <stuartdouglas> actually it is probably not worth splitting up BindingDescription[23:26:30] <Nihility> what i really want to have happen[23:27:20] <dmlloyd> the class loader is available from the injection source description[23:27:23] <Nihility> is a bindingsourcedescription where the value at the time it is looked up[23:27:33] <Nihility> oh is it[23:31:52] <stuartdouglas> hmm, the way I have CDI injections set up at the moment the injections respect annotation changes made through the SPI[23:32:54] <stuartdouglas> if I change it to just add BindingDescriptions this will not be possible[23:33:56] *** Nihility has quit IRC[23:34:03] <dmlloyd> yeah the binding dependencies were not intended to accommodate CDI in any way[23:34:29] <dmlloyd> I figured that we'd take care of that in the Component itself, where it constructs the instance[23:34:52] <stuartdouglas> that is pretty much what I do now[23:35:20] *** mbg has joined #jboss-as7[23:35:20] *** ChanServ sets mode: +v mbg[23:35:22] <stuartdouglas> the injector is a service that depends on the BM, so it does not build it's metadata until CDI has started[23:36:13] *** Nihility has joined #jboss-as7[23:36:13] *** Nihility has joined #jboss-as7[23:36:13] *** ChanServ sets mode: +v Nihility[23:43:05] <stuartdouglas> I think it may be best just to leave this as-is for now, because I can't really see any nice way of hooking it in with what we already have[23:44:58] <Nihility> damn eclipse[23:45:16] <Nihility> crashed....[23:45:40] * stuartdouglas does not miss eclipse[23:46:27] <Nihility> and after it crashes it has to rebuild everything[23:46:28] <Nihility> :/[23:46:37] * Nihility shakes fist at eclipse[23:53:05] *** FordPrefect has quit IRC[23:55:02] <stuartdouglas> I have rebased my webComponent branch[23:56:52] <stuartdouglas> should the transactions or the ee subsystem be responsible for binding UserTransaction?[23:58:32] *** bstansberry is now known as bstans_afk[23:58:49] <Nihility> good question[23:58:53] <Nihility> probably transaction[23:59:26] <Nihility> dmlloyd: the only thing i appear to have access to is the module name[23:59:45] <stuartdouglas> ok, I might look at adding that then[23:59:54] <Nihility> oh doh[23:59:58] <Nihility> i have the Deployment phase