[seam-issues] [JBoss JIRA] Updated: (SEAMCRON-15) CL issues on redeployment

[Peter Royle (JIRA)]

     [ https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Royle updated SEAMCRON-15:
--------------------------------

    Fix Version/s: 3.0.0.Alpha1


> CL issues on redeployment
> -------------------------
>
>                 Key: SEAMCRON-15
>                 URL: https://issues.jboss.org/browse/SEAMCRON-15
>             Project: Seam Cron
>          Issue Type: Bug
>            Reporter: Peter Royle
>            Assignee: Peter Royle
>             Fix For: 3.0.0.Alpha1
>
>
> Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it once (using NetBeans redeploying after sitting overnight). The sumptom is the 'Singleton is not set' error.
> In a conversation about this Stuart Douglas explained how I can solve this:
> (04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will probably not work very well in this new thread anyway, unless you set the TCCL to the correct one
> (04:43:07 PM) PeteRoyle: TCCL?
> (04:43:16 PM) stuartdouglas: Thread Context Class Loader
> (04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it to be set
> (04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative 'Singleton is not set' errors
> (04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
> (04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
> (04:44:49 PM) PeteRoyle: (so far)
> (04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader being set as the TCCL
> (04:45:54 PM) stuartdouglas: also the only beans that will be accessible is @ApplicationScoped and @Dependant
> (04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the contexts
> (04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
> (04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
> (04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should only be a problem when you start trying to use threads that you have spawned yourself to interact with weld
> (04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as the original threads TCCL, and set it back in a finally block
> (04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a security manager might not let you set it
> (04:50:22 PM) marekn [~mnovotny at nat/redhat/x-wgsrrhabedyogdbb] entered the room.
> (04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do that stuff
> (04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
> (04:51:57 PM) stuartdouglas: https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/WeldContainer.java#L77
> (04:52:11 PM) stuartdouglas: https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/SecurityActions.java
> (04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any class can use it to set the TCCL
> (04:53:42 PM) stuartdouglas: basically it just wraps Thread.currentThread().set/getContextClassLoader
> (04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it portable?
> (04:55:09 PM) stuartdouglas: it needs to be copied each time
> (04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
> (04:56:02 PM) kevinpollet [~kevinpoll at 217.112.54.72] entered the room.
> (04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
> (04:56:59 PM) amitev [~amitev at 212.25.36.84] entered the room.
> (04:57:06 PM) stuartdouglas: yes
> (04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
> (04:57:17 PM) stuartdouglas: yes
> (04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which screate the new thread
> (04:57:52 PM) PeteRoyle: screate=created
> (04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving and restoring the existing TCCL
> (04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang around after redeployment, which results in a memory leak
> (04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both those things in the same thread. Can I unset the TCCL at the end of the run() method (in a finally)?
> (04:59:58 PM) maschmid [~maschmid at nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
> (05:00:00 PM) stuartdouglas: yes
> (05:00:06 PM) PeteRoyle: ok
> (05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
> (05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
> (05:00:57 PM) PeteRoyle: ok gotchya

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira