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
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
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
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
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
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
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
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
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
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) {
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.
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.
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
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:
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
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
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://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
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
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
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
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
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:
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,
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
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
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
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
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
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
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
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
32 matches
Mail list logo
