Re: Background Threading
It does not requiere hibernate... I will build an example... better than empty talk. On Tue, May 6, 2014 at 3:59 PM, Richard W. Adams wrote: > Well for starters, the example seems to require Hibernate (which our > organization doesn't allow us to use). This correct? > > Second, I don't have the flexibility implement a service. I have to send > Javascript back to the client, and the corporate Javascript framework then > renders the progress bar. > > What is the 'context' class you refer to? Where is it instantiated and > where is it stored? > > > > > From: Ernesto Reinaldo Barreiro > To: "users@wicket.apache.org" > Date: 05/06/2014 07:52 AM > Subject:Re: Background Threading > > > > Hi, > > > 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) > > > > Really? Is it that hard? > > 1-Create a "context" class to pass information to/from WEB > threads/background thread. > 2-Both threads keep a copy of it: so you can report progress, cancel > generation and so on. > > I have implemented something like that ages ago > > https://code.google.com/p/antilia/wiki/OSGiPowered > > > > > > > > > > > > > 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 > > }
Re: Background Threading
Well for starters, the example seems to require Hibernate (which our organization doesn't allow us to use). This correct? Second, I don't have the flexibility implement a service. I have to send Javascript back to the client, and the corporate Javascript framework then renders the progress bar. What is the 'context' class you refer to? Where is it instantiated and where is it stored? From: Ernesto Reinaldo Barreiro To: "users@wicket.apache.org" Date: 05/06/2014 07:52 AM Subject: Re: Background Threading Hi, 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) > Really? Is it that hard? 1-Create a "context" class to pass information to/from WEB threads/background thread. 2-Both threads keep a copy of it: so you can report progress, cancel generation and so on. I have implemented something like that ages ago https://code.google.com/p/antilia/wiki/OSGiPowered > > > > > 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 >
Re: Background Threading
Hi, 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) > Really? Is it that hard? 1-Create a "context" class to pass information to/from WEB threads/background thread. 2-Both threads keep a copy of it: so you can report progress, cancel generation and so on. I have implemented something like that ages ago https://code.google.com/p/antilia/wiki/OSGiPowered > > > > > 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 AjaxSelfUpdatingTimerBehavior(Duration.seconds(2)) { > private static final long serialVersionUID = 1L; > > @Override protected void onPostProcessTarget(final > AjaxRequestTarget ajax) { > > final Progress progress = reporte
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 AjaxSelfUpdatingTimerBehavior(Duration.seconds(2)) { > private static final long serialVersionUID = 1L; > > @Override protected void onPostProcessTarget(final > AjaxRequestTarget ajax) { > > final Progress progress = reporter.getProgress(); > final String script = // Build > script to update >
Background Threading
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 AjaxSelfUpdatingTimerBehavior(Duration.seconds(2)) { private static final long serialVersionUID = 1L; @Override protected void onPostProcessTarget(final AjaxRequestTarget ajax) { final Progress progress = reporter.getProgress(); final String script = // Build script to update ProgressScript.build(progress); // progress bar ajax.appendJavascript(script); if (progress == null) { // If operation is finished final ProgressBarUpdater updater = ProgressBarUpdater.this; updater.remove(this); // Stop timer to prevent