Hi all, thanks for the discussion! In my particular case: I use guice for DI. Guice supports scoping of objects. This includes session scope. Storing values in the session using keys means that those keys need to be managed. Using guice session scope I don't need to care about this stuff anymore. If I want a to move a Object out of the session into a singleton scope I don't have to refactor all the code. I just change the scope in the configuration. Interceptors often access session values. Stripes-Guice also supports interceptor instantiation using guice. But the only thing I can inject is the injector it self to use it later to retrieve the required stateful information inside the intercept method. If a new interceptor would be instantiated each request I could inject the required stateful values directly using the constructor. This would make programming and testing interceptors more easy, cause I can ask for the things I need, not for things I need to get the things I need. Less code, less chance of errors and less mocking effort for testing.
If I do need a state in my interceptor I will have to create the stateful objects anyway - regardless if a new interceptor is instantiated or a new stateful object inside the intercept method. IMHO garbage collecting of objects created inside a method is still something that needs to be done so the gc has to work harder in any way. Compared to the number of objects created when a request comes in, a chain of 10 interceptors wouldn't really matter. Anyway this problem can be solved using a single annotation indicating if the interceptor should be singleton or not. The web flow I'm used to is that you don't care about thread safety(as long as no information needs to flow between two concurrent requests) since every request and its children are existing in their own thread and environment which is realized by creating different instances of the same classes for every request. ActionBeans are the best example for this. IMHO Stripes interceptors are also part of the control layer - the same one ActionBeans belong to. This smells like they should share the scope they are existing in. I know one should not get into the business of trying to stop people doing silly things but the singleton scope of interceptors invites unexperienced programmers (like me) to use synchronized methods. The execution time of the gc scales with the number of cpu's. Thread synchronization does not. IMHO this is not really getting into the business here since many web frameworks are following the pattern to isolate a request by creating new objects - including stripes. Cheers. Richard On Wed, Jun 24, 2009 at 10:27 AM, VANKEISBELCK Remi<[email protected]> wrote: > Hi Richard, > > Thread safety isn't an issue here, as the interceptor isn't supposed > to be stateful... why would it need to ? > > Otoh, imagine you create an interceptor for each intercepted stage, > this makes quite a lot of useless instance creations, makes your GC > work harder etc. > > Cheers > > Remi > > 2009/6/24 Richard Hauswald <[email protected]>: >> IMHO instantiating new objects is default behavior unless mentioned >> other in the documentation. The fact that there is only one instance >> means that interceptors must be implemented thread safe. To answer >> your question: If a interceptor would be instantiated more than once >> they could be injected using a DI framework and they'd thread safe by >> default. >> >> On Wed, Jun 24, 2009 at 8:43 AM, Cosmin Marginean<[email protected]> wrote: >>> Is there a reason why it should be instantiated more than once? :) >>>> Hello list, >>>> is there a reason why a stripes interceptor is only instantiated once? >>>> Thanks, >>>> Richard >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Stripes-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/stripes-users >>> >> >> >> >> -- >> Richard Hauswald >> Blog: http://tnfstacc.blogspot.com/ >> LinkedIn: http://www.linkedin.com/in/richardhauswald >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Stripes-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/stripes-users >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Stripes-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stripes-users > -- Richard Hauswald Blog: http://tnfstacc.blogspot.com/ LinkedIn: http://www.linkedin.com/in/richardhauswald ------------------------------------------------------------------------------ _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
