Warren,

ThreadContext.detach(); seems to be more proper than...
ThreadContext.setApplication(null); I will update demo.

On Sat, Nov 22, 2014 at 10:58 PM, Warren Bell <warrenbe...@gmail.com> wrote:

> Ernesto,
>
> That’s kind of what I ended up doing except with a different
> ThreadPoolExecutor implementation.
>
> ExecutorService executorService = new ScheduledThreadPoolExecutor(20)
>         {
>             @Override
>             protected void beforeExecute(Thread t, Runnable r) {
>                 ThreadContext.setApplication(MyApplication.this);
>             }
>
>             @Override
>             protected void afterExecute(Runnable r, Throwable t) {
>                 ThreadContext.detach();
>             }
>         };
>
> No particular reason why I picked ScheduledThreadPoolExecutor other than
> it looked a little easier to use. I need to look more into the different
> types of Thread pools and such.
>
> I used:
>
> ThreadContext.detach();
>
> instead of:
>
> ThreadContext.setApplication(null);
>
> Warren Bell
>
>
> On Nov 22, 2014, at 11:18 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > pushed a new version including injecting a Guice managed service class
> >
> > On Sat, Nov 22, 2014 at 8:08 PM, Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> >> Warren,
> >>
> >> Something like:
> >>
> >> ExecutorService executorService =  new ThreadPoolExecutor(10, 10,
> >>            0L, TimeUnit.MILLISECONDS,
> >>            new LinkedBlockingQueue<Runnable>()) {
> >>   @Override
> >>           protected void beforeExecute(final Thread t, final Runnable
> r) {
> >>   ThreadContext.setApplication(BgProcessApplication.this);
> >>           };
> >>           @Override
> >>           protected void afterExecute(final Runnable r, final Throwable
> >> t) {
> >>           ThreadContext.setApplication(null);
> >>           }
> >> };
> >>
> >> seems to work.
> >>
> >> On Thu, Nov 20, 2014 at 8:33 PM, Warren Bell <
> warr...@clarksnutrition.com>
> >> wrote:
> >>
> >>> I have seen this from a 2010 post:
> >>>
> >>> final Application app = Application.get();
> >>>          final ExecutorService service = new
> >>> ScheduledThreadPoolExecutor(1) {
> >>>            @Override
> >>>            protected void beforeExecute(final Thread t, final Runnable
> >>> r) {
> >>>              Application.set(app);
> >>>            };
> >>>            @Override
> >>>            protected void afterExecute(final Runnable r, final
> Throwable
> >>> t) {
> >>>              Application.unset();
> >>>            }
> >>>          };
> >>>
> >>> But there is no more Application#set(app) and Application#unset() in
> >>> Wicket 6. Does Wicket 6 have some built in way of creating secondary
> >>> processes, maybe an internal thread pool that can be set-up ?
> >>>
> >>> Warren Bell
> >>>
> >>> On Nov 20, 2014, at 10:03 AM, Warren Bell <warr...@clarksnutrition.com
> >>> <mailto:warr...@clarksnutrition.com>> wrote:
> >>>
> >>> Ernesto, great job putting all that code together so quickly. I cloned
> >>> your project and cherry picked out the code that I needed, I don’t
> need all
> >>> the process progress code you have. I don’t really care what the
> process
> >>> progress is or even if it completes ok, just don’t want it holding up
> my
> >>> response.
> >>>
> >>> I ended up using your ExecutionBridge, TasksRunnable, and ITask classes
> >>> and interfaces. But I still don’t know where and how to inject my
> service
> >>> into this new task/thread or ExecutionBridge without getting this
> exception:
> >>>
> >>> Exception in thread "pool-1-thread-1"
> >>> org.apache.wicket.WicketRuntimeException: There is no application
> attached
> >>> to current thread pool-1-thread-1
> >>>
> >>> Do I need to get the application attached to my new threads somehow so
> I
> >>> can use my injected service, and if so, how do I do that ?
> >>>
> >>> Warren
> >>>
> >>> On Nov 20, 2014, at 5:47 AM, Ernesto Reinaldo Barreiro <
> >>> reier...@gmail.com<mailto:reier...@gmail.com><mailto:
> reier...@gmail.com>>
> >>> wrote:
> >>>
> >>> Martin,
> >>>
> >>> I have created
> >>>
> >>> https://github.com/reiern70/antilia-bits/tree/master/bgprocess
> >>>
> >>> My only caveats are
> >>>
> >>>
> >>>
> https://github.com/reiern70/antilia-bits/blob/master/bgprocess/src/main/java/com/antilia/panel/TasksListPanel.java#L50
> >>>
> >>> and
> >>>
> >>>
> >>>
> https://github.com/reiern70/antilia-bits/blob/master/bgprocess/src/main/java/com/antilia/panel/TasksListPanel.java#L70
> >>>
> >>> I had to re-add Timer behavior: I do not see yet why? It is as if the
> >>> timer
> >>> is not re-rendered: they are not isTemporar :-( I will check when I
> have
> >>> more time.
> >>>
> >>> I would appreciate if you can review the code... before I write
> anything
> >>> on
> >>> my fork  of Wicket in Action. This probably could be done in a leaner
> way
> >>> mounting a resource to serve JSON for task states and building the UI
> at
> >>> client side... But example illustrates how to do it with "plain
> Wicket".
> >>>
> >>>
> >>> On Thu, Nov 20, 2014 at 8:40 AM, Ernesto Reinaldo Barreiro <
> >>> reier...@gmail.com<mailto:reier...@gmail.com><mailto:
> reier...@gmail.com>>
> >>> wrote:
> >>>
> >>> Ok. Let me see what I can do this weekend while I wait for my son to
> >>> finish he's shower after he's football match  ;-)
> >>>
> >>> On Thu, Nov 20, 2014 at 8:30 AM, Martin Grigorov <mgrigo...@apache.org
> >>> <mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>>
> >>> wrote:
> >>>
> >>> Sure! Thanks!
> >>> It could be as fancy as you wish.
> >>>
> >>> Martin Grigorov
> >>> Wicket Training and Consulting
> >>> https://twitter.com/mtgrigorov
> >>>
> >>> On Thu, Nov 20, 2014 at 10:17 AM, Ernesto Reinaldo Barreiro <
> >>> reier...@gmail.com> wrote:
> >>>
> >>> Can I give it a try? Something event showing some progress at client
> >>> side?
> >>>
> >>> On Thu, Nov 20, 2014 at 7:54 AM, Martin Grigorov <mgrigo...@apache.org
> >
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Someday I'll write a blog (with a demo) about this at
> >>> http://wicketinaction.com.
> >>> The question is being asked regularly.
> >>>
> >>> Actually anyone can send a Pull Request at
> >>> https://github.com/dashorst/wicketinaction.com with such article.
> >>>
> >>> Martin Grigorov
> >>> Wicket Training and Consulting
> >>> https://twitter.com/mtgrigorov
> >>>
> >>> On Thu, Nov 20, 2014 at 7:26 AM, Ernesto Reinaldo Barreiro <
> >>> reier...@gmail.com> wrote:
> >>>
> >>> Hi Warren,
> >>>
> >>>
> >>> On Thu, Nov 20, 2014 at 12:46 AM, Warren Bell <
> >>> warrenbe...@gmail.com>
> >>> wrote:
> >>>
> >>> I am using Wicket 6 REST annotations and want to asynchronously
> >>> start a
> >>> process that writes some logging data to a db. I don’t need the
> >>> response
> >>> to
> >>> wait for this process. I have tried using threads, but I get the
> >>> “App
> >>> not
> >>> attached to this thread” exception when I try to use an injected
> >>> service.
> >>> This logging process is a little more complicated than what log4j
> >>> or
> >>> loopback can do. The bottom line is that I do not want the
> >>> request/response
> >>> process to have to wait for the logging process to complete. What
> >>> is
> >>> the
> >>> proper way of doing this in Wicket 6 using an injected service.
> >>>
> >>> Sometimes  what I do is I create a context class ServiceHolder,
> >>> inject
> >>> what I need on this class (e.g. services) and pass this to the non
> >>> web
> >>> thread (e.g as an argument to the runnable). Injector.inject will
> >>> have
> >>> WicketApp in context.
> >>>
> >>>
> >>> 1) Get request
> >>> 2) Log some data (Do not wait for this to complete)
> >>> 3) Process request
> >>> 4) Return response
> >>>
> >>>
> >>> You could use the same ServiceHolder as a bridge to pass info to the
> >>> WEB
> >>> layer. 1) keep a reference to it 2) in another (polling) request
> >>> use it
> >>> to
> >>> see how back-ground job is progressing. Sometimes I also use it to
> >>> control
> >>> the Job: e.g. stop/pause it, cancel it. Once Job finishes just let
> >>> service
> >>> holder "go".
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Warren Bell
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards - Ernesto Reinaldo Barreiro
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards - Ernesto Reinaldo Barreiro
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards - Ernesto Reinaldo Barreiro
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards - Ernesto Reinaldo Barreiro
> >>>
> >>> --
> >>> This email was Virus checked by Clark's Nutrition's Astaro Security
> >>> Gateway.
> >>>
> >>>
> >>
> >>
> >> --
> >> Regards - Ernesto Reinaldo Barreiro
> >>
> >
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Regards - Ernesto Reinaldo Barreiro

Reply via email to