[
https://issues.jboss.org/browse/SEAMCRON-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605155#comment-12605155
]
Peter Royle commented on SEAMCRON-15:
-------------------------------------
Update: The issue was more likely being caused by the fact that the schedulers
weren't being shut down in Weld and were trying to fire in the background with
absolutely no context available to them. Having solved that (SEAMCRON-23) this
issue seems to not show up anymore. I will still apply the concepts Stuart
described, but will put them off until Alpha2 while we see how Alpha1 behaves
without it.
> 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.Alpha2
>
>
> 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@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 [[email protected]] 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 [[email protected]] 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@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
_______________________________________________
seam-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-issues
