You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Paul Cooley <pe...@gmail.com> on 2007/09/17 14:25:41 UTC

T5: Stateful lifecycle for services

All:
I am replacing an existing avalon framework implementation for my company.
The current framework has the ability to keep stateful services given a
token.  Much of the code in our systems depends on this functionality and
the framework runs as both a standalone application as well as within rmi
servers and http web containers.  In looking through the source code, I
noticed that services are loaded with a specific lifecycle (threaded or
singleton).  Is it possible to create a stateful lifecycle and then plug
this in?  I know it flies in the face of the traditional SOA components
(sorry for the buzzword), but this is a feature we have to have in order to
avoid rearchitecting/implementing our entire technology stack.  Since we
don't always have a thread id (although I could use the token to set the
ThreadLocal id), I need a mechanism to store associate the pojo services
with the token provided via login.

Cheers.

-- 
Gotta find my destiny, before it gets too late.-- Ian Curtis

Re: T5: Stateful lifecycle for services

Posted by Paul Cooley <pe...@gmail.com>.
Sorry for the dupe.  Hit the wrong button in gmail.  :">

T5: Stateful lifecycle for services

Posted by Paul Cooley <pe...@gmail.com>.
I am replacing an existing avalon framework implementation for my
company.  The current framework has the ability to keep stateful services
given a token.  Much of the code in our systems depends on this
functionality and the framework runs as both a standalone application as
well as within rmi servers and http web containers.  In looking through the
source code, I noticed that services are loaded with a specific lifecycle
(threaded or singleton).  Is it possible to create a stateful lifecycle and
then plug this in?  I know it flies in the face of the traditional SOA
components (sorry for the buzzword), but this is a feature we have to have
in order to avoid rearchitecting/implementing our entire technology
stack.  Since we don't always have a thread id (although I could use the
token to set the ThreadLocal id), I need a mechanism to store associate the
pojo services with the token provided via login.
-- 
Gotta find my destiny, before it gets too late.-- Ian Curtis