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