Leigh, I agree with your analysis. WadlApplication now calls findTarget() instead of createTarget(). Also, I've changed the modifier of those methods as suggested: findTarget() is now public and all createTarget() methods are now protected. Note that those changes are only in SVN trunk as they imply some API changes. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com> http://www.noelios.com _____
De : [email protected] [mailto:[email protected]] De la part de Tim Peierls Envoye : mardi 3 fevrier 2009 19:52 A : Klotz, Leigh Cc : [email protected] Objet : Re: WadlApplication and Guice in Restlet 1.1.1 problem with Finder.createTarget(Class<? extends Handler>...) Sounds good to me. I'll post a link to this discussion at the end of my old blog posting. --tim On Tue, Feb 3, 2009 at 1:43 PM, Klotz, Leigh <[email protected]> wrote: I am using Restlet Resource Dependency Injection in Guice/Restlet as described in <http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html> http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html Much like the Spring integration org.restlet.ext.spring.SpringFinder, this package provides its own Finder, via a FinderFactory. WadlApplication does not work when using the Finder from the Guice integration. Below I explain the issue, make a suggestion to change Finder and WadlApplication to eliminate the issue, and propose a workaround to Tim Peierls's suggested code. Explanation Specifically, the following line in WadlApplication fails for classes found with the Guice Finder: class WadlApplication { ... private ResourceInfo getResourceInfo(Finder finder, String path, Request request, Response response) { // The handler instance targeted by this finder. final Handler handler = finder.createTarget(finder.getTargetClass(), request, response); As near as I can tell, in Restlet 1.1.1, that line in WadlApplication is the only place that uses finder.createTarget(class, request, response). Suggestions to change Finder and WadlApplication: 1. Change WadlApplication to use finder.findTarget(request, response) instead of finder.createTarget(class, request, response) 2. If there is no need for finder.createTarget(Class<? extends Handler>, Request, Response) to be public, I would suggest that it be demoted, and that WadlApplication be changed simple to use finder.findTarget(request, response). Here is further analysis of why this fails with the Guice version, and a workaround for Tim Peierls code suggestions. Workaround for Guice Finder: The Guice Finder does not implement the method createTarget(Class<? extends Handler>, Request, Response), defaulting it to the Finder implementation. Additionally, it does not implement getTargetClassname, because it allows targets to be found by Guice Keys, which are more generic than classnames. When used from WadlApplication, finder.getTargetClass returns null, and finder.createTarget then fails. I implemented a deponent version createTarget(Class<? extends Handler>, Request, Response) which ignores Handler if null, and checks it against the class if one is specified. @Override public Handler createTarget(Class<? extends Handler> targetClass, Request request, Response response) { if (targetClass != null && Key.get(targetClass) != key) throw new RuntimeException(String.format("RestletFinderFactory.createTarget targetClass is %s but Key %s as not equal.", targetClass, key)); return getInjector().getInstance(key); } Conclusion: I think this solution is not optimal. I believe the main issues are raised above and would prefer to see the createTarget(class, request, response) method deprecated and WadlApplication changed to use findTarget instead. Leigh. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1118930
