10:58:56 AM galderz: hi pmuir
10:59:04 AM pmuir: hey galderz 
navssurtani [~Adium@94-194-41-209.zone8.bethere.co.uk] entered the room. (11:00:58 AM)
11:01:37 AM galderz: so pmuir, we're discussing the class loading and listener stuff?
11:02:03 AM pmuir: yes
11:02:19 AM pmuir: alesj, stuartdouglas, kevinpollet you guys there
11:02:27 AM stuartdouglas: yes
11:03:20 AM pmuir: ok, so basically the problem we've hit is this
11:03:59 AM pmuir: if we register a listener on a cache
11:04:08 AM pmuir: and it get's called when entries are added to the cache
11:04:24 AM kevinpollet: pmuir: I'm here 
11:05:03 AM pmuir: if the entries are added in a thread that doesn't already have the TCCL set, then Weld can't establish the context in which to operate
11:05:06 AM pmuir: and therefore fails
11:05:26 AM pmuir: if you have e.g. a single node (so just a cache, not a distributed cache)
11:05:33 AM pmuir: and you add some entries from a servlet
11:05:35 AM pmuir: then it all works
11:05:47 AM pmuir: as the TCCL is set, and the events get fired in that thread
11:05:58 AM galderz: cos the TCCL is set to the deployments, which is assumed to be the one containing the listener, right?
11:06:08 AM pmuir: however we first noticed this problem when we made the cache distributed, so some entries are distrubted to the second node
11:06:32 AM pmuir: and hence the events get fired on that second node
11:06:38 AM pmuir: and the listener is called there
11:06:48 AM galderz: and that's coming at the JGroups thread which does not have the right CL set
11:06:55 AM pmuir: galderz: i'm not sure if the tccl is set at all or not
11:07:00 AM pmuir: but yes, thats right
11:07:08 AM alesj: tccl is set to ispan's cl
11:07:21 AM alesj: i mean, to ispan's module cl
11:07:23 AM galderz: ah ok, i thought the servlet/ee spec had something on tccl and deployment link
11:07:39 AM pmuir: so alesj and matej got around this by doing a try {} finally{} and manually setting the TCCL
11:07:56 AM galderz: pmuir: where did they add that code?
11:07:59 AM pmuir: galderz: right but we aren't in anything ee/sevlet on the second node
11:08:11 AM alesj: galderz: directly in the listener code
11:08:14 AM pmuir: galderz: just around the injection of the cdi bean into the listener
11:08:17 AM galderz: sure pmuir, just clarifying the initial servlet example in single node
11:08:27 AM galderz: ok
11:08:50 AM pmuir: galderz: ah yes, in that case the tccl is set to the "deployment" (loosely speaking) so it all works
11:08:59 AM galderz: pmuir: exactly 
11:09:09 AM alesj: that's per ee spec
11:09:09 AM pmuir: alesj and matej just set the tccl to the classloader of the listener class
11:09:10 AM galderz: the problem here is that we can't use the same trick as for lazy deserialization
11:09:26 AM alesj: galderz: which trick is that?
11:09:47 AM galderz: lazy deserialization or store as binary allows you to get around the fact that when data is replicated, the jgroups thread might not have the CL to deserialize data
11:10:20 AM galderz: so, lazy deserialization says: don't try to deserialize it and instead, let the user thread, when it requests the data, deserialize it then
11:10:31 AM galderz: cos we assume that when the user requests the data, it will have the right CL set
11:10:57 AM galderz: with listener events, it would be counter intuitive to have lazy listener events
11:11:52 AM alesj: yeah, in that case the user doesn't even interact
11:12:02 AM galderz: exactly
11:12:08 AM galderz: one sec guys
vblagoje [~vblagoje@redhat/jboss/vblagoje] entered the room. (11:12:35 AM)
11:13:14 AM stuartdouglas: The main issue that weld's singleton impl is dependent on the class loader
11:13:25 AM pmuir: stuartdouglas: yeah
11:13:37 AM galderz: back, sorry
11:13:43 AM stuartdouglas: In theory we could attach extra information to the serialized classes to allow them to locate the correct deployment 
11:13:46 AM alesj: we hit the issue with weld/cdi
11:13:56 AM galderz: one workaround is to associate a classloader with a cache/cachemanager
11:13:58 AM alesj: but i'm sure there can easily be other similar
11:14:10 AM stuartdouglas: and manually activate the singleton based on deployment name, rather than than class loader
11:14:27 AM stuartdouglas: this would require some minor changes in weld and AS7
11:14:49 AM alesj: i think we're already trying to do something like this with weld-osgi
11:14:51 AM alesj: pmuir: ?
11:14:54 AM alesj: pmuir: ^
11:15:07 AM galderz: stuartdouglas: i think that would require not only changes in weld but also in infinispan
11:15:20 AM galderz: and this use case goes beyond weld tbh
11:15:24 AM pmuir: alesj: yes basically
11:16:05 AM stuartdouglas: I don't think it would require infinspan changes, I was thinking just add a SPI to weld that allows you to attach the deployment name to a proxies serialised form 
11:16:26 AM stuartdouglas: then when the proxy is de-serialized the de-serialization code can activate the correct singleton 
11:16:58 AM pmuir: alesj: what mathieu is doing for weld osgi is allowing you to store the Deployment id into the bean manager etc. objects so that they know what deployment they come from
11:17:17 AM galderz: stuartdouglas: right, but even if that works, you're only solving the weld use case
11:17:28 AM galderz: and this problem can happen in any modular env
11:18:05 AM alesj: pmuir: yeah, and that way i suspect we won;t need tccl info to find the right singleton store
11:18:38 AM stuartdouglas: alesj: not in every case 
11:18:46 AM alesj: galderz: in any env in which ispan's classes don't share deployment's view
11:18:57 AM galderz: exactly alesj
11:19:12 AM pmuir: alesj: you would still need it
11:19:25 AM pmuir: or you still need to tie things together properly
11:19:58 AM pmuir: in jboss as where we can guarantee a deployment has the same id across every node we might be able to get rid of the requirement if we also serialized the deployment id with the proxy class
11:20:07 AM stuartdouglas: from infininispans point of view could you add a SPI that allows you to attach something to the serialised data, that can be used to locate the TCCL 
11:20:24 AM stuartdouglas: like what pete just said 
11:22:06 AM alesj: what about if ispan wrapped the listener invocation's with listener's cl as tccl?
11:22:07 AM galderz: indeed stuartdouglas, and this is something we might consider doing it
11:22:38 AM galderz: but needs some thought cos we had this mechanism in JBossCache days but that's a very long story...
maeste [~maeste4@redhat/jboss/maeste] entered the room. (11:22:59 AM)
11:25:49 AM stuartdouglas: did it not work very well?
11:26:12 AM galderz: stuartdouglas: it was an old or nothing approach
11:26:24 AM galderz: sorry, all or nothing approach
11:26:41 AM galderz: basically, you had a region, which could equivalent to a cache these days,
11:26:50 AM galderz: and you had to associate a classloader with the region on startup
11:27:06 AM galderz: then, when something was replicated for that cache, the region name would be shipped
11:27:15 AM galderz: and the region name would be used to figure out the classloader to us
11:27:16 AM galderz: use
11:27:28 AM pmuir: ok, so it sounds like we have some JIRAs to file - one for Infinispan (add SPI JBoss AS can use to attach deployment ID to serialized data and then restore TCCL), two for Weld (modify serialization to allow attaching some deployment id to the proxy classes serialized form AND apply the Weld OSGi changes which mena that Weld objects track their own deployment id) and two for JBoss AS (use the new SPIs)
11:27:34 AM pmuir: does that sound right to everyone?
11:27:51 AM galderz: in an AS env, it works nicely cos AS can set the region to be the deployment unit for example and associate the classloader there
11:27:58 AM galderz: but that's done by the AS internals
aslak [~aslak@redhat/jboss/aslak] entered the room. (11:28:01 AM)
11:28:05 AM stuartdouglas: do we need both the infinispan and the weld changes?
11:28:26 AM stuartdouglas: if infinispan can restore the TCCL, weld should work fine
11:28:39 AM galderz: but when users had to do this manually, it was a pain - which is the nice thing about lazy deserialization
11:28:46 AM galderz: it's a flag, you set it and you're good to go
11:28:59 AM galderz: but lazy deserialization approach does not work well for listeners as we can see now
11:30:04 AM galderz: pmuir: sounds good - we need to make it very clear when to use storeAsBinary or lazyDeserialization, as opposed to the use SPI the assign the CL
11:30:28 AM pmuir: stuartdouglas: maybe 
11:30:36 AM pmuir: stuartdouglas: i'll still file the JIRA for the record
11:30:41 AM galderz: the 1st works well for deserializing data in cache, the 2nd for deserializing listener classes provided by user
11:31:01 AM kevinpollet: pmuir: sounds good
11:31:03 AM pmuir: as once mathieu makes his changes it shouldn't be a big change to impl this in Weld I think
11:31:03 AM stuartdouglas: ok
11:32:04 AM pmuir: galderz: i'll add that to the JIRA
11:32:18 AM pmuir: alesj: in the meantime I'll see if we can place the TCCL setting into a interceptor of some sort
11:32:32 AM galderz: pmuir: btw
11:32:36 AM alesj: pmuir: hehe, we tried that already
11:32:40 AM alesj: but ...
11:32:43 AM galderz: wouldn't it be possible to do away with the SPI?
11:32:48 AM alesj: @Listener is no @Inherited
11:33:01 AM alesj: hence ISpan doesn't consider proxy as listener
11:33:20 AM galderz: hmmm, actuallly no, that could only work if a cache could only be used by a single deployment unit
11:33:23 AM galderz: pmuir: ^^^
11:33:35 AM galderz: then weld could just call cache.setClassLoader() or similar
11:34:24 AM pmuir: alesj: I think you can do it as a decorator
11:34:46 AM galderz: the SPI would allow going beyond cos a cache could have different deployment unit info in it and each operation on that cache would ship the deployment unit info to detect the CL
11:35:15 AM galderz: pmuir: ^^^ - isn't limiting a cache to a single deployment unit information good enough here? just wondering
11:37:10 AM stuartdouglas: if it helps I could mirror the annotations on the proxy
maeste left the room (quit: Remote host closed the connection). (11:37:17 AM)
11:37:21 AM stuartdouglas: we do with the AS7 ejb proxies
dberindei [~dan@89.137.120.233] entered the room. (11:37:35 AM)
11:37:45 AM alesj: pmuir: decorator would work, but you still need to manually code methods
11:38:03 AM pmuir: alesj: yes, it's just a workaround
11:38:33 AM pmuir: galderz: probably, I think we can work around this until we have a proper soln in place
11:38:35 AM alesj: stuartdouglas: why don't we mirror  class annotations on proxies already?
11:38:52 AM alesj: or any annotations for that matter
11:39:24 AM alesj: as you can see quite a few frmwrks doing: getClass::getAnnotation
11:39:36 AM alesj: which will fail on CDI proxy
stuartdouglas left the room (quit: *.net *.split). (11:40:00 AM)
emmanuel left the room (quit: *.net *.split). (11:40:00 AM)
tkimura left the room (quit: *.net *.split). (11:40:01 AM)
maeste [~maeste4@redhat/jboss/maeste] entered the room. (11:42:21 AM)
stuartdouglas [~stuartdou@redhat/jboss/stuartdouglas] entered the room. (11:42:48 AM)
emmanuel [~Adium@redhat/jboss/epbernard] entered the room. (11:42:48 AM)
tkimura [~tkimura@nat/redhat/x-aezgczzskpthngwg] entered the room. (11:42:48 AM)
11:43:56 AM alesj: stuartdouglas: ^
11:44:04 AM alesj: stuartdouglas: why don't we mirror  class annotations on proxies already?
11:44:04 AM alesj: 11:38
11:44:04 AM alesj: or any annotations for that matter
11:44:04 AM alesj: 11:39
11:44:04 AM alesj: as you can see quite a few frmwrks doing: getClass::getAnnotation
11:44:05 AM alesj: 11:39
11:44:05 AM alesj: which will fail on CDI proxy
11:45:24 AM stuartdouglas: because no one has implemented it yet
11:45:40 AM alesj: ah, good answer 
11:47:26 AM stuartdouglas: I think there is code in fakereplace that already does something similar 
11:47:36 AM stuartdouglas: i.e. goes from a reflection annotation to a javassist one