Jerome Louvel <contact <at> noelios.com> writes: > > > Hi all, > > Thanks for exploring this recurring issue. I realize that the current > approach isn't flexible enough in many case. So, I have restored the default > constructor and added a new 'init(Context, Request, Response) method that > gets invoke by the other constructor. > > Also, the Finder class will now look for a default constructor if the normal > one isn't available and will call 'init' after the instantiation in this > case. This should make everyone happy. > > I will post a first RC4 snapshot soon. > > Best regards, > Jerome >
Wow, thank you Jerome for your willingness to be flexible here. After thinking about is some more it seems that subclassing Finder and making that a spring bean is an easier way to go for what I want to accomplish. The findTarget method can then create the appropriate Resource or use a Spring factory method to do so. So far I am just creating the FindingSince the Resource class still stores the request/response/context as members it would run into issues w/ state control unless SpringAOP and @Configurable are used like Valdis suggested. I think your change does though provide some more flexibility for creating the objects, thank you. I apologize if I raised any confusion. -Brandon
