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 > -----Message d'origine----- > De : Ryan Daum [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 25 janvier 2007 17:43 > À : [email protected] > Objet : Re: Newbie question on the Resource changes in RC3 > > On second thought, after looking at what is required to use > @Configurable, I have totally balked. To get it to work: > > * Need Spring AOP, Aspects > * Need AspectJ > * Need to configure build system to do AspectJ "Weaving" > * Need to add flags to start scripts to add AspectJ weaving. > > Does anybody have a simpler and less brittle (from a > component POV) of configuring either Resources or attributes > of the Application? > > R > > > On 1/24/07, Ryan Daum <[EMAIL PROTECTED]> wrote: > > Brilliant! Thanks for the tip, I was wondering how I > was going to do this. > > R > > > > On 1/24/07, Valdis Rigdon < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > wrote: > > > Hello... > > I just recently found this project and after > evaluating decided to use > > it for a project that I am starting. Great > project, I am very impressed > > so far. I am planning to run Restlet inside > Jetty and Spring. > > Based on the Spring example for configuring > all the restlets and URIs in > > the config, I am subclassing the > ServerServlet so I can override the > > createApplication method so Spring can manage > all the classes for me. > > > > This works great except with defining > Resources to handle the get, > > delete, put, post methods. Since the handler > is now auto created and > > the Resource constructor requires a context, > request, and response to be > > created it makes it difficult to use Spring > to manage the Resource > > objects. If the idea is now that the > Resource class is subclassed to > > provide the implementation, it generally is > going to need other objects, > > like a DAO, to do the work. DAOs in > particular are much simplified when > > using Spring and being able to inject them > into the Resource is required > > if Spring is being used in my case. > > > > I can think of a possible work around by > subclassing the object that > > creates Resources and making that object a > Spring bean so I can properly > > inject other dependencies. It would be > easiest if the the default > > constructor was still available and not > deprecated, so that Spring could > > manage the Resources. Or possibly I should > use explicit Handlers > > instead? > > > > I have not dug into Restlet enough yet to > know which is the best way to > > proceed. > > Any ideas or comments would be appreciated. > > > > Thank you! > > -Brandon > > Brandon, > > The Spring managed approach for Resource > instances is exactly how we've > implemented Restlets for our project. > > If you are using Spring 2.0, then use the AOP > support. In short, you > annotate your classes extending Resource with > @Configurable and Spring > will inject the dependencies seamlessly after > the constructor is finished, > even though the Restlet framework is calling > "new MyResource()". > > See > http://static.springframework.org/spring/docs/2.0.x/reference/ > aop.html > <http://static.springframework.org/spring/docs/2.0.x/reference > /aop.html> > for more details, specifically section 6.8. > > > Valdis > > > > > >
