|
From: Erwin V. <erw...@er...> - 2005-03-29 20:42:48
|
>> Mmm. So you're thinking about a custom mapper that (in the >> 'createSubFlowInputAttributes' method) takes a list of persons (ids) from >> the parent flow scope and instantiates an algorithm object, passing in >> those >> ids. Once that is done it puts the algorithm object in the subflow scope. >> As >> far as I can see the mapper would still be thread safe right -- >> everything >> happens in a method call with local variables? > > This is indeed what I was thinking about. The mapper is the pivot > point between two sub flows. Since the Person flow requires the > algorithm class the mapper to me looks like the obvious point to > create it. Yes. > > Since the mapper is a singleton and I would like to use IoC to > configure which algorithm class the mapper should use the mapper needs > to create the algorithm instance on every call to > 'createSubFlowInputAttributes'. This would require the use of the > 'getBean' method of the application context and a string property on > the mapper class to set the bean name of the algorithm class. The > algorithm class would be stateful thus needs to be configured as a > prototype and its instances cannot outlive the scope of a request. That would work. Or you could just configure the algorithm class and instantiate it yourself in the mapper. I think I would do it like that. Seems simpler. >> >> All mappers (and actions) should be stateless and there should be little >> need to make them statefull. > > Agreed. > |