Re: [PROPOSAL] Application.runAs() Method...
Is @SpringBean used *by* the framework? No, not the core. A thread local won't work for what we're trying to do, hence the long, drawn-out discussion thread(s) we've been having recently. IMHO the discussion threads have not shown a conclusive use case for an ITL. Some folks like to use Wicket as a templating framework so that they can generate emails with links in them that point to Wicket-managed pages. Well, this is a strong argument for improved support of mail generation with Wicket - I'm not yet sure if the ITL is the answer to this issue. Regards Sven -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234535.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
On Fri, May 28, 2010 at 9:05 AM, Sven Meier s...@meiers.net wrote: IMHO the discussion threads have not shown a conclusive use case for an ITL. What I'm proposing is an alternative to the ITL (which we've shown is quite ineffective). Well, this is a strong argument for improved support of mail generation with Wicket - I'm not yet sure if the ITL is the answer to this issue. Again, I'm not for ITL. It just doesn't work reliably. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
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();
}
};
Alex
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234567.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
OK, no ITL, got it. Then, you can use that Runnable anywhere to run a task with all of the appropriate Wickety goodness set up for you (except for the request cycle of course because you're not executing within a request cycle). But what are the use cases for *this* proposal (beside mail generation)? Sven -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234572.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
I am sorry but I don't knwo what ITL is? Could you explained a little? On Fri, May 28, 2010 at 10:33 AM, Sven Meier s...@meiers.net wrote: OK, no ITL, got it. Then, you can use that Runnable anywhere to run a task with all of the appropriate Wickety goodness set up for you (except for the request cycle of course because you're not executing within a request cycle). But what are the use cases for *this* proposal (beside mail generation)? Sven -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234572.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Fernando Wermus. www.linkedin.com/in/fernandowermus
Re: [PROPOSAL] Application.runAs() Method...
ITL = InheritableThreadLocal
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();
}
};
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234578.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
On Fri, May 28, 2010 at 9:35 AM, Fernando Wermus fernando.wer...@gmail.com wrote: I am sorry but I don't knwo what ITL is? Could you explained a little? InheritableThreadLocal variables. Sorry, we've just had a rather lengthy conversation over the past week about them, so I guess I figured everyone was watching. :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
On Fri, May 28, 2010 at 9:33 AM, Sven Meier s...@meiers.net wrote: But what are the use cases for *this* proposal (beside mail generation)? Probably whatever they were that caused the team to implement the ITL approach in the first place. My suggestion is an alternative to the ITL approach to solving the same problem (perhaps a hammer looking for a nail?). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
On Friday 28 May 2010 15:33:16 Sven Meier wrote: OK, no ITL, got it. Then, you can use that Runnable anywhere to run a task with all of the appropriate Wickety goodness set up for you (except for the request cycle of course because you're not executing within a request cycle). But what are the use cases for *this* proposal (beside mail generation)? In our jobs, we sometimes need access to the security layer of the application via wicket-security to authenticate actions performed by the job. This only works when Application.get() returns the application. Emond - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Why so much trouble inside your UI layer? Normally Wicket components are
single-threaded, but with your solution you may introduce race conditions.
Move the ExecutorService into your service layer:
http://pastebin.com/NN58fiZx
new ProcessExecutorPanel(associatedFilesMigration) {
@Override
protected Future? start() {
return injectedSpringBean.startMigration();
}
};
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234624.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
The problem is that injectedSpringBean won't work because it needs Application :)... Alex -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234639.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Please take another look on http://pastebin.com/NN58fiZx - it will work :). -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234652.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
The problem is not with the ProcessExecutorPanel component.. but with the way you execute it: because the client needs a reference to injectedSpringBean which cannot be resolved unless it is invoked from within a thread which can access Application, because @SpringBean needs it. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234731.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
But in my example start() *is* invoked on the request thread, thus the Wicket application is available. Please take another look on http://pastebin.com/NN58fiZx . -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234769.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
So, don't use the feature. If yours works, then fine. Some folks are doing things asynchronously where they need the Application in place. On Fri, May 28, 2010 at 11:31 AM, Sven Meier s...@meiers.net wrote: But in my example start() *is* invoked on the request thread, thus the Wicket application is available. Please take another look on http://pastebin.com/NN58fiZx . -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234769.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
What is the service layer that you speak of?
Is this built into wicket?
D/
On May 28, 2010, at 9:06 AM, Sven Meier wrote:
Why so much trouble inside your UI layer? Normally Wicket components are
single-threaded, but with your solution you may introduce race conditions.
Move the ExecutorService into your service layer:
http://pastebin.com/NN58fiZx
new ProcessExecutorPanel(associatedFilesMigration) {
@Override
protected Future? start() {
return injectedSpringBean.startMigration();
}
};
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234624.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Yes, I see now. Thanks! The only drawback of this approach is that the client code is responsible for creating the Future. The initial purpose was to hide the implementation details related to thread creation. Alex -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234916.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
http://en.wikipedia.org/wiki/Multitier_architecture
On 05/28/2010 06:04 PM, Douglas Ferguson wrote:
What is the service layer that you speak of?
Is this built into wicket?
D/
On May 28, 2010, at 9:06 AM, Sven Meier wrote:
Why so much trouble inside your UI layer? Normally Wicket components are
single-threaded, but with your solution you may introduce race conditions.
Move the ExecutorService into your service layer:
http://pastebin.com/NN58fiZx
new ProcessExecutorPanel(associatedFilesMigration) {
@Override
protected Future? start() {
return injectedSpringBean.startMigration();
}
};
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234624.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
The details of thread creation are hidden from your Wicket class - IMHO this is a good thing. Sven On 05/28/2010 07:08 PM, Alex Objelean wrote: Yes, I see now. Thanks! The only drawback of this approach is that the client code is responsible for creating the Future. The initial purpose was to hide the implementation details related to thread creation. Alex - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
asynchronously where they need the Application in place As I've written I still don't see a reason why they need the Application at all. Sven On 05/28/2010 05:50 PM, James Carman wrote: So, don't use the feature. If yours works, then fine. Some folks are doing things asynchronously where they need the Application in place. On Fri, May 28, 2010 at 11:31 AM, Sven Meiers...@meiers.net wrote: But in my example start() *is* invoked on the request thread, thus the Wicket application is available. Please take another look on http://pastebin.com/NN58fiZx . -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234769.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
I know all this, I was just hoping you would explain what you were trying to
say.
On May 28, 2010, at 12:18 PM, Sven Meier wrote:
http://en.wikipedia.org/wiki/Multitier_architecture
On 05/28/2010 06:04 PM, Douglas Ferguson wrote:
What is the service layer that you speak of?
Is this built into wicket?
D/
On May 28, 2010, at 9:06 AM, Sven Meier wrote:
Why so much trouble inside your UI layer? Normally Wicket components are
single-threaded, but with your solution you may introduce race conditions.
Move the ExecutorService into your service layer:
http://pastebin.com/NN58fiZx
new ProcessExecutorPanel(associatedFilesMigration) {
@Override
protected Future? start() {
return injectedSpringBean.startMigration();
}
};
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234624.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Sorry, I didn't want to bore you with this whole pattern stuff (which
you probably know too):
- single responsibility,
- facade,
- object (thread) pool,
- active object,
- DI,
- yada yada yada.
I fail to see how the original implementation of ProcessExecutorPanel
confirms to any of these points. It's just a class which does to much
and now someone is asking for a method in Wicket to keep this mess running.
There might be good reasons for changes but IMHO this use case is not.
Sven
On 05/28/2010 08:31 PM, Douglas Ferguson wrote:
I know all this, I was just hoping you would explain what you were trying to
say.
On May 28, 2010, at 12:18 PM, Sven Meier wrote:
http://en.wikipedia.org/wiki/Multitier_architecture
On 05/28/2010 06:04 PM, Douglas Ferguson wrote:
What is the service layer that you speak of?
Is this built into wicket?
D/
On May 28, 2010, at 9:06 AM, Sven Meier wrote:
Why so much trouble inside your UI layer? Normally Wicket components are
single-threaded, but with your solution you may introduce race conditions.
Move the ExecutorService into your service layer:
http://pastebin.com/NN58fiZx
new ProcessExecutorPanel(associatedFilesMigration) {
@Override
protected Future? start() {
return injectedSpringBean.startMigration();
}
};
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2234624.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
I don't understand why do you think that a component responsible for creating a thread and check its status does too much, is it really that complicated?? And also, pardon me, but what mess are you talking about? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2235206.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
In our application we use quartz for long running jobs. These threads have access to the application context, which contains the wicket application. In the execute method, we locate the application and use Application.set and Application.unset to set and remove the application. This is, however, not a 'public API' and could easily be replaced by wrapping the main body in a Runnable and calling Application.wrap. I'm in favor of this wrap method. It allows you to set the application on a thread, without having to use non- public API, and without the try/finally hassle. I do not care how this method is implemented (that's the beauty of a good API, isn't it?). It could store the application in the runnable, or look it up in a map, as long as it works reliably, I'm fine with it :) Emond On Wednesday 26 May 2010 23:47:43 James Carman wrote: Well, this doesn't start any threads or anything. So, it wouldn't immediately allow folks to start up threads. All this would do is create an object that *can* be run in another thread, but have access to this Application in it. Also, this is just a proposal. I'm just wanting folks to give feedback about the idea. I think this is the most flexible way to solve the problem we're seeing folks have. On Wed, May 26, 2010 at 4:28 PM, Joe Fawzy joewic...@gmail.com wrote: Hi Please make this configurable(can be disabled) as i am on appengine, they does not allow threads thanks Joe On Tue, May 25, 2010 at 4:34 PM, James Carman ja...@carmanconsulting.comwrote: Sorry, subject should be wrap() method, not runAs(). On Tue, May 25, 2010 at 9:33 AM, James Carman ja...@carmanconsulting.com wrote: I've been thinking about this whole idea of needing to access the application object in different threads idea. What if the Application class had a method like this: public Runnable wrap(Runnable task) Basically, the Application would create a Runnable object that can be run within the context of itself (by setting/clearing the ThreadLocal variable). Then, you can use that Runnable anywhere to run a task with all of the appropriate Wickety goodness set up for you (except for the request cycle of course because you're not executing within a request cycle). Now, what the Application stores in the Runnable doesn't have to be the Application itself. We can set up a static MapString,WeakReferenceApplication object on the Application class and when an Application is constructed, it registers itself (the key could be a UUID.randomUUID().toString()). Then, we could have a method like public static Application get(String id); on the Application class to get back the original Application object. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
On Thu, May 27, 2010 at 2:34 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: In our application we use quartz for long running jobs. These threads have access to the application context, which contains the wicket application. In the execute method, we locate the application and use Application.set and Application.unset to set and remove the application. This is, however, not a 'public API' and could easily be replaced by wrapping the main body in a Runnable and calling Application.wrap. I'm in favor of this wrap method. It allows you to set the application on a thread, without having to use non- public API, and without the try/finally hassle. What happens if you have multiple applications running in the same webapp? I do not care how this method is implemented (that's the beauty of a good API, isn't it?). It could store the application in the runnable, or look it up in a map, as long as it works reliably, I'm fine with it :) Right, we can figure out how to implement it later, but I think making this method available would be a huge step in the right direction. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
On Thursday 27 May 2010 12:41:10 James Carman wrote: On Thu, May 27, 2010 at 2:34 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: In our application we use quartz for long running jobs. These threads have access to the application context, which contains the wicket application. In the execute method, we locate the application and use Application.set and Application.unset to set and remove the application. This is, however, not a 'public API' and could easily be replaced by wrapping the main body in a Runnable and calling Application.wrap. I'm in favor of this wrap method. It allows you to set the application on a thread, without having to use non- public API, and without the try/finally hassle. What happens if you have multiple applications running in the same webapp? Well, the answer is pretty simple: we only have one application per webapp. :) If we wanted to supported multiple applications, we probably would pass the application in some way to the jobs (we already pass other information, such as the user starting the job). I do not care how this method is implemented (that's the beauty of a good API, isn't it?). It could store the application in the runnable, or look it up in a map, as long as it works reliably, I'm fine with it :) Right, we can figure out how to implement it later, but I think making this method available would be a huge step in the right direction. Agreed. Emond - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Hi James! It would be a good idea to add this feature to next release, since the Application won't be stored in InheritableThreadLocal anymore. Alex -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PROPOSAL-Application-runAs-Method-tp2230030p2233184.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Hi all, I don't think the proposed method is a good idea. Why add a method to a framework which is not used *by* the framework? Why can't you just create your own static helper method storing the application in an inheritable/non-inheritable thread local? Why would anyone want to pass a web application object to another non-web thread? My 3 questions. Sven On 05/27/2010 04:13 PM, Alex Objelean wrote: Hi James! It would be a good idea to add this feature to next release, since the Application won't be stored in InheritableThreadLocal anymore. Alex - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
On Thu, May 27, 2010 at 2:20 PM, Sven Meier s...@meiers.net wrote: Hi all, I don't think the proposed method is a good idea. Why add a method to a framework which is not used *by* the framework? Is @SpringBean used *by* the framework? Why can't you just create your own static helper method storing the application in an inheritable/non-inheritable thread local? A thread local won't work for what we're trying to do, hence the long, drawn-out discussion thread(s) we've been having recently. Why would anyone want to pass a web application object to another non-web thread? Some folks like to use Wicket as a templating framework so that they can generate emails with links in them that point to Wicket-managed pages. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Hi Please make this configurable(can be disabled) as i am on appengine, they does not allow threads thanks Joe On Tue, May 25, 2010 at 4:34 PM, James Carman ja...@carmanconsulting.comwrote: Sorry, subject should be wrap() method, not runAs(). On Tue, May 25, 2010 at 9:33 AM, James Carman ja...@carmanconsulting.com wrote: I've been thinking about this whole idea of needing to access the application object in different threads idea. What if the Application class had a method like this: public Runnable wrap(Runnable task) Basically, the Application would create a Runnable object that can be run within the context of itself (by setting/clearing the ThreadLocal variable). Then, you can use that Runnable anywhere to run a task with all of the appropriate Wickety goodness set up for you (except for the request cycle of course because you're not executing within a request cycle). Now, what the Application stores in the Runnable doesn't have to be the Application itself. We can set up a static MapString,WeakReferenceApplication object on the Application class and when an Application is constructed, it registers itself (the key could be a UUID.randomUUID().toString()). Then, we could have a method like public static Application get(String id); on the Application class to get back the original Application object. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Well, this doesn't start any threads or anything. So, it wouldn't immediately allow folks to start up threads. All this would do is create an object that *can* be run in another thread, but have access to this Application in it. Also, this is just a proposal. I'm just wanting folks to give feedback about the idea. I think this is the most flexible way to solve the problem we're seeing folks have. On Wed, May 26, 2010 at 4:28 PM, Joe Fawzy joewic...@gmail.com wrote: Hi Please make this configurable(can be disabled) as i am on appengine, they does not allow threads thanks Joe On Tue, May 25, 2010 at 4:34 PM, James Carman ja...@carmanconsulting.comwrote: Sorry, subject should be wrap() method, not runAs(). On Tue, May 25, 2010 at 9:33 AM, James Carman ja...@carmanconsulting.com wrote: I've been thinking about this whole idea of needing to access the application object in different threads idea. What if the Application class had a method like this: public Runnable wrap(Runnable task) Basically, the Application would create a Runnable object that can be run within the context of itself (by setting/clearing the ThreadLocal variable). Then, you can use that Runnable anywhere to run a task with all of the appropriate Wickety goodness set up for you (except for the request cycle of course because you're not executing within a request cycle). Now, what the Application stores in the Runnable doesn't have to be the Application itself. We can set up a static MapString,WeakReferenceApplication object on the Application class and when an Application is constructed, it registers itself (the key could be a UUID.randomUUID().toString()). Then, we could have a method like public static Application get(String id); on the Application class to get back the original Application object. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [PROPOSAL] Application.runAs() Method...
Sorry, subject should be wrap() method, not runAs(). On Tue, May 25, 2010 at 9:33 AM, James Carman ja...@carmanconsulting.com wrote: I've been thinking about this whole idea of needing to access the application object in different threads idea. What if the Application class had a method like this: public Runnable wrap(Runnable task) Basically, the Application would create a Runnable object that can be run within the context of itself (by setting/clearing the ThreadLocal variable). Then, you can use that Runnable anywhere to run a task with all of the appropriate Wickety goodness set up for you (except for the request cycle of course because you're not executing within a request cycle). Now, what the Application stores in the Runnable doesn't have to be the Application itself. We can set up a static MapString,WeakReferenceApplication object on the Application class and when an Application is constructed, it registers itself (the key could be a UUID.randomUUID().toString()). Then, we could have a method like public static Application get(String id); on the Application class to get back the original Application object. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
