You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bertrand Guay-Paquet <be...@step.polymtl.ca> on 2011/07/23 05:55:26 UTC
Handling futures
Hello,
I can't find the correct way to handle java.util.concurrent.Future
instances returned from asynchronous methods in Wicket. This interface
does not extend Serializable so its instances can't be stored in
components or pages. So what do you do with them?
Do you store them in a map in the application and keep a handle (e.g. an
int) in the Wicket component?
I saw code on a github repository that implemented an ajax timer
behavior that keeps a reference to a Future in a transient field to
update a status. However, I can't understand how that would work.
Wouldn't the transient field be nulled out if the behavior is serialized
with the page and then deserialized?
Essentially, my question is: what is the standard way to handle Futures
in Wicket that run longer than the page rendering? (like processing an
order or sending emails)
I hope I'm not missing something obvious, but that might be the case...
Regards,
Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling futures
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Hans: I hadn't looked at that project, thanks for mentioning it.
Thank you all for your input.
It seems the only viable solution is to keep track of Futures in another
scope than the relevant components so I'll go with that.
On 24/07/2011 1:21 AM, Rodolfo Hansen wrote:
> Have you thought about keeping your future in another scope? a conversation
> scope for example, or delegating it to the application / session ?
>
> On Sat, Jul 23, 2011 at 10:31 PM, Bertrand Guay-Paquet<
> bernie@step.polymtl.ca> wrote:
>
>> Thanks for your answers Scott.
>>
>> I thought Wicket could essentially serialize a page any time it sees fit.
>> Is that the case? If so, that would mean that even if the page containing
>> the Future reference is still open in the browser window, the Future could
>> be thrown away. Wouldn't that be a definite possibility if a user has
>> multiple browser windows open in the same session and keeps browsing the
>> site in another window while the "pending result" window is still open?
>>
>>
>> On 23/07/2011 11:10 AM, Scott Swank wrote:
>>
>>> Perhaps a transient Future would work for you after all. If the user
>>> navigates away the Page is serialized and the Future is thrown away.
>>>
>>> If you do put futures in a Map, perhaps in the Session, I'd wrap that
>>> in an AbstractReadonlyModel<Future>. Then you could use have a
>>> Map<Integer, SoftReference<Future>> (assuming your key is an Integer)
>>> if you're still concerned about memory usage getting out of hand.
>>>
>>> Scott
>>>
>>> On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet
>>> <be...@step.polymtl.ca> wrote:
>>>
>>>> I haven't actually done it yet, but the 3 steps you list are what I have
>>>> in
>>>> mind.
>>>>
>>>> After these, I plan to use a javascript timer that polls the status of
>>>> the
>>>> request and updates a label (or icon). That ajax behavior would be the
>>>> one
>>>> polling the Future.
>>>>
>>>> What I can't wrap my head around is this: the ajax behavior can't
>>>> directly
>>>> hold a reference to the Future because it can be serialized with the
>>>> page.
>>>> On the other hand, if I store the Future in a map somewhere and keep a
>>>> serializable handle in the behavior, there is a possibility that the user
>>>> will navigate to another page before get() is called on the Future. To
>>>> avoid
>>>> running out of memory, this means that I would need to have a daemon that
>>>> periodically nulls stale Futures from the map so they can be garbage
>>>> collected.
>>>>
>>>> This kind of operation (submit + polling asynchronous result) seems
>>>> rather
>>>> common so I'm sure there's some (easy) way to handle it...
>>>>
>>>> On 23/07/2011 9:14 AM, Scott Swank wrote:
>>>>
>>>>> What does your workflow look like?
>>>>>
>>>>> 1. submit form (or ajax event)
>>>>> 2. create Future
>>>>> 3. return response page (or ajax response)
>>>>>
>>>>> Now who checks the Future and what sort of UI result occurs?
>>>>>
>>>>> Scott
>>>>>
>>>>> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
>>>>> <be...@step.polymtl.ca> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I can't find the correct way to handle java.util.concurrent.Future
>>>>>> instances
>>>>>> returned from asynchronous methods in Wicket. This interface does not
>>>>>> extend
>>>>>> Serializable so its instances can't be stored in components or pages.
>>>>>> So
>>>>>> what do you do with them?
>>>>>>
>>>>>> Do you store them in a map in the application and keep a handle (e.g.
>>>>>> an
>>>>>> int) in the Wicket component?
>>>>>>
>>>>>> I saw code on a github repository that implemented an ajax timer
>>>>>> behavior
>>>>>> that keeps a reference to a Future in a transient field to update a
>>>>>> status.
>>>>>> However, I can't understand how that would work. Wouldn't the transient
>>>>>> field be nulled out if the behavior is serialized with the page and
>>>>>> then
>>>>>> deserialized?
>>>>>>
>>>>>> Essentially, my question is: what is the standard way to handle Futures
>>>>>> in
>>>>>> Wicket that run longer than the page rendering? (like processing an
>>>>>> order
>>>>>> or
>>>>>> sending emails)
>>>>>>
>>>>>> I hope I'm not missing something obvious, but that might be the case...
>>>>>>
>>>>>> Regards,
>>>>>> Bertrand
>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling futures
Posted by Rodolfo Hansen <rh...@kitsd.com>.
Have you thought about keeping your future in another scope? a conversation
scope for example, or delegating it to the application / session ?
On Sat, Jul 23, 2011 at 10:31 PM, Bertrand Guay-Paquet <
bernie@step.polymtl.ca> wrote:
> Thanks for your answers Scott.
>
> I thought Wicket could essentially serialize a page any time it sees fit.
> Is that the case? If so, that would mean that even if the page containing
> the Future reference is still open in the browser window, the Future could
> be thrown away. Wouldn't that be a definite possibility if a user has
> multiple browser windows open in the same session and keeps browsing the
> site in another window while the "pending result" window is still open?
>
>
> On 23/07/2011 11:10 AM, Scott Swank wrote:
>
>> Perhaps a transient Future would work for you after all. If the user
>> navigates away the Page is serialized and the Future is thrown away.
>>
>> If you do put futures in a Map, perhaps in the Session, I'd wrap that
>> in an AbstractReadonlyModel<Future>. Then you could use have a
>> Map<Integer, SoftReference<Future>> (assuming your key is an Integer)
>> if you're still concerned about memory usage getting out of hand.
>>
>> Scott
>>
>> On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet
>> <be...@step.polymtl.ca> wrote:
>>
>>> I haven't actually done it yet, but the 3 steps you list are what I have
>>> in
>>> mind.
>>>
>>> After these, I plan to use a javascript timer that polls the status of
>>> the
>>> request and updates a label (or icon). That ajax behavior would be the
>>> one
>>> polling the Future.
>>>
>>> What I can't wrap my head around is this: the ajax behavior can't
>>> directly
>>> hold a reference to the Future because it can be serialized with the
>>> page.
>>> On the other hand, if I store the Future in a map somewhere and keep a
>>> serializable handle in the behavior, there is a possibility that the user
>>> will navigate to another page before get() is called on the Future. To
>>> avoid
>>> running out of memory, this means that I would need to have a daemon that
>>> periodically nulls stale Futures from the map so they can be garbage
>>> collected.
>>>
>>> This kind of operation (submit + polling asynchronous result) seems
>>> rather
>>> common so I'm sure there's some (easy) way to handle it...
>>>
>>> On 23/07/2011 9:14 AM, Scott Swank wrote:
>>>
>>>> What does your workflow look like?
>>>>
>>>> 1. submit form (or ajax event)
>>>> 2. create Future
>>>> 3. return response page (or ajax response)
>>>>
>>>> Now who checks the Future and what sort of UI result occurs?
>>>>
>>>> Scott
>>>>
>>>> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
>>>> <be...@step.polymtl.ca> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I can't find the correct way to handle java.util.concurrent.Future
>>>>> instances
>>>>> returned from asynchronous methods in Wicket. This interface does not
>>>>> extend
>>>>> Serializable so its instances can't be stored in components or pages.
>>>>> So
>>>>> what do you do with them?
>>>>>
>>>>> Do you store them in a map in the application and keep a handle (e.g.
>>>>> an
>>>>> int) in the Wicket component?
>>>>>
>>>>> I saw code on a github repository that implemented an ajax timer
>>>>> behavior
>>>>> that keeps a reference to a Future in a transient field to update a
>>>>> status.
>>>>> However, I can't understand how that would work. Wouldn't the transient
>>>>> field be nulled out if the behavior is serialized with the page and
>>>>> then
>>>>> deserialized?
>>>>>
>>>>> Essentially, my question is: what is the standard way to handle Futures
>>>>> in
>>>>> Wicket that run longer than the page rendering? (like processing an
>>>>> order
>>>>> or
>>>>> sending emails)
>>>>>
>>>>> I hope I'm not missing something obvious, but that might be the case...
>>>>>
>>>>> Regards,
>>>>> Bertrand
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Rodolfo Hansen
CTO, KindleIT Software Development
Email: rhansen@kitsd.com
Mobile: +1 (809) 860-6669
Re: Handling futures
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Thanks for your answers Scott.
I thought Wicket could essentially serialize a page any time it sees
fit. Is that the case? If so, that would mean that even if the page
containing the Future reference is still open in the browser window, the
Future could be thrown away. Wouldn't that be a definite possibility if
a user has multiple browser windows open in the same session and keeps
browsing the site in another window while the "pending result" window is
still open?
On 23/07/2011 11:10 AM, Scott Swank wrote:
> Perhaps a transient Future would work for you after all. If the user
> navigates away the Page is serialized and the Future is thrown away.
>
> If you do put futures in a Map, perhaps in the Session, I'd wrap that
> in an AbstractReadonlyModel<Future>. Then you could use have a
> Map<Integer, SoftReference<Future>> (assuming your key is an Integer)
> if you're still concerned about memory usage getting out of hand.
>
> Scott
>
> On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet
> <be...@step.polymtl.ca> wrote:
>> I haven't actually done it yet, but the 3 steps you list are what I have in
>> mind.
>>
>> After these, I plan to use a javascript timer that polls the status of the
>> request and updates a label (or icon). That ajax behavior would be the one
>> polling the Future.
>>
>> What I can't wrap my head around is this: the ajax behavior can't directly
>> hold a reference to the Future because it can be serialized with the page.
>> On the other hand, if I store the Future in a map somewhere and keep a
>> serializable handle in the behavior, there is a possibility that the user
>> will navigate to another page before get() is called on the Future. To avoid
>> running out of memory, this means that I would need to have a daemon that
>> periodically nulls stale Futures from the map so they can be garbage
>> collected.
>>
>> This kind of operation (submit + polling asynchronous result) seems rather
>> common so I'm sure there's some (easy) way to handle it...
>>
>> On 23/07/2011 9:14 AM, Scott Swank wrote:
>>> What does your workflow look like?
>>>
>>> 1. submit form (or ajax event)
>>> 2. create Future
>>> 3. return response page (or ajax response)
>>>
>>> Now who checks the Future and what sort of UI result occurs?
>>>
>>> Scott
>>>
>>> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
>>> <be...@step.polymtl.ca> wrote:
>>>> Hello,
>>>>
>>>> I can't find the correct way to handle java.util.concurrent.Future
>>>> instances
>>>> returned from asynchronous methods in Wicket. This interface does not
>>>> extend
>>>> Serializable so its instances can't be stored in components or pages. So
>>>> what do you do with them?
>>>>
>>>> Do you store them in a map in the application and keep a handle (e.g. an
>>>> int) in the Wicket component?
>>>>
>>>> I saw code on a github repository that implemented an ajax timer behavior
>>>> that keeps a reference to a Future in a transient field to update a
>>>> status.
>>>> However, I can't understand how that would work. Wouldn't the transient
>>>> field be nulled out if the behavior is serialized with the page and then
>>>> deserialized?
>>>>
>>>> Essentially, my question is: what is the standard way to handle Futures
>>>> in
>>>> Wicket that run longer than the page rendering? (like processing an order
>>>> or
>>>> sending emails)
>>>>
>>>> I hope I'm not missing something obvious, but that might be the case...
>>>>
>>>> Regards,
>>>> Bertrand
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling futures
Posted by Scott Swank <sc...@gmail.com>.
Perhaps a transient Future would work for you after all. If the user
navigates away the Page is serialized and the Future is thrown away.
If you do put futures in a Map, perhaps in the Session, I'd wrap that
in an AbstractReadonlyModel<Future>. Then you could use have a
Map<Integer, SoftReference<Future>> (assuming your key is an Integer)
if you're still concerned about memory usage getting out of hand.
Scott
On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
> I haven't actually done it yet, but the 3 steps you list are what I have in
> mind.
>
> After these, I plan to use a javascript timer that polls the status of the
> request and updates a label (or icon). That ajax behavior would be the one
> polling the Future.
>
> What I can't wrap my head around is this: the ajax behavior can't directly
> hold a reference to the Future because it can be serialized with the page.
> On the other hand, if I store the Future in a map somewhere and keep a
> serializable handle in the behavior, there is a possibility that the user
> will navigate to another page before get() is called on the Future. To avoid
> running out of memory, this means that I would need to have a daemon that
> periodically nulls stale Futures from the map so they can be garbage
> collected.
>
> This kind of operation (submit + polling asynchronous result) seems rather
> common so I'm sure there's some (easy) way to handle it...
>
> On 23/07/2011 9:14 AM, Scott Swank wrote:
>>
>> What does your workflow look like?
>>
>> 1. submit form (or ajax event)
>> 2. create Future
>> 3. return response page (or ajax response)
>>
>> Now who checks the Future and what sort of UI result occurs?
>>
>> Scott
>>
>> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
>> <be...@step.polymtl.ca> wrote:
>>>
>>> Hello,
>>>
>>> I can't find the correct way to handle java.util.concurrent.Future
>>> instances
>>> returned from asynchronous methods in Wicket. This interface does not
>>> extend
>>> Serializable so its instances can't be stored in components or pages. So
>>> what do you do with them?
>>>
>>> Do you store them in a map in the application and keep a handle (e.g. an
>>> int) in the Wicket component?
>>>
>>> I saw code on a github repository that implemented an ajax timer behavior
>>> that keeps a reference to a Future in a transient field to update a
>>> status.
>>> However, I can't understand how that would work. Wouldn't the transient
>>> field be nulled out if the behavior is serialized with the page and then
>>> deserialized?
>>>
>>> Essentially, my question is: what is the standard way to handle Futures
>>> in
>>> Wicket that run longer than the page rendering? (like processing an order
>>> or
>>> sending emails)
>>>
>>> I hope I'm not missing something obvious, but that might be the case...
>>>
>>> Regards,
>>> Bertrand
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling futures
Posted by Hans Lesmeister <ha...@lessy-software.de>.
Did you already take a look at wicketstuff-progressbar?
Regards
Hans
Am 23.07.11 17:02 schrieb "Bertrand Guay-Paquet" unter
<be...@step.polymtl.ca>:
> I haven't actually done it yet, but the 3 steps you list are what I have
> in mind.
>
> After these, I plan to use a javascript timer that polls the status of
> the request and updates a label (or icon). That ajax behavior would be
> the one polling the Future.
>
> What I can't wrap my head around is this: the ajax behavior can't
> directly hold a reference to the Future because it can be serialized
> with the page. On the other hand, if I store the Future in a map
> somewhere and keep a serializable handle in the behavior, there is a
> possibility that the user will navigate to another page before get() is
> called on the Future. To avoid running out of memory, this means that I
> would need to have a daemon that periodically nulls stale Futures from
> the map so they can be garbage collected.
>
> This kind of operation (submit + polling asynchronous result) seems
> rather common so I'm sure there's some (easy) way to handle it...
>
> On 23/07/2011 9:14 AM, Scott Swank wrote:
>> What does your workflow look like?
>>
>> 1. submit form (or ajax event)
>> 2. create Future
>> 3. return response page (or ajax response)
>>
>> Now who checks the Future and what sort of UI result occurs?
>>
>> Scott
>>
>> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
>> <be...@step.polymtl.ca> wrote:
>>> Hello,
>>>
>>> I can't find the correct way to handle java.util.concurrent.Future instances
>>> returned from asynchronous methods in Wicket. This interface does not extend
>>> Serializable so its instances can't be stored in components or pages. So
>>> what do you do with them?
>>>
>>> Do you store them in a map in the application and keep a handle (e.g. an
>>> int) in the Wicket component?
>>>
>>> I saw code on a github repository that implemented an ajax timer behavior
>>> that keeps a reference to a Future in a transient field to update a status.
>>> However, I can't understand how that would work. Wouldn't the transient
>>> field be nulled out if the behavior is serialized with the page and then
>>> deserialized?
>>>
>>> Essentially, my question is: what is the standard way to handle Futures in
>>> Wicket that run longer than the page rendering? (like processing an order or
>>> sending emails)
>>>
>>> I hope I'm not missing something obvious, but that might be the case...
>>>
>>> Regards,
>>> Bertrand
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling futures
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
I haven't actually done it yet, but the 3 steps you list are what I have
in mind.
After these, I plan to use a javascript timer that polls the status of
the request and updates a label (or icon). That ajax behavior would be
the one polling the Future.
What I can't wrap my head around is this: the ajax behavior can't
directly hold a reference to the Future because it can be serialized
with the page. On the other hand, if I store the Future in a map
somewhere and keep a serializable handle in the behavior, there is a
possibility that the user will navigate to another page before get() is
called on the Future. To avoid running out of memory, this means that I
would need to have a daemon that periodically nulls stale Futures from
the map so they can be garbage collected.
This kind of operation (submit + polling asynchronous result) seems
rather common so I'm sure there's some (easy) way to handle it...
On 23/07/2011 9:14 AM, Scott Swank wrote:
> What does your workflow look like?
>
> 1. submit form (or ajax event)
> 2. create Future
> 3. return response page (or ajax response)
>
> Now who checks the Future and what sort of UI result occurs?
>
> Scott
>
> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
> <be...@step.polymtl.ca> wrote:
>> Hello,
>>
>> I can't find the correct way to handle java.util.concurrent.Future instances
>> returned from asynchronous methods in Wicket. This interface does not extend
>> Serializable so its instances can't be stored in components or pages. So
>> what do you do with them?
>>
>> Do you store them in a map in the application and keep a handle (e.g. an
>> int) in the Wicket component?
>>
>> I saw code on a github repository that implemented an ajax timer behavior
>> that keeps a reference to a Future in a transient field to update a status.
>> However, I can't understand how that would work. Wouldn't the transient
>> field be nulled out if the behavior is serialized with the page and then
>> deserialized?
>>
>> Essentially, my question is: what is the standard way to handle Futures in
>> Wicket that run longer than the page rendering? (like processing an order or
>> sending emails)
>>
>> I hope I'm not missing something obvious, but that might be the case...
>>
>> Regards,
>> Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling futures
Posted by Scott Swank <sc...@gmail.com>.
What does your workflow look like?
1. submit form (or ajax event)
2. create Future
3. return response page (or ajax response)
Now who checks the Future and what sort of UI result occurs?
Scott
On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
> Hello,
>
> I can't find the correct way to handle java.util.concurrent.Future instances
> returned from asynchronous methods in Wicket. This interface does not extend
> Serializable so its instances can't be stored in components or pages. So
> what do you do with them?
>
> Do you store them in a map in the application and keep a handle (e.g. an
> int) in the Wicket component?
>
> I saw code on a github repository that implemented an ajax timer behavior
> that keeps a reference to a Future in a transient field to update a status.
> However, I can't understand how that would work. Wouldn't the transient
> field be nulled out if the behavior is serialized with the page and then
> deserialized?
>
> Essentially, my question is: what is the standard way to handle Futures in
> Wicket that run longer than the page rendering? (like processing an order or
> sending emails)
>
> I hope I'm not missing something obvious, but that might be the case...
>
> Regards,
> Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org