You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Alexandru Objelean (JIRA)" <ji...@apache.org> on 2010/04/23 12:02:09 UTC
[jira] Created: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Store Application in InheritableThreadLocal instead of ThreadLocal
------------------------------------------------------------------
Key: WICKET-2846
URL: https://issues.apache.org/jira/browse/WICKET-2846
Project: Wicket
Issue Type: Improvement
Reporter: Alexandru Objelean
Is there any particular reason why Application class wouldn't be stored in
InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
be able to access Application class from a thread created when a button is
pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
this problem.
Thanks!
Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Alexandru Objelean (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872967#action_12872967 ]
Alexandru Objelean edited comment on WICKET-2846 at 5/28/10 9:28 AM:
---------------------------------------------------------------------
The main reason why this cannot be moved outside the UI tier is:
- the use case is to have some sort of component which launch a long running task and have a clear visual indication of the status (in progress, complete, not started).
Here is the link of the component implementing this use case: http://pastebin.com/0GwGXkmr
The usage is pretty simple:
new ProcessExecutorPanel("associatedFilesMigration") {
@Override
protected void execute() {
//a business logic method which takes a lot time to complete
startMigration();
}
};
One more thing I want to point out is that though there was a long discussion about the problem the ITL may cause, nobody actually managed to prove it:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-td2226987i20.html
was (Author: alexandru.objelean):
The main reason why this cannot be moved outside the UI tier is:
- the use case is to have some sort of component which launch a long running task and have a clear visual indication of the status (in progress, complete, not started).
One more thing I want to point out is that though there was a long discussion about the problem the ITL may cause, nobody actually managed to prove it:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-td2226987i20.html
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.10
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Sven Meier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872957#action_12872957 ]
Sven Meier commented on WICKET-2846:
------------------------------------
There might be reasons to prefer an ITL but IMHO the provided use case example is contrived.
I'd suggest moving your thread creation out of your UI tier:
public class MyPage extends Page {
@SpringBean
private MyService service;
//perform a polling of long running process triggered by a button click
onClickButton() {
service.executeLongRunningProcessAndReturnImmediately();
}
}
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.10
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Alexandru Objelean (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexandru Objelean updated WICKET-2846:
---------------------------------------
Description:
Is there any particular reason why Application class wouldn't be stored in
InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
be able to access Application class from a thread created when a button is
pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
this problem.
Use case example:
public class MyPage extends Page {
@SpringBean
private MyService service;
//perform a polling of long running process triggered by a button click
onClickButton() {
new Thread() {
run() {
service.executeLongRunningProcess();
}
}.start();
}
}
The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
Thanks!
Alex
was:
Is there any particular reason why Application class wouldn't be stored in
InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
be able to access Application class from a thread created when a button is
pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
this problem.
Thanks!
Alex
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.4.9
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Alexandru Objelean (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872967#action_12872967 ]
Alexandru Objelean commented on WICKET-2846:
--------------------------------------------
The main reason why this cannot be moved outside the UI tier is:
- the use case is to have some sort of component which launch a long running task and have a clear visual indication of the status (in progress, complete, not started).
One more thing I want to point out is that though there was a long discussion about the problem the ITL may cause, nobody actually managed to prove it:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-td2226987i20.html
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.10
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-2846.
-----------------------------------
Assignee: Igor Vaynberg
Fix Version/s: 1.4.9
Resolution: Fixed
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.4.9
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Adriano dos Santos Fernandes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896272#action_12896272 ]
Adriano dos Santos Fernandes commented on WICKET-2846:
------------------------------------------------------
This issue went "fixed" in 1.4.9 then reverted in 1.4.10.
This ticket was changed to "won't fix" against 1.4.10. This seems as a bad documentation practice. It would need another ticket.
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.10
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson resolved WICKET-2846.
--------------------------------------
Fix Version/s: 1.4.10
(was: 1.4.9)
Resolution: Won't Fix
this was released in 1.4.9, but is now being reverted in 1.4.10 due to overwhelming community feedback
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.10
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Alexandru Objelean (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861013#action_12861013 ]
Alexandru Objelean commented on WICKET-2846:
--------------------------------------------
Hi Igor!
Thanks for the fix. I have a question, why this fix is not a part of 1.4.8 release?
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.4.9
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Alexandru Objelean (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexandru Objelean updated WICKET-2846:
---------------------------------------
Priority: Minor (was: Major)
Component/s: wicket
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Priority: Minor
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "James Carman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Carman updated WICKET-2846:
---------------------------------
Attachment: wicket-application-leak.tar.gz
Here's a quickstart that can be used to show the "leak" of the Application object into the Java2D Disposer thread. You have to use jvisualvm heap dump to see it, but it's there:
1. Go to the "Classes" view.
2. Find the java.lang.Thread class.
3. Click on it and it will bring up a list of instances.
4. Find the thread with the name "Java2D Disposer" (#13 for me).
5. Look for the field called "inheritableThreadLocals" and look in its "table"
6. In there, you'll find a reference to the WicketApplication object.
The Java2D Disposer thread runs for the duration of the VM and it will keep that reference to the application object.
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.4.9
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson reopened WICKET-2846:
--------------------------------------
Assignee: Jeremy Thomerson (was: Igor Vaynberg)
reopening this to revert
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.9
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2846) Store Application in
InheritableThreadLocal instead of ThreadLocal
Posted by "Erik van Oosten (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888729#action_12888729 ]
Erik van Oosten commented on WICKET-2846:
-----------------------------------------
Juliano Viana on the WIcket user mailing list at 2010-07-14 15:55 wrote:
Hi everyone,
I know this issue has already been debated and that a decision was made to
revert this change in a future version of Wicket.
However, the discussions about this issue were centered on the fact starting
threads in web applications is not a good idea anyway, and hence this would
not break applications that are not already broken.
I have found a real case where this breaks an innocent application:
redeploying an application based on Wicket 1.4.9 on Glassfish 3.0.1 causes
a memory leak due to the use of InheritableThreadLocal.
The problem is that when the application accesses a JDBC resource for the
first time, Glassfish lazily starts a timer (connector-timer-proxy) that has
an associated thread. This timer is started from the web request processing
thread. This thread never dies, and inherits a reference to the Wicket
Application object.
This only happens on redeployments, but it really hurts development as you
keep having to restart Glassfish due to OOM exceptions.
Removing the InheritableThreadLocal resolves the issue completely and makes
development really smooth again.
So if you are using Wicket 1.4.9 with Glassfish v3 you should consider
patching it until a new Wicket release is out.
Regards,
- Juliano
> Store Application in InheritableThreadLocal instead of ThreadLocal
> ------------------------------------------------------------------
>
> Key: WICKET-2846
> URL: https://issues.apache.org/jira/browse/WICKET-2846
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Alexandru Objelean
> Assignee: Jeremy Thomerson
> Priority: Minor
> Fix For: 1.4.10
>
> Attachments: wicket-application-leak.tar.gz
>
>
> Is there any particular reason why Application class wouldn't be stored in
> InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
> be able to access Application class from a thread created when a button is
> pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
> this problem.
> Use case example:
> public class MyPage extends Page {
> @SpringBean
> private MyService service;
> //perform a polling of long running process triggered by a button click
> onClickButton() {
> new Thread() {
> run() {
> service.executeLongRunningProcess();
> }
> }.start();
> }
> }
> The following example won't work well if the Application is not stored in InheritableThreadLocal. The reason why it doesn't work, as I understand that, is because @SpringBean lookup depends on Application instance which is not accessible from within the thread. Having it stored inside of ITL would solve the problem.
> Thanks!
> Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.