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]