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
