I'll guess the question is how to use services at all...
As IOC services are usually singletons changing state via setters will affect 
all threads which deal with this service thus data may creep from one session 
to another and will introduce concurrency problems immediately. In case a 
service is thread or request based I'll consider it to be more like a cache 
class which is accessible as long the thread is running / the request is 
processed and mentains state in this period of time. To me usage of a per 
thread scope class is more elegant as using threadlocal attributes because its 
simply more obvious in which context it is used. If this is not an answer to 
the initial question just ignore me

Jens


Von meinem iPad gesendet

Am 14.09.2012 um 22:42 schrieb "Thiago H de Paula Figueiredo" 
<thiag...@gmail.com>:

> On Fri, 14 Sep 2012 16:59:44 -0300, George Christman 
> <gchrist...@cardaddy.com> wrote:
> 
>> My bad, I meant modifier. I was setting the modifier with a set method then 
>> accessing the data within the modifer from other methods.
> 
> I still don't know what you're talking about. Are you saying modifier as 
> meaning the same as setter? As you may have noticed, I don't like helping 
> unless I know what's being talked about. :)
> 
> -- 
> Thiago H. de Paula Figueiredo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to