Re: Application Scope
You can’t, and it isn’t a deficiency, just think about e.g. session replication among multiple cluster nodes. Cheers, -Tom On 06.05.2014, at 15:52, Richard W. Adams wrote: > I assume that means we can't store non-serializable objects in the > session? This is sounding like a serious deficiency in Wicket's > architecture... > > > > > From: Francois Meillet > To: users@wicket.apache.org > Date: 05/06/2014 08:48 AM > Subject:Re: Application Scope > > > > sessions are serialised > > François Meillet > Formation Wicket - Développement Wicket > > > > > > Le 6 mai 2014 à 15:28, Richard W. Adams a écrit : > >> One more question: Since each task is associated with a single user, > would >> it make more sense to create a task map in Session scope? Or will Wicket > >> try to serialize a map we put into the session? >> >> >> >> >> From: Martin Grigorov >> To: "users@wicket.apache.org" >> Date: 05/06/2014 08:06 AM >> Subject:Re: Application Scope >> >> >> >> Please don't change the thread subject for all your answers. This > confuses >> the threading support in some mail clients. >> >> I meant *My*Application, i.e. *Your*Application. >> Add this method and map/associate all tasks that your run to some > id/key. >> Serialize the key and later get a reference to the FutureTask with >> something like: >> YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/... >> >> Martin Grigorov >> Wicket Training and Consulting >> >> >> On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams > wrote: >> >>> Are you referring to org.apache.wicket.Application? I don't see a >>> getTasksMap() method there. We use Wicket 1.4.17 & our company will > not >>> allow us to upgrade to newer versions). If getTasksMap() is unavailable > >> in >>> 1.4.17, could Application.getSharedResources() be used in a similar > way? >>> >>> >>> >>> >>> From: Martin Grigorov >>> To: "users@wicket.apache.org" >>> Date: 05/06/2014 07:26 AM >>> Subject:Re: Background Threading >>> >>> >>> >>> Hi, >>> >>> You can put the tasks in an application scoped structure (e.g. >>> MyApplication.get().getTasksMap()) and use a serializable key. >>> >>> Martin Grigorov >>> Wicket Training and Consulting >>> >>> >>> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams >> wrote: >>> >>>> Interesting approach. Our use case is more complex, as it runs a >>>> background task in a separate thread. Our task has three basic >>>> requirements. It must: >>>> >>>> 1. Be cancellable. >>>> >>>> 2. Report its outcome (success/failure/warning). >>>> >>>> 3. Report incremental progress. >>>> >>>> Our fundamental problem is not how to display the progress bar, it's >> how >>>> to determine the outcome of the background thread. That's an >>> unexpectedly >>>> a tough nut to crack. The vast majority of examples we've seen use the >>>> Runnable interface (which doesn't help us, as it can't be canceled or >>>> return a value), rather than Callable interface (which meets our >> needs, >>>> but doesn't seem to play well with Wicket) >>>> >>>> >>>> >>>> >>>> From: Colin Rogers >>>> To: "users@wicket.apache.org" >>>> Date: 05/05/2014 08:14 PM >>>> Subject:RE: Progress Bar >>>> >>>> >>>> >>>> There is a pretty nifty, jquery based progress bar, in >> wicket-jquery-ui >>>> library... >>>> >>>> >>> >> > http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage >>>> >>>> Cheers, >>>> Col. >>>> >>>> -Original Message- >>>> From: Richard W. Adams [mailto:rwada...@up.com] >>>> Sent: Tuesday, 6 May 2014 3:19 AM >>>> To: users@wicket.apache.org >>>> Subject: Progress Bar >>>> >>>> We have a requirement to implement a progress bar for long-running >>> server >>>> operations. We
Re: Application Scope
That's a javax.servlet restriction:
http://stackoverflow.com/questions/1662348/setattribute-non-serializable-attribute-java-object-serialization
http://stackoverflow.com/questions/3460249/java-httpsession-setattribute-throws-non-serializable-exception-on-qa-but-not-i
Sven
On 05/06/2014 03:52 PM, Richard W. Adams wrote:
I assume that means we can't store non-serializable objects in the
session? This is sounding like a serious deficiency in Wicket's
architecture...
From: Francois Meillet
To: users@wicket.apache.org
Date: 05/06/2014 08:48 AM
Subject:Re: Application Scope
sessions are serialised
François Meillet
Formation Wicket - Développement Wicket
Le 6 mai 2014 à 15:28, Richard W. Adams a écrit :
One more question: Since each task is associated with a single user,
would
it make more sense to create a task map in Session scope? Or will Wicket
try to serialize a map we put into the session?
From: Martin Grigorov
To: "users@wicket.apache.org"
Date: 05/06/2014 08:06 AM
Subject:Re: Application Scope
Please don't change the thread subject for all your answers. This
confuses
the threading support in some mail clients.
I meant *My*Application, i.e. *Your*Application.
Add this method and map/associate all tasks that your run to some
id/key.
Serialize the key and later get a reference to the FutureTask with
something like:
YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/...
Martin Grigorov
Wicket Training and Consulting
On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams
wrote:
Are you referring to org.apache.wicket.Application? I don't see a
getTasksMap() method there. We use Wicket 1.4.17 & our company will
not
allow us to upgrade to newer versions). If getTasksMap() is unavailable
in
1.4.17, could Application.getSharedResources() be used in a similar
way?
From: Martin Grigorov
To: "users@wicket.apache.org"
Date: 05/06/2014 07:26 AM
Subject:Re: Background Threading
Hi,
You can put the tasks in an application scoped structure (e.g.
MyApplication.get().getTasksMap()) and use a serializable key.
Martin Grigorov
Wicket Training and Consulting
On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams
wrote:
Interesting approach. Our use case is more complex, as it runs a
background task in a separate thread. Our task has three basic
requirements. It must:
1. Be cancellable.
2. Report its outcome (success/failure/warning).
3. Report incremental progress.
Our fundamental problem is not how to display the progress bar, it's
how
to determine the outcome of the background thread. That's an
unexpectedly
a tough nut to crack. The vast majority of examples we've seen use the
Runnable interface (which doesn't help us, as it can't be canceled or
return a value), rather than Callable interface (which meets our
needs,
but doesn't seem to play well with Wicket)
From: Colin Rogers
To: "users@wicket.apache.org"
Date: 05/05/2014 08:14 PM
Subject:RE: Progress Bar
There is a pretty nifty, jquery based progress bar, in
wicket-jquery-ui
library...
http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
Cheers,
Col.
-Original Message-
From: Richard W. Adams [mailto:rwada...@up.com]
Sent: Tuesday, 6 May 2014 3:19 AM
To: users@wicket.apache.org
Subject: Progress Bar
We have a requirement to implement a progress bar for long-running
server
operations. We can't use the code at
https://github.com/wicketstuff/core/wiki/Progressbar, because it
doesn't
meet our corporate user interface look-and-feel standards.
So, we started our own implementation. Our test page contains these
methods below (the TestExecutor below class implements
Callable).
//--
private Component createButton() {
return new AjaxButton("start-button") {
private static final long serialVersionUID = -1;
@Override protected void onSubmit(final
AjaxRequestTarget
ajax, final Form form) {
final ExecutorService service = Executors.
newSingleThreadExecutor();
try {
final ProgressBarTestPage page =
ProgressBarTestPage.this;
final TransactionData data = new
TransactionData (page.getId(), false);
final TestExecutor executor = new
TestExecutor(data, getPermissions());
executor.addListener(page); //
Request
notification when done
future = service.submit(executor); //
Begin execution
progressBarUpdater.start(ajax,
executor);
// Start polling for progress
Re: Application Scope
It is not a limitation of wicket but J2EE specification. On Tue, May 6, 2014 at 3:52 PM, Richard W. Adams wrote: > I assume that means we can't store non-serializable objects in the > session? This is sounding like a serious deficiency in Wicket's > architecture... > > > > > From: Francois Meillet > To: users@wicket.apache.org > Date: 05/06/2014 08:48 AM > Subject:Re: Application Scope > > > > sessions are serialised > > François Meillet > Formation Wicket - Développement Wicket > > > > > > Le 6 mai 2014 à 15:28, Richard W. Adams a écrit : > > > One more question: Since each task is associated with a single user, > would > > it make more sense to create a task map in Session scope? Or will Wicket > > > try to serialize a map we put into the session? > > > > > > > > > > From: Martin Grigorov > > To: "users@wicket.apache.org" > > Date: 05/06/2014 08:06 AM > > Subject:Re: Application Scope > > > > > > > > Please don't change the thread subject for all your answers. This > confuses > > the threading support in some mail clients. > > > > I meant *My*Application, i.e. *Your*Application. > > Add this method and map/associate all tasks that your run to some > id/key. > > Serialize the key and later get a reference to the FutureTask with > > something like: > > YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/... > > > > Martin Grigorov > > Wicket Training and Consulting > > > > > > On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams > wrote: > > > >> Are you referring to org.apache.wicket.Application? I don't see a > >> getTasksMap() method there. We use Wicket 1.4.17 & our company will > not > >> allow us to upgrade to newer versions). If getTasksMap() is unavailable > > > in > >> 1.4.17, could Application.getSharedResources() be used in a similar > way? > >> > >> > >> > >> > >> From: Martin Grigorov > >> To: "users@wicket.apache.org" > >> Date: 05/06/2014 07:26 AM > >> Subject:Re: Background Threading > >> > >> > >> > >> Hi, > >> > >> You can put the tasks in an application scoped structure (e.g. > >> MyApplication.get().getTasksMap()) and use a serializable key. > >> > >> Martin Grigorov > >> Wicket Training and Consulting > >> > >> > >> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams > > wrote: > >> > >>> Interesting approach. Our use case is more complex, as it runs a > >>> background task in a separate thread. Our task has three basic > >>> requirements. It must: > >>> > >>> 1. Be cancellable. > >>> > >>> 2. Report its outcome (success/failure/warning). > >>> > >>> 3. Report incremental progress. > >>> > >>> Our fundamental problem is not how to display the progress bar, it's > > how > >>> to determine the outcome of the background thread. That's an > >> unexpectedly > >>> a tough nut to crack. The vast majority of examples we've seen use the > >>> Runnable interface (which doesn't help us, as it can't be canceled or > >>> return a value), rather than Callable interface (which meets our > > needs, > >>> but doesn't seem to play well with Wicket) > >>> > >>> > >>> > >>> > >>> From: Colin Rogers > >>> To: "users@wicket.apache.org" > >>> Date: 05/05/2014 08:14 PM > >>> Subject:RE: Progress Bar > >>> > >>> > >>> > >>> There is a pretty nifty, jquery based progress bar, in > > wicket-jquery-ui > >>> library... > >>> > >>> > >> > > > http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage > >>> > >>> Cheers, > >>> Col. > >>> > >>> -Original Message- > >>> From: Richard W. Adams [mailto:rwada...@up.com] > >>> Sent: Tuesday, 6 May 2014 3:19 AM > >>> To: users@wicket.apache.org > >>> Subject: Progress Bar > >>> > >>> We have a requirement to implement a progress bar for long-running > >> server > >>> operations. We can't use the code at >
Re: Application Scope
I assume that means we can't store non-serializable objects in the
session? This is sounding like a serious deficiency in Wicket's
architecture...
From: Francois Meillet
To: users@wicket.apache.org
Date: 05/06/2014 08:48 AM
Subject: Re: Application Scope
sessions are serialised
François Meillet
Formation Wicket - Développement Wicket
Le 6 mai 2014 à 15:28, Richard W. Adams a écrit :
> One more question: Since each task is associated with a single user,
would
> it make more sense to create a task map in Session scope? Or will Wicket
> try to serialize a map we put into the session?
>
>
>
>
> From: Martin Grigorov
> To: "users@wicket.apache.org"
> Date: 05/06/2014 08:06 AM
> Subject:Re: Application Scope
>
>
>
> Please don't change the thread subject for all your answers. This
confuses
> the threading support in some mail clients.
>
> I meant *My*Application, i.e. *Your*Application.
> Add this method and map/associate all tasks that your run to some
id/key.
> Serialize the key and later get a reference to the FutureTask with
> something like:
> YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/...
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams
wrote:
>
>> Are you referring to org.apache.wicket.Application? I don't see a
>> getTasksMap() method there. We use Wicket 1.4.17 & our company will
not
>> allow us to upgrade to newer versions). If getTasksMap() is unavailable
> in
>> 1.4.17, could Application.getSharedResources() be used in a similar
way?
>>
>>
>>
>>
>> From: Martin Grigorov
>> To: "users@wicket.apache.org"
>> Date: 05/06/2014 07:26 AM
>> Subject:Re: Background Threading
>>
>>
>>
>> Hi,
>>
>> You can put the tasks in an application scoped structure (e.g.
>> MyApplication.get().getTasksMap()) and use a serializable key.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>>
>>
>> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams
> wrote:
>>
>>> Interesting approach. Our use case is more complex, as it runs a
>>> background task in a separate thread. Our task has three basic
>>> requirements. It must:
>>>
>>> 1. Be cancellable.
>>>
>>> 2. Report its outcome (success/failure/warning).
>>>
>>> 3. Report incremental progress.
>>>
>>> Our fundamental problem is not how to display the progress bar, it's
> how
>>> to determine the outcome of the background thread. That's an
>> unexpectedly
>>> a tough nut to crack. The vast majority of examples we've seen use the
>>> Runnable interface (which doesn't help us, as it can't be canceled or
>>> return a value), rather than Callable interface (which meets our
> needs,
>>> but doesn't seem to play well with Wicket)
>>>
>>>
>>>
>>>
>>> From: Colin Rogers
>>> To: "users@wicket.apache.org"
>>> Date: 05/05/2014 08:14 PM
>>> Subject:RE: Progress Bar
>>>
>>>
>>>
>>> There is a pretty nifty, jquery based progress bar, in
> wicket-jquery-ui
>>> library...
>>>
>>>
>>
>
http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
>>>
>>> Cheers,
>>> Col.
>>>
>>> -Original Message-
>>> From: Richard W. Adams [mailto:rwada...@up.com]
>>> Sent: Tuesday, 6 May 2014 3:19 AM
>>> To: users@wicket.apache.org
>>> Subject: Progress Bar
>>>
>>> We have a requirement to implement a progress bar for long-running
>> server
>>> operations. We can't use the code at
>>> https://github.com/wicketstuff/core/wiki/Progressbar, because it
> doesn't
>>> meet our corporate user interface look-and-feel standards.
>>>
>>> So, we started our own implementation. Our test page contains these
>>> methods below (the TestExecutor below class implements
>>> Callable).
>>>
>>>
>>>
>>
>>
>
//--
>>> private Component createButton() {
>>>return new AjaxButton("start-button") {
>>>private static final long serialVersionUID = -1;
>>>
>>>@
Re: Application Scope
The Javadocs for setMetaData() & MetaDataKey are somewhat unclear (to me).
It says the meta data key has to be a singleton. This seems to imply you
can only store only one piece of metadata for a given component (e.g., a
page)? If so, that's not helpful, since I have to to store many
potentially many (similar) pieces of data (read FutureTask) for the same
page in a multi-user environment: That is, one for each user who's running
the background task thread.
This would be much easier if I could store something non-serializeable in
session scope. Storing things in application scope is beginning to sound
like an extremely awkward work around. Can WebSession store things that
are not serializable? I'm guessing not, since WebSession itself implements
Serializable.
From: Francois Meillet
To: users@wicket.apache.org
Date: 05/06/2014 08:06 AM
Subject: Re: Application Scope
You can use MyApp.get().setMetaData() and MyApp.get().getMetaData()
François Meillet
Formation Wicket - Développement Wicket
Le 6 mai 2014 à 14:50, Richard W. Adams a écrit :
> Are you referring to org.apache.wicket.Application? I don't see a
> getTasksMap() method there. We use Wicket 1.4.17 & our company will not
> allow us to upgrade to newer versions). If getTasksMap() is unavailable
in
> 1.4.17, could Application.getSharedResources() be used in a similar way?
>
>
>
>
> From: Martin Grigorov
> To: "users@wicket.apache.org"
> Date: 05/06/2014 07:26 AM
> Subject:Re: Background Threading
>
>
>
> Hi,
>
> You can put the tasks in an application scoped structure (e.g.
> MyApplication.get().getTasksMap()) and use a serializable key.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams
wrote:
>
>> Interesting approach. Our use case is more complex, as it runs a
>> background task in a separate thread. Our task has three basic
>> requirements. It must:
>>
>> 1. Be cancellable.
>>
>> 2. Report its outcome (success/failure/warning).
>>
>> 3. Report incremental progress.
>>
>> Our fundamental problem is not how to display the progress bar, it's
how
>> to determine the outcome of the background thread. That's an
> unexpectedly
>> a tough nut to crack. The vast majority of examples we've seen use the
>> Runnable interface (which doesn't help us, as it can't be canceled or
>> return a value), rather than Callable interface (which meets our needs,
>> but doesn't seem to play well with Wicket)
>>
>>
>>
>>
>> From: Colin Rogers
>> To: "users@wicket.apache.org"
>> Date: 05/05/2014 08:14 PM
>> Subject:RE: Progress Bar
>>
>>
>>
>> There is a pretty nifty, jquery based progress bar, in wicket-jquery-ui
>> library...
>>
>>
>
http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
>>
>> Cheers,
>> Col.
>>
>> -Original Message-
>> From: Richard W. Adams [mailto:rwada...@up.com]
>> Sent: Tuesday, 6 May 2014 3:19 AM
>> To: users@wicket.apache.org
>> Subject: Progress Bar
>>
>> We have a requirement to implement a progress bar for long-running
> server
>> operations. We can't use the code at
>> https://github.com/wicketstuff/core/wiki/Progressbar, because it
doesn't
>> meet our corporate user interface look-and-feel standards.
>>
>> So, we started our own implementation. Our test page contains these
>> methods below (the TestExecutor below class implements
>> Callable).
>>
>>
>>
>
//--
>> private Component createButton() {
>>return new AjaxButton("start-button") {
>>private static final long serialVersionUID = -1;
>>
>>@Override protected void onSubmit(final
> AjaxRequestTarget
>> ajax, final Form form) {
>>
>>final ExecutorService service = Executors.
>> newSingleThreadExecutor();
>>try {
>>final ProgressBarTestPage page =
>> ProgressBarTestPage.this;
>>final TransactionData data = new
>> TransactionData (page.getId(), false);
>>final TestExecutor executor = new
>> TestExecutor(data, getPermissions());
>>
>>
Re: Application Scope
sessions are serialised
François Meillet
Formation Wicket - Développement Wicket
Le 6 mai 2014 à 15:28, Richard W. Adams a écrit :
> One more question: Since each task is associated with a single user, would
> it make more sense to create a task map in Session scope? Or will Wicket
> try to serialize a map we put into the session?
>
>
>
>
> From: Martin Grigorov
> To: "users@wicket.apache.org"
> Date: 05/06/2014 08:06 AM
> Subject:Re: Application Scope
>
>
>
> Please don't change the thread subject for all your answers. This confuses
> the threading support in some mail clients.
>
> I meant *My*Application, i.e. *Your*Application.
> Add this method and map/associate all tasks that your run to some id/key.
> Serialize the key and later get a reference to the FutureTask with
> something like:
> YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/...
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams wrote:
>
>> Are you referring to org.apache.wicket.Application? I don't see a
>> getTasksMap() method there. We use Wicket 1.4.17 & our company will not
>> allow us to upgrade to newer versions). If getTasksMap() is unavailable
> in
>> 1.4.17, could Application.getSharedResources() be used in a similar way?
>>
>>
>>
>>
>> From: Martin Grigorov
>> To: "users@wicket.apache.org"
>> Date: 05/06/2014 07:26 AM
>> Subject:Re: Background Threading
>>
>>
>>
>> Hi,
>>
>> You can put the tasks in an application scoped structure (e.g.
>> MyApplication.get().getTasksMap()) and use a serializable key.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>>
>>
>> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams
> wrote:
>>
>>> Interesting approach. Our use case is more complex, as it runs a
>>> background task in a separate thread. Our task has three basic
>>> requirements. It must:
>>>
>>> 1. Be cancellable.
>>>
>>> 2. Report its outcome (success/failure/warning).
>>>
>>> 3. Report incremental progress.
>>>
>>> Our fundamental problem is not how to display the progress bar, it's
> how
>>> to determine the outcome of the background thread. That's an
>> unexpectedly
>>> a tough nut to crack. The vast majority of examples we've seen use the
>>> Runnable interface (which doesn't help us, as it can't be canceled or
>>> return a value), rather than Callable interface (which meets our
> needs,
>>> but doesn't seem to play well with Wicket)
>>>
>>>
>>>
>>>
>>> From: Colin Rogers
>>> To: "users@wicket.apache.org"
>>> Date: 05/05/2014 08:14 PM
>>> Subject:RE: Progress Bar
>>>
>>>
>>>
>>> There is a pretty nifty, jquery based progress bar, in
> wicket-jquery-ui
>>> library...
>>>
>>>
>>
> http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
>>>
>>> Cheers,
>>> Col.
>>>
>>> -Original Message-
>>> From: Richard W. Adams [mailto:rwada...@up.com]
>>> Sent: Tuesday, 6 May 2014 3:19 AM
>>> To: users@wicket.apache.org
>>> Subject: Progress Bar
>>>
>>> We have a requirement to implement a progress bar for long-running
>> server
>>> operations. We can't use the code at
>>> https://github.com/wicketstuff/core/wiki/Progressbar, because it
> doesn't
>>> meet our corporate user interface look-and-feel standards.
>>>
>>> So, we started our own implementation. Our test page contains these
>>> methods below (the TestExecutor below class implements
>>> Callable).
>>>
>>>
>>>
>>
>>
> //--
>>> private Component createButton() {
>>>return new AjaxButton("start-button") {
>>>private static final long serialVersionUID = -1;
>>>
>>>@Override protected void onSubmit(final
>> AjaxRequestTarget
>>> ajax, final Form form) {
>>>
>>>final ExecutorService service = Executors.
>>> newSingleThreadExecutor();
>>>try {
>>>
Re: Application Scope
One more question: Since each task is associated with a single user, would
it make more sense to create a task map in Session scope? Or will Wicket
try to serialize a map we put into the session?
From: Martin Grigorov
To: "users@wicket.apache.org"
Date: 05/06/2014 08:06 AM
Subject: Re: Application Scope
Please don't change the thread subject for all your answers. This confuses
the threading support in some mail clients.
I meant *My*Application, i.e. *Your*Application.
Add this method and map/associate all tasks that your run to some id/key.
Serialize the key and later get a reference to the FutureTask with
something like:
YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/...
Martin Grigorov
Wicket Training and Consulting
On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams wrote:
> Are you referring to org.apache.wicket.Application? I don't see a
> getTasksMap() method there. We use Wicket 1.4.17 & our company will not
> allow us to upgrade to newer versions). If getTasksMap() is unavailable
in
> 1.4.17, could Application.getSharedResources() be used in a similar way?
>
>
>
>
> From: Martin Grigorov
> To: "users@wicket.apache.org"
> Date: 05/06/2014 07:26 AM
> Subject:Re: Background Threading
>
>
>
> Hi,
>
> You can put the tasks in an application scoped structure (e.g.
> MyApplication.get().getTasksMap()) and use a serializable key.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams
wrote:
>
> > Interesting approach. Our use case is more complex, as it runs a
> > background task in a separate thread. Our task has three basic
> > requirements. It must:
> >
> > 1. Be cancellable.
> >
> > 2. Report its outcome (success/failure/warning).
> >
> > 3. Report incremental progress.
> >
> > Our fundamental problem is not how to display the progress bar, it's
how
> > to determine the outcome of the background thread. That's an
> unexpectedly
> > a tough nut to crack. The vast majority of examples we've seen use the
> > Runnable interface (which doesn't help us, as it can't be canceled or
> > return a value), rather than Callable interface (which meets our
needs,
> > but doesn't seem to play well with Wicket)
> >
> >
> >
> >
> > From: Colin Rogers
> > To: "users@wicket.apache.org"
> > Date: 05/05/2014 08:14 PM
> > Subject:RE: Progress Bar
> >
> >
> >
> > There is a pretty nifty, jquery based progress bar, in
wicket-jquery-ui
> > library...
> >
> >
>
http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
> >
> > Cheers,
> > Col.
> >
> > -Original Message-
> > From: Richard W. Adams [mailto:rwada...@up.com]
> > Sent: Tuesday, 6 May 2014 3:19 AM
> > To: users@wicket.apache.org
> > Subject: Progress Bar
> >
> > We have a requirement to implement a progress bar for long-running
> server
> > operations. We can't use the code at
> > https://github.com/wicketstuff/core/wiki/Progressbar, because it
doesn't
> > meet our corporate user interface look-and-feel standards.
> >
> > So, we started our own implementation. Our test page contains these
> > methods below (the TestExecutor below class implements
> > Callable).
> >
> >
> >
>
>
//--
> > private Component createButton() {
> > return new AjaxButton("start-button") {
> > private static final long serialVersionUID = -1;
> >
> > @Override protected void onSubmit(final
> AjaxRequestTarget
> > ajax, final Form form) {
> >
> > final ExecutorService service = Executors.
> > newSingleThreadExecutor();
> > try {
> > final ProgressBarTestPage page =
> > ProgressBarTestPage.this;
> > final TransactionData data = new
> > TransactionData (page.getId(), false);
> > final TestExecutor executor = new
> > TestExecutor(data, getPermissions());
> >
> > executor.addListener(page); //
> Request
> > notification when done
> > future = service.submit(executor); //
> > Begin execution
> > progressBarUpdater.start(ajax,
> executor);
&g
Re: Application Scope
To clarify: Are you saying that we should add our own setTask() &
getTask() methods to our application class? And then maintain a task map
as a member variable of our application class?
From: Martin Grigorov
To: "users@wicket.apache.org"
Date: 05/06/2014 08:06 AM
Subject:Re: Application Scope
Please don't change the thread subject for all your answers. This confuses
the threading support in some mail clients.
I meant *My*Application, i.e. *Your*Application.
Add this method and map/associate all tasks that your run to some id/key.
Serialize the key and later get a reference to the FutureTask with
something like:
YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/...
Martin Grigorov
Wicket Training and Consulting
On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams wrote:
> Are you referring to org.apache.wicket.Application? I don't see a
> getTasksMap() method there. We use Wicket 1.4.17 & our company will not
> allow us to upgrade to newer versions). If getTasksMap() is unavailable
in
> 1.4.17, could Application.getSharedResources() be used in a similar way?
>
>
>
>
> From: Martin Grigorov
> To: "users@wicket.apache.org"
> Date: 05/06/2014 07:26 AM
> Subject:Re: Background Threading
>
>
>
> Hi,
>
> You can put the tasks in an application scoped structure (e.g.
> MyApplication.get().getTasksMap()) and use a serializable key.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams
wrote:
>
> > Interesting approach. Our use case is more complex, as it runs a
> > background task in a separate thread. Our task has three basic
> > requirements. It must:
> >
> > 1. Be cancellable.
> >
> > 2. Report its outcome (success/failure/warning).
> >
> > 3. Report incremental progress.
> >
> > Our fundamental problem is not how to display the progress bar, it's
how
> > to determine the outcome of the background thread. That's an
> unexpectedly
> > a tough nut to crack. The vast majority of examples we've seen use the
> > Runnable interface (which doesn't help us, as it can't be canceled or
> > return a value), rather than Callable interface (which meets our
needs,
> > but doesn't seem to play well with Wicket)
> >
> >
> >
> >
> > From: Colin Rogers
> > To: "users@wicket.apache.org"
> > Date: 05/05/2014 08:14 PM
> > Subject:RE: Progress Bar
> >
> >
> >
> > There is a pretty nifty, jquery based progress bar, in
wicket-jquery-ui
> > library...
> >
> >
>
http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
> >
> > Cheers,
> > Col.
> >
> > -Original Message-
> > From: Richard W. Adams [mailto:rwada...@up.com]
> > Sent: Tuesday, 6 May 2014 3:19 AM
> > To: users@wicket.apache.org
> > Subject: Progress Bar
> >
> > We have a requirement to implement a progress bar for long-running
> server
> > operations. We can't use the code at
> > https://github.com/wicketstuff/core/wiki/Progressbar, because it
doesn't
> > meet our corporate user interface look-and-feel standards.
> >
> > So, we started our own implementation. Our test page contains these
> > methods below (the TestExecutor below class implements
> > Callable).
> >
> >
> >
>
>
//--
> > private Component createButton() {
> > return new AjaxButton("start-button") {
> > private static final long serialVersionUID = -1;
> >
> > @Override protected void onSubmit(final
> AjaxRequestTarget
> > ajax, final Form form) {
> >
> > final ExecutorService service = Executors.
> > newSingleThreadExecutor();
> > try {
> > final ProgressBarTestPage page =
> > ProgressBarTestPage.this;
> > final TransactionData data = new
> > TransactionData (page.getId(), false);
> > final TestExecutor executor = new
> > TestExecutor(data, getPermissions());
> >
> > executor.addListener(page); //
> Request
> > notification when done
> > future = service.submit(executor); //
> > Begin execution
> > progressBarUpdater.start(ajax,
> executor);
>
Re: Application Scope
You can use MyApp.get().setMetaData() and MyApp.get().getMetaData()
François Meillet
Formation Wicket - Développement Wicket
Le 6 mai 2014 à 14:50, Richard W. Adams a écrit :
> Are you referring to org.apache.wicket.Application? I don't see a
> getTasksMap() method there. We use Wicket 1.4.17 & our company will not
> allow us to upgrade to newer versions). If getTasksMap() is unavailable in
> 1.4.17, could Application.getSharedResources() be used in a similar way?
>
>
>
>
> From: Martin Grigorov
> To: "users@wicket.apache.org"
> Date: 05/06/2014 07:26 AM
> Subject:Re: Background Threading
>
>
>
> Hi,
>
> You can put the tasks in an application scoped structure (e.g.
> MyApplication.get().getTasksMap()) and use a serializable key.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams wrote:
>
>> Interesting approach. Our use case is more complex, as it runs a
>> background task in a separate thread. Our task has three basic
>> requirements. It must:
>>
>> 1. Be cancellable.
>>
>> 2. Report its outcome (success/failure/warning).
>>
>> 3. Report incremental progress.
>>
>> Our fundamental problem is not how to display the progress bar, it's how
>> to determine the outcome of the background thread. That's an
> unexpectedly
>> a tough nut to crack. The vast majority of examples we've seen use the
>> Runnable interface (which doesn't help us, as it can't be canceled or
>> return a value), rather than Callable interface (which meets our needs,
>> but doesn't seem to play well with Wicket)
>>
>>
>>
>>
>> From: Colin Rogers
>> To: "users@wicket.apache.org"
>> Date: 05/05/2014 08:14 PM
>> Subject:RE: Progress Bar
>>
>>
>>
>> There is a pretty nifty, jquery based progress bar, in wicket-jquery-ui
>> library...
>>
>>
> http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
>>
>> Cheers,
>> Col.
>>
>> -Original Message-
>> From: Richard W. Adams [mailto:rwada...@up.com]
>> Sent: Tuesday, 6 May 2014 3:19 AM
>> To: users@wicket.apache.org
>> Subject: Progress Bar
>>
>> We have a requirement to implement a progress bar for long-running
> server
>> operations. We can't use the code at
>> https://github.com/wicketstuff/core/wiki/Progressbar, because it doesn't
>> meet our corporate user interface look-and-feel standards.
>>
>> So, we started our own implementation. Our test page contains these
>> methods below (the TestExecutor below class implements
>> Callable).
>>
>>
>>
> //--
>> private Component createButton() {
>>return new AjaxButton("start-button") {
>>private static final long serialVersionUID = -1;
>>
>>@Override protected void onSubmit(final
> AjaxRequestTarget
>> ajax, final Form form) {
>>
>>final ExecutorService service = Executors.
>> newSingleThreadExecutor();
>>try {
>>final ProgressBarTestPage page =
>> ProgressBarTestPage.this;
>>final TransactionData data = new
>> TransactionData (page.getId(), false);
>>final TestExecutor executor = new
>> TestExecutor(data, getPermissions());
>>
>>executor.addListener(page); //
> Request
>> notification when done
>>future = service.submit(executor); //
>> Begin execution
>>progressBarUpdater.start(ajax,
> executor);
>> // Start polling for progress
>>
>>} catch (final Exception ex) {
>>throw new RuntimeException(ex);
>>}
>>service.shutdown(); // Terminate gracefully
>> (VM probably
>>} // won't exit if we fail to do
> this)
>>};
>> }
>>
>>
> //--
>> /**
>> Observer Pattern method to let us know when the task is done so we
> can
>> check how things went.
>> */
>> @Override public void executionComplete(final EnmCallableExecutor
>> executor) {
>>
>>try {
>>if (!future.isCancelled()) { //
>> Unless execution was canceled
>>final ExecutorResult result = future.get(); //
>> Get the outcome
>>System.out.println(result);
>>/*
>> * TODO: Show success or error message
>> */
>>}
>>} catch (final Exception ex) {
>>ex.printStackTrace();
>>}
>> }
>>
>> The ProgessBarUpdater class has this method:
>>
>>
>>
> //--
>> /
Re: Application Scope
Please don't change the thread subject for all your answers. This confuses
the threading support in some mail clients.
I meant *My*Application, i.e. *Your*Application.
Add this method and map/associate all tasks that your run to some id/key.
Serialize the key and later get a reference to the FutureTask with
something like:
YourApp.get().getTasks().get(theKey).isDone()/.isCanceled()/...
Martin Grigorov
Wicket Training and Consulting
On Tue, May 6, 2014 at 2:50 PM, Richard W. Adams wrote:
> Are you referring to org.apache.wicket.Application? I don't see a
> getTasksMap() method there. We use Wicket 1.4.17 & our company will not
> allow us to upgrade to newer versions). If getTasksMap() is unavailable in
> 1.4.17, could Application.getSharedResources() be used in a similar way?
>
>
>
>
> From: Martin Grigorov
> To: "users@wicket.apache.org"
> Date: 05/06/2014 07:26 AM
> Subject:Re: Background Threading
>
>
>
> Hi,
>
> You can put the tasks in an application scoped structure (e.g.
> MyApplication.get().getTasksMap()) and use a serializable key.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams wrote:
>
> > Interesting approach. Our use case is more complex, as it runs a
> > background task in a separate thread. Our task has three basic
> > requirements. It must:
> >
> > 1. Be cancellable.
> >
> > 2. Report its outcome (success/failure/warning).
> >
> > 3. Report incremental progress.
> >
> > Our fundamental problem is not how to display the progress bar, it's how
> > to determine the outcome of the background thread. That's an
> unexpectedly
> > a tough nut to crack. The vast majority of examples we've seen use the
> > Runnable interface (which doesn't help us, as it can't be canceled or
> > return a value), rather than Callable interface (which meets our needs,
> > but doesn't seem to play well with Wicket)
> >
> >
> >
> >
> > From: Colin Rogers
> > To: "users@wicket.apache.org"
> > Date: 05/05/2014 08:14 PM
> > Subject:RE: Progress Bar
> >
> >
> >
> > There is a pretty nifty, jquery based progress bar, in wicket-jquery-ui
> > library...
> >
> >
> http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
> >
> > Cheers,
> > Col.
> >
> > -Original Message-
> > From: Richard W. Adams [mailto:rwada...@up.com]
> > Sent: Tuesday, 6 May 2014 3:19 AM
> > To: users@wicket.apache.org
> > Subject: Progress Bar
> >
> > We have a requirement to implement a progress bar for long-running
> server
> > operations. We can't use the code at
> > https://github.com/wicketstuff/core/wiki/Progressbar, because it doesn't
> > meet our corporate user interface look-and-feel standards.
> >
> > So, we started our own implementation. Our test page contains these
> > methods below (the TestExecutor below class implements
> > Callable).
> >
> >
> >
>
> //--
> > private Component createButton() {
> > return new AjaxButton("start-button") {
> > private static final long serialVersionUID = -1;
> >
> > @Override protected void onSubmit(final
> AjaxRequestTarget
> > ajax, final Form form) {
> >
> > final ExecutorService service = Executors.
> > newSingleThreadExecutor();
> > try {
> > final ProgressBarTestPage page =
> > ProgressBarTestPage.this;
> > final TransactionData data = new
> > TransactionData (page.getId(), false);
> > final TestExecutor executor = new
> > TestExecutor(data, getPermissions());
> >
> > executor.addListener(page); //
> Request
> > notification when done
> > future = service.submit(executor); //
> > Begin execution
> > progressBarUpdater.start(ajax,
> executor);
> > // Start polling for progress
> >
> > } catch (final Exception ex) {
> > throw new RuntimeException(ex);
> > }
> > service.shutdown(); // Terminate gracefully
> > (VM probably
> > } // won't exit if we fail to do
> this)
> > };
> > }
> >
> >
>
> //--
> > /**
> >Observer Pattern method to let us know when the task is done so we
> can
> > check how things went.
> > */
> > @Override public void executionComplete(final EnmCallableExecutor
> > executor) {
> >
> > try {
> > if (!future.isCancelled()) { //
> > Unless execution was canceled
> > final ExecutorResult result = future.get(); //
> > Get the outcome
> > System.out.println(result);
> >
Application Scope
Are you referring to org.apache.wicket.Application? I don't see a
getTasksMap() method there. We use Wicket 1.4.17 & our company will not
allow us to upgrade to newer versions). If getTasksMap() is unavailable in
1.4.17, could Application.getSharedResources() be used in a similar way?
From: Martin Grigorov
To: "users@wicket.apache.org"
Date: 05/06/2014 07:26 AM
Subject:Re: Background Threading
Hi,
You can put the tasks in an application scoped structure (e.g.
MyApplication.get().getTasksMap()) and use a serializable key.
Martin Grigorov
Wicket Training and Consulting
On Tue, May 6, 2014 at 2:11 PM, Richard W. Adams wrote:
> Interesting approach. Our use case is more complex, as it runs a
> background task in a separate thread. Our task has three basic
> requirements. It must:
>
> 1. Be cancellable.
>
> 2. Report its outcome (success/failure/warning).
>
> 3. Report incremental progress.
>
> Our fundamental problem is not how to display the progress bar, it's how
> to determine the outcome of the background thread. That's an
unexpectedly
> a tough nut to crack. The vast majority of examples we've seen use the
> Runnable interface (which doesn't help us, as it can't be canceled or
> return a value), rather than Callable interface (which meets our needs,
> but doesn't seem to play well with Wicket)
>
>
>
>
> From: Colin Rogers
> To: "users@wicket.apache.org"
> Date: 05/05/2014 08:14 PM
> Subject:RE: Progress Bar
>
>
>
> There is a pretty nifty, jquery based progress bar, in wicket-jquery-ui
> library...
>
>
http://www.7thweb.net/wicket-jquery-ui/progressbar/DefaultProgressBarPage
>
> Cheers,
> Col.
>
> -Original Message-
> From: Richard W. Adams [mailto:rwada...@up.com]
> Sent: Tuesday, 6 May 2014 3:19 AM
> To: users@wicket.apache.org
> Subject: Progress Bar
>
> We have a requirement to implement a progress bar for long-running
server
> operations. We can't use the code at
> https://github.com/wicketstuff/core/wiki/Progressbar, because it doesn't
> meet our corporate user interface look-and-feel standards.
>
> So, we started our own implementation. Our test page contains these
> methods below (the TestExecutor below class implements
> Callable).
>
>
>
//--
> private Component createButton() {
> return new AjaxButton("start-button") {
> private static final long serialVersionUID = -1;
>
> @Override protected void onSubmit(final
AjaxRequestTarget
> ajax, final Form form) {
>
> final ExecutorService service = Executors.
> newSingleThreadExecutor();
> try {
> final ProgressBarTestPage page =
> ProgressBarTestPage.this;
> final TransactionData data = new
> TransactionData (page.getId(), false);
> final TestExecutor executor = new
> TestExecutor(data, getPermissions());
>
> executor.addListener(page); //
Request
> notification when done
> future = service.submit(executor); //
> Begin execution
> progressBarUpdater.start(ajax,
executor);
> // Start polling for progress
>
> } catch (final Exception ex) {
> throw new RuntimeException(ex);
> }
> service.shutdown(); // Terminate gracefully
> (VM probably
> } // won't exit if we fail to do
this)
> };
> }
>
>
//--
> /**
>Observer Pattern method to let us know when the task is done so we
can
> check how things went.
> */
> @Override public void executionComplete(final EnmCallableExecutor
> executor) {
>
> try {
> if (!future.isCancelled()) { //
> Unless execution was canceled
> final ExecutorResult result = future.get(); //
> Get the outcome
> System.out.println(result);
> /*
> * TODO: Show success or error message
> */
> }
> } catch (final Exception ex) {
> ex.printStackTrace();
> }
> }
>
> The ProgessBarUpdater class has this method:
>
>
>
//--
> /**
> * Displays the progress bar & begins the polling. We don't start
the
> polling until
> * explicitly told to do, for efficiency purposes.
> * @param ajax The Ajax request wrapper.
> * @param reporter The object to query for progress data.
> */
> public void start(final AjaxRequestTarget ajax, final ProgressReporter
> reporter) {
>
> add(new AjaxSelf
Re: Application scope vs Singleton
On Sat, May 16, 2009 at 2:39 PM, nino martinez wael wrote: > you can mock statict classes with power mock , but i'vé come to the > konklusion that it is a code smell going that way ioc are much better. Right, I didn't say it was impossible. I said it would be more difficult. Dependency injection is definitely the best way to go, but the "lookupable" services on the application object would work also (how those service implementations get initialized is a different story, though). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Application scope vs Singleton
you can mock statict classes with power mock , but i'vé come to the konklusion that it is a code smell going that way ioc are much better. -from my htc 2009/5/15, James Carman : > On Fri, May 15, 2009 at 12:18 PM, alf.redo > wrote: >> >> Thank you to all for your precious suggestions. >> >> My question is not for a real need. >> Supposing to discard the injection "strategy", I would like to know if the >> cache of an object into my WebApplication class during application startup >> has the same result if I make this object Singleton (and not store it in >> WebApplication). Can be some problems about "thread-safety" or other issue >> in one case rather than the other? > > Making the object a "singleton" would make unit testing more difficult, > IMHO. > > Thread-safety is all up to how you implement the class, really. You'd > have to be aware of threading issues either way. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Sendt fra min mobile enhed - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Application scope vs Singleton
On Fri, May 15, 2009 at 12:18 PM, alf.redo wrote: > > Thank you to all for your precious suggestions. > > My question is not for a real need. > Supposing to discard the injection "strategy", I would like to know if the > cache of an object into my WebApplication class during application startup > has the same result if I make this object Singleton (and not store it in > WebApplication). Can be some problems about "thread-safety" or other issue > in one case rather than the other? Making the object a "singleton" would make unit testing more difficult, IMHO. Thread-safety is all up to how you implement the class, really. You'd have to be aware of threading issues either way. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Application scope vs Singleton
Thank you to all for your precious suggestions. My question is not for a real need. Supposing to discard the injection "strategy", I would like to know if the cache of an object into my WebApplication class during application startup has the same result if I make this object Singleton (and not store it in WebApplication). Can be some problems about "thread-safety" or other issue in one case rather than the other? I'm sorry if this seems to be a stupid question... alf -- View this message in context: http://www.nabble.com/Application-scope-vs-Singleton-tp23559402p23563036.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: Application scope vs Singleton
On Fri, May 15, 2009 at 11:26 AM, Jeremy Thomerson wrote: > Use injection. The difference is that there is no way to override the > implementation of the static accessor / singleton for testing > functionality. If you instead use an IoC container (Spring / Guice) > and injection, you are not statically tying yourself to a single > class. Work off the interface, and all the places in your code that > use that interface can be changed to use a different implementation > without changing each of them - just change the config as to which one > is injected. You could always use a mock application object in your tests that has mock objects for the singletons defined there. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Application scope vs Singleton
Use injection. The difference is that there is no way to override the implementation of the static accessor / singleton for testing functionality. If you instead use an IoC container (Spring / Guice) and injection, you are not statically tying yourself to a single class. Work off the interface, and all the places in your code that use that interface can be changed to use a different implementation without changing each of them - just change the config as to which one is injected. -- Jeremy Thomerson http://www.wickettraining.com On Fri, May 15, 2009 at 10:21 AM, alf.redo wrote: > > Hi James, > I would like to know what is the difference between a Singleton class with a > static accessor method and POJO stored into my WebApplication class (with > proper getter). > What is the preferred way to set an application scoped object? > > Thank you again... > > > -- > View this message in context: > http://www.nabble.com/Application-scope-vs-Singleton-tp23559402p23562038.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: Application scope vs Singleton
Hi James, I would like to know what is the difference between a Singleton class with a static accessor method and POJO stored into my WebApplication class (with proper getter). What is the preferred way to set an application scoped object? Thank you again... -- View this message in context: http://www.nabble.com/Application-scope-vs-Singleton-tp23559402p23562038.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: Application scope vs Singleton
Alfredo Aleandri wrote: > I have a doubt about application-scoped objects. > What's the pro and cons of setting an object instance into my > WebApplication class or define that class as singleton (using a static > method to access it) ? Pro: Singletons are easy to use Contra: They make Unit tests and re-usability difficult. I personally use dependency-injection with wicket-guice. Jan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Application scope vs Singleton
On Fri, May 15, 2009 at 9:01 AM, Alfredo Aleandri wrote: > Hi, > I have a doubt about application-scoped objects. What is your doubt? > What's the pro and cons of setting an object instance into my WebApplication > class or define that class as singleton (using a static method to access it) > ? If you always access it through the "getter" method on the application, I don't think there's any real problem with that. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Application scope vs Singleton
Hi, I have a doubt about application-scoped objects. What's the pro and cons of setting an object instance into my WebApplication class or define that class as singleton (using a static method to access it) ? Thank you alf - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: application scope objects in Wicket
Thank you both for your answers, Jeremy and James.
The data structure I'll use in the real case will be a collection of
objects with
one object for each of the user sessions.
That same object will be accessed only once outside the user session
and then it will be erased. There won't be 2 threads accessing the same
object in the collection
at the same time but they will access the collection object itself
concurrently (even if on separate elements).
That's why I thought about using synchronized methods only for removing,
setting and adding an element in the Collection,
I hope this will work correctly without affecting the performance of the
WebApplication object.
Don't know if I should incapsulate the collection in another object
member of WebApplication and implement the synchronized methods
inside it.
I didn't post these details because my doubt was really on the
correctness of overriding the get() method of WebApplication
to enable the use of application scope objects.
Thanks for the advice and cheers,
Marvan
James Perry wrote:
Firstly I hope you are enjoying building your first Wicket web app.
Is this application scope object immutable? What is the data structure?
IMHO, if it's immutable then it's OK to use composition within your
WebApplication by adding this object as a field within WebApplication.
I would just make it final so it never gets incorrectly pointed to a
different object once initialized.
However if this has mutable shared data, then do not use the
WebApplication's intrinsic lock as you will jeopardize its throughput
to process requests. For example:
public class FooBarApplication extends WebApplication {
private MyAppScopeObject appScopeObject;
public synchronized MyAppScopeObject getAppScopeObject(){
return appScopeObject;
}
public synchronized void setAppScopeObject(MyAppScopeObject appScopeObject) {
this.appScopeObject = appScopeObject;
}
}
Instead, use your application-scope object's intrinsic lock or use a
suitable mutex in the Java 5/6 API.
Best,
James.
On Mon, Aug 25, 2008 at 12:04 PM, Marvan Spagnolo <[EMAIL PROTECTED]> wrote:
Hi all, I'm new to Wicket and developing my first Wicket website.
I have some temporary objects created inside a users' session but needed by
a parallel process which uses them
outside the user session and I would like to avoid temporarily persisting
them into a database.
I'm looking at using application scope objects but I'm not sure how to do it
best
in Wicket.
I guess I should override the get() method of WebApplication
mimicking the pattern used for custom Session objects.
public class WicketApplication extends MyWebApplication
{
private Object applicationScopeObject;
public WicketApplication() {
setApplicationScopeObject( );
}
@Override
public static WicketApplication get() {
return (WicketApplication) WebApplication.get();
}
public Object getApplicationScopeObject(){
return this.applicationScopeObject;
}
public void setApplicationScopeObject( Object applicationScopeObject ){
this.applicationScopeObject = applicationScopeObject;
}
[...]
}
public class PageInsideUserSession
{
public PageInsideUserSession(){
[...]
// object has already been initialized
WicketApplication.get().setApplicationScopeObject( object );
}
}
public class PageOutsideUserSession
{
public PageOutsideUserSession(){
Object object = WicketApplication.get().getApplicationScopeObject();
[...]
}
}
In my case synchronizing the access to the application scope object should
not be needed.
Is this approach correct (and efficient) or is there a better solution ?
Should I maybe use a separate parent class (parent of WicketApplication and
child of WebApplication) for
overriding the get() method (in case the override interferes with something
else in the framework) ?
Cheers,
Marvan
--
Reza Marvan Spagnolo
SW Engineer - Freelancer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: application scope objects in Wicket
Firstly I hope you are enjoying building your first Wicket web app.
Is this application scope object immutable? What is the data structure?
IMHO, if it's immutable then it's OK to use composition within your
WebApplication by adding this object as a field within WebApplication.
I would just make it final so it never gets incorrectly pointed to a
different object once initialized.
However if this has mutable shared data, then do not use the
WebApplication's intrinsic lock as you will jeopardize its throughput
to process requests. For example:
public class FooBarApplication extends WebApplication {
private MyAppScopeObject appScopeObject;
public synchronized MyAppScopeObject getAppScopeObject(){
return appScopeObject;
}
public synchronized void setAppScopeObject(MyAppScopeObject appScopeObject) {
this.appScopeObject = appScopeObject;
}
}
Instead, use your application-scope object's intrinsic lock or use a
suitable mutex in the Java 5/6 API.
Best,
James.
On Mon, Aug 25, 2008 at 12:04 PM, Marvan Spagnolo <[EMAIL PROTECTED]> wrote:
> Hi all, I'm new to Wicket and developing my first Wicket website.
> I have some temporary objects created inside a users' session but needed by
> a parallel process which uses them
> outside the user session and I would like to avoid temporarily persisting
> them into a database.
>
> I'm looking at using application scope objects but I'm not sure how to do it
> best
> in Wicket.
>
> I guess I should override the get() method of WebApplication
> mimicking the pattern used for custom Session objects.
>
> public class WicketApplication extends MyWebApplication
> {
> private Object applicationScopeObject;
>
> public WicketApplication() {
> setApplicationScopeObject( );
> }
> @Override
> public static WicketApplication get() {
> return (WicketApplication) WebApplication.get();
> }
> public Object getApplicationScopeObject(){
> return this.applicationScopeObject;
> }
> public void setApplicationScopeObject( Object applicationScopeObject ){
> this.applicationScopeObject = applicationScopeObject;
> }
> [...]
> }
>
> public class PageInsideUserSession
> {
> public PageInsideUserSession(){
> [...]
> // object has already been initialized
> WicketApplication.get().setApplicationScopeObject( object );
> }
> }
>
> public class PageOutsideUserSession
> {
> public PageOutsideUserSession(){
> Object object = WicketApplication.get().getApplicationScopeObject();
> [...]
> }
> }
>
> In my case synchronizing the access to the application scope object should
> not be needed.
>
> Is this approach correct (and efficient) or is there a better solution ?
> Should I maybe use a separate parent class (parent of WicketApplication and
> child of WebApplication) for
> overriding the get() method (in case the override interferes with something
> else in the framework) ?
>
> Cheers,
>
> Marvan
>
> --
> Reza Marvan Spagnolo
> SW Engineer - Freelancer
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: application scope objects in Wicket
If I understood your use correctly, this approach won't work if there are
two users using the application concurrently - you would overwrite one's
application-scoped object with another Right? There is only one
application per application - not per session.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Aug 25, 2008 at 6:04 AM, Marvan Spagnolo <[EMAIL PROTECTED]> wrote:
> Hi all, I'm new to Wicket and developing my first Wicket website.
> I have some temporary objects created inside a users' session but needed by
> a parallel process which uses them
> outside the user session and I would like to avoid temporarily persisting
> them into a database.
>
> I'm looking at using application scope objects but I'm not sure how to do
> it
> best
> in Wicket.
>
> I guess I should override the get() method of WebApplication
> mimicking the pattern used for custom Session objects.
>
> public class WicketApplication extends MyWebApplication
> {
> private Object applicationScopeObject;
>
> public WicketApplication() {
> setApplicationScopeObject( );
> }
> @Override
> public static WicketApplication get() {
> return (WicketApplication) WebApplication.get();
> }
> public Object getApplicationScopeObject(){
> return this.applicationScopeObject;
> }
> public void setApplicationScopeObject( Object applicationScopeObject ){
> this.applicationScopeObject = applicationScopeObject;
> }
> [...]
> }
>
> public class PageInsideUserSession
> {
> public PageInsideUserSession(){
> [...]
> // object has already been initialized
> WicketApplication.get().setApplicationScopeObject( object );
> }
> }
>
> public class PageOutsideUserSession
> {
> public PageOutsideUserSession(){
> Object object = WicketApplication.get().getApplicationScopeObject();
> [...]
> }
> }
>
> In my case synchronizing the access to the application scope object should
> not be needed.
>
> Is this approach correct (and efficient) or is there a better solution ?
> Should I maybe use a separate parent class (parent of WicketApplication and
> child of WebApplication) for
> overriding the get() method (in case the override interferes with something
> else in the framework) ?
>
> Cheers,
>
> Marvan
>
> --
> Reza Marvan Spagnolo
> SW Engineer - Freelancer
>
application scope objects in Wicket
Hi all, I'm new to Wicket and developing my first Wicket website.
I have some temporary objects created inside a users' session but needed by
a parallel process which uses them
outside the user session and I would like to avoid temporarily persisting
them into a database.
I'm looking at using application scope objects but I'm not sure how to do it
best
in Wicket.
I guess I should override the get() method of WebApplication
mimicking the pattern used for custom Session objects.
public class WicketApplication extends MyWebApplication
{
private Object applicationScopeObject;
public WicketApplication() {
setApplicationScopeObject( );
}
@Override
public static WicketApplication get() {
return (WicketApplication) WebApplication.get();
}
public Object getApplicationScopeObject(){
return this.applicationScopeObject;
}
public void setApplicationScopeObject( Object applicationScopeObject ){
this.applicationScopeObject = applicationScopeObject;
}
[...]
}
public class PageInsideUserSession
{
public PageInsideUserSession(){
[...]
// object has already been initialized
WicketApplication.get().setApplicationScopeObject( object );
}
}
public class PageOutsideUserSession
{
public PageOutsideUserSession(){
Object object = WicketApplication.get().getApplicationScopeObject();
[...]
}
}
In my case synchronizing the access to the application scope object should
not be needed.
Is this approach correct (and efficient) or is there a better solution ?
Should I maybe use a separate parent class (parent of WicketApplication and
child of WebApplication) for
overriding the get() method (in case the override interferes with something
else in the framework) ?
Cheers,
Marvan
--
Reza Marvan Spagnolo
SW Engineer - Freelancer
Re: Application scope pages
this is already how 1.3 works. only the current page is stored in session, older pages are swapped off to disk. -igor On 10/19/07, John Patterson <[EMAIL PROTECTED]> wrote: > HI, > > Is there anyway to have stateless pages that live in the application > scope so I can use AJAX behaviours and other listeners? Failing > that, can I turn off storing all pages except for the current active > page? > > Cheers, > > John. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Application scope pages
HI, Is there anyway to have stateless pages that live in the application scope so I can use AJAX behaviours and other listeners? Failing that, can I turn off storing all pages except for the current active page? Cheers, John. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
