No target class was defined for this finder ...
|
|
JohnBat26
|
Hello.
I attempt update Restlet from 1.2-M2 to 2.0-M3.With 1.2-M2 all work ok. I use Spring Framework 2.5.6. and have next routing: see attached file. But I attain error: No target class was defined for this finder: org.restlet.ext.spring.SpringFinder$$EnhancerByCGLIB$$e5294ae0_115@1d3375 I don't understand why appears this error?!? Help me please <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:security="http://www.springframework.org/schema/security" xmlns:jee="http://www.springframework.org/schema/jee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:util="http://www.springframework.org/schema/util" xsi:schemaLocation=" http://www.springframework.org/schema/beans classpath:schema/spring-beans-2.5.xsd http://www.springframework.org/schema/jee classpath:schema/spring-jee-2.5.xsd http://www.springframework.org/schema/context classpath:schema/spring-context-2.5.xsd http://www.springframework.org/schema/tx classpath:schema/spring-tx-2.5.xsd http://www.springframework.org/schema/beans classpath:schema/spring-beans-2.5.xsd http://www.springframework.org/schema/aop classpath:schema/spring-aop-2.5.xsd http://www.springframework.org/schema/util classpath:schema/spring-util-2.5.xsd http://www.springframework.org/schema/security classpath:schema/spring-security-2.5.xsd"> <!-- required for autowiring --> <context:annotation-config /> <bean name="root" class="org.restlet.ext.spring.SpringRouter"> <property name="attachments" ref="resourceMap" /> <property name="finderClass" value="org.restlet.ext.spring.SpringFinder" /> </bean> <bean id="resourceMap" class="java.util.HashMap"> <constructor-arg> <map> <!-- STB --> <entry key="/stb/mapper/{mac},{ip}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="stbIpMapperResource" /> </bean> </entry> <entry key="/stb/registration"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="stbRegistrationResource" /> </bean> </entry> <entry key="/stb/logout"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="stbLogoutResource" /> </bean> </entry> <!-- BTV --> <entry key="/btv/imageMap/{width},{height},{bySide},{format},{colorMode}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="btvImageMapResource" /> </bean> </entry> <entry key="/btv/channels/{locale},{width},{height},{bySide},{format}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="btvСhannelsResource" /> </bean> </entry> <entry key="/btv/privateData/{profileId}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="btvPrivateDataResource" /> </bean> </entry> <entry key="/btv/epg/current/single/{channelId},{locale}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="epgCurrentProgramResource" /> </bean> </entry> <entry key="/btv/epg/current/all/{locale}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="epgCurrentProgramAllChannelsResource" /> </bean> </entry> <entry key="/btv/epg/day/{channelId},{locale},{startTime},{countSymbols}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="epgOverDayByChannelResource" /> </bean> </entry> <entry key="/btv/epg/notifications/{profileId}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="epgNotificationsResource" /> </bean> </entry> <entry key="/btv/epg/notification/{profileId}/{id},{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="epgNotificationResource" /> </bean> </entry> <entry key="/btv/npvr/programRecord/{profileId}/{programId},{ip}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="npvrProgramRecordResource" /> </bean> </entry> <entry key="/btv/npvr/records/{profileId},{ip}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="npvrRecordsResource" /> </bean> </entry> <entry key="/btv/npvr/record/{profileId}/{id},{ip},{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="npvrRecordResource" /> </bean> </entry> <!-- VOD --> <entry key="/vod/categories/{profileId}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="vodCategoriesResource" /> </bean> </entry> <entry key="/vod/movies/{profileId}/{categoryId},{from},{limit}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="vodMoviesResource" /> </bean> </entry> <entry key="/vod/movie/offerings/{profileId}/{movieId}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="vodOfferingsResource" /> </bean> </entry> <entry key="/vod/movie/movieOrder/{profileId}/{id},{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="movieOrderResource" /> </bean> </entry> <entry key="/vod/movie/FavouriteItem/{profileId}/{id},{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="favouriteItemResource" /> </bean> </entry> <entry key="/vod/asset/{profileId}/{assetId},{ip}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="vodAssetResource" /> </bean> </entry> <!-- CUSTOMER --> <entry key="/profileLogo/{pictogramId}/{width},{height},{format},{colorMode}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="profileLogoResource" /> </bean> </entry> <entry key="/profiles/{width},{height},{format},{colorMode}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="profilesResource" /> </bean> </entry> <entry key="/customer/{profileId}/{width},{height},{format},{colorMode},{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="profileResource" /> </bean> </entry> <entry key="/customer/parameters/{profileId}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="customerParametersResource" /> </bean> </entry> <entry key="/customer/parameters/{profileId}/{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="customerParametersResource" /> </bean> </entry> <entry key="/customerId"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="customerResource" /> </bean> </entry> <entry key="/customer/parameter/{profileId}/{name}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="customerParameterResource" /> </bean> </entry> <entry key="/customer/parameter/{profileId}/{name},{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="customerParameterResource" /> </bean> </entry> <entry key="/customer/parameter/{profileId}/{name},{value},{expiredTime},{method}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="customerParameterResource" /> </bean> </entry> <entry key="/customer/additional/{width},{height},{format},{colorMode}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="customerAdditionalResource" /> </bean> </entry> <!-- OTHERS --> <entry key="/errorTest/{errorCode}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="errorTestResource" /> </bean> </entry> </map> </constructor-arg> </bean> <!-- Scan Spring Components. Note the Resource will be automatically picked --> <context:component-scan base-package="ru.cti.tve.ng" /> <!-- Spring Application --> <bean id="component" class="org.restlet.ext.spring.SpringComponent"> <property name="logService" ref="logService" /> <property name="defaultTarget" ref="application" /> </bean> <bean id="application" class="org.restlet.Application" > <property name="name" value="portalFacadeNGApplication"></property> <property name="statusService" ref="tveStatusService" /> <property name="root" ref="root" /> </bean> <bean id="logService" class="org.restlet.service.LogService"> <constructor-arg value="true" type="boolean" /> <property name="enabled" value="true" /> <property name="logFormat" value="{cia} {m} {S} {rp} AGENT:{cig} REF:{fp}" /> <property name="loggerName" value="restlet" /> </bean> <bean id="tveStatusService" class="ru.cti.tve.ng.web.restlet.TveStatusService"> </bean> <!-- <bean id="tveStatusService" class="ru.cti.tve.ng.web.restlet.custom.TveStatusService"> <property name="enabled" value="true" /> <property name="overwrite" value="false" /> </bean> --> <bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource"> <property name="basename"> <value>messages</value> </property> </bean> <bean id="iptvmwConfig" class="org.springframework.context.support.ResourceBundleMessageSource"> <property name="basename"> <value>iptvmw-config</value> </property> </bean> <bean id="tveResourceHelper" class="ru.cti.tve.ng.web.resource.TveResourceHelper"> <property name="appName" value="/portal-facade-ng/" /> </bean> <bean id="profilesResource" class="ru.cti.tve.ng.web.resource.customer.ProfilesResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="profileResource" class="ru.cti.tve.ng.web.resource.customer.ProfileResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="customerResource" class=" ru.cti.tve.ng.web.resource.customer.CustomerResource " scope="prototype"> <property name="available" value="true" /> </bean> <bean id="customerParameterResource" class="ru.cti.tve.ng.web.resource.customer.CustomerParameterResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="customerParametersResource" class="ru.cti.tve.ng.web.resource.customer.CustomerParametersResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="customerAdditionalResource" class="ru.cti.tve.ng.web.resource.customer.CustomerAdditionalResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="btvPrivateDataResource" class="ru.cti.tve.ng.web.resource.btv.BtvPrivateDataResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="btvChannelsResource" class="ru.cti.tve.ng.web.resource.btv.BtvChannelsResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="btvImageMapResource" class="ru.cti.tve.ng.web.resource.btv.BtvImageMapResource" scope="prototype"> <property name="available" value="true" /> </bean> <!-- VOD --> <bean id="vodCategoriesResource" class="ru.cti.tve.ng.web.resource.vod.VodCategoriesResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="vodOfferingsResource" class="ru.cti.tve.ng.web.resource.vod.VodOfferingsResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="vodMoviesResource" class="ru.cti.tve.ng.web.resource.vod.VodMoviesResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="vodMovieResource" class="ru.cti.tve.ng.web.resource.vod.VodMovieResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="movieOrderResource" class="ru.cti.tve.ng.web.resource.vod.VodMovieOrderResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="favouriteItemResource" class="ru.cti.tve.ng.web.resource.vod.VodFavouriteItemResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="vodAssetResource" class="ru.cti.tve.ng.web.resource.vod.VodAssetResource" scope="prototype"> <property name="available" value="true" /> </bean> <!-- PROFILES --> <bean id="profileLogoResource" class="ru.cti.tve.ng.web.resource.customer.ProfileLogoResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="epgCurrentProgramResource" class="ru.cti.tve.ng.web.resource.btv.EpgCurrentProgramResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="epgCurrentProgramAllChannelsResource" class="ru.cti.tve.ng.web.resource.btv.EpgCurrentProgramAllChannelsResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="epgOverDayByChannelResource" class="ru.cti.tve.ng.web.resource.btv.EpgOverDayByChannelResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="epgNotificationsResource" class="ru.cti.tve.ng.web.resource.btv.EpgNotificationsResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="epgNotificationResource" class="ru.cti.tve.ng.web.resource.btv.EpgNotificationResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="npvrProgramRecordResource" class="ru.cti.tve.ng.web.resource.btv.NpvrProgramRecordResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="npvrRecordsResource" class="ru.cti.tve.ng.web.resource.btv.NpvrRecordsResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="npvrRecordResource" class="ru.cti.tve.ng.web.resource.btv.NpvrRecordResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="errorTestResource" class="ru.cti.tve.ng.web.resource.ErrorTestResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="stbIpMapperResource" class="ru.cti.tve.ng.web.resource.stb.StbIpMapperResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="stbRegistrationResource" class="ru.cti.tve.ng.web.resource.stb.StbRegistrationResource" scope="prototype"> <property name="available" value="true" /> </bean> <bean id="stbLogoutResource" class="ru.cti.tve.ng.web.resource.stb.StbLogoutResource" scope="prototype"> <property name="available" value="true" /> </bean> </beans> |
||||||||||||||||
jlouvel
|
Hi Eugene,
Where you able to resolve this issue? I have just updated the Spring extension to support the new resource API. But in your case you seem to be using the older resource classes, which should work the same. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : Eugene [mailto:[hidden email]] Envoyé : lundi 1 juin 2009 12:57 À : [hidden email] Objet : No target class was defined for this finder ... Hello. I attempt update Restlet from 1.2-M2 to 2.0-M3.With 1.2-M2 all work ok. I use Spring Framework 2.5.6. and have next routing: see attached file. But I attain error: No target class was defined for this finder: org.restlet.ext.spring.SpringFinder$$EnhancerByCGLIB$$e5294ae0_115@1d3375 I don't understand why appears this error?!? Help me please ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2360830 |
||||||||||||||||
webpost
|
Is this issue resolved? I'm facing the exact same problem. If it has been resolved, please provide the steps you took to resolve it. Thank you.
p.s. I'm running on 2.0-SNAPSHOT. and pulling in cglib 2.2. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2387945 |
||||||||||||||||
Cheng Lee
|
I'm using org.restlet.ext.spring 2.0-M3 and I'm seeing the same problem.
To solve "No target class was defined for this finder ..." I had to add an additional property "targetClass" in my spring config and add a factory bean to instantiate a Class: <entry key="/realEstate"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="realEstateResource" /> <property name="targetClass" ref="realEstateResourceClass"></property> </bean> </entry> <bean id="realEstateResource" class="com.company.RealEstateResource" scope="prototype"> <property name="configuration" ref="freemarkerConfiguration" /> </bean> <bean id="realEstateResourceClass" factory-bean="realEstateResource" factory-method="getClass"/> This should make your problem go away since it will instantiate the Resource correctly. But it's still not using Spring context so read on. I've seen that the SpringFinder is not retrieving the bean "realEstateResource" from the spring context but rather instantiating "targetClass" using newInstance() and of course not enjoying any of the dependencies injection. The reason why it's not working is because I'm extending ServerResource instead of Resource. Now, the new ServerResource does not extend Handler so it will be false in org.restlet.resource.Finder line 450: if (Handler.class.isAssignableFrom((Class<? extends Handler>) getTargetClass())) { which in turn calls "find(request, response)" instead of "findTarget(request, response)". The consequence is that the lookup-method we declared above (createResource) is never called. I think I can contribute a fix for this. Regards, Cheng ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2394856 |
||||||||||||||||
Rhett Sutphin
|
Hi Cheng,
On Sep 14, 2009, at 11:07 PM, Cheng Lee wrote: > I'm using org.restlet.ext.spring 2.0-M3 and I'm seeing the same > problem. > > To solve "No target class was defined for this finder ..." I had to > add an additional property "targetClass" in my spring config and add > a factory bean to instantiate a Class: > > <entry key="/realEstate"> > <bean class="org.restlet.ext.spring.SpringFinder"> > <lookup-method name="createResource" bean="realEstateResource" /> > <property name="targetClass" ref="realEstateResourceClass"></ > property> > </bean> > </entry> > > <bean id="realEstateResource" class="com.company.RealEstateResource" > scope="prototype"> > <property name="configuration" ref="freemarkerConfiguration" /> > </bean> > > <bean id="realEstateResourceClass" factory-bean="realEstateResource" > factory-method="getClass"/> > > This should make your problem go away since it will instantiate the > Resource correctly. But it's still not using Spring context so read > on. > > I've seen that the SpringFinder is not retrieving the bean > "realEstateResource" from the spring context but rather > instantiating "targetClass" using newInstance() and of course not > enjoying any of the dependencies injection. > > The reason why it's not working is because I'm extending > ServerResource instead of Resource. Now, the new ServerResource does > not extend Handler so it will be false in > org.restlet.resource.Finder line 450: > > if (Handler.class.isAssignableFrom((Class<? extends Handler>) > getTargetClass())) { > > which in turn calls "find(request, response)" instead of > "findTarget(request, response)". The consequence is that the lookup- > method we declared above (createResource) is never called. > > I think I can contribute a fix for this. This issue is being tracked as #892: http://restlet.tigris.org/issues/show_bug.cgi?id=892 That's the place to contribute a fix if you'd care to. Be sure to read the contribution guidelines first: http://www.restlet.org/community/contribute Rhett ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2396523 |
||||||||||||||||
|
jlouvel
|
Hi guys,
As reported in issue #892, this should now work fine in SVN trunk. If you could do additional testing that would be welcome. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : Rhett Sutphin [mailto:[hidden email]] Envoyé : vendredi 18 septembre 2009 18:50 À : [hidden email] Objet : Re: No target class was defined for this finder ... Hi Cheng, On Sep 14, 2009, at 11:07 PM, Cheng Lee wrote: > I'm using org.restlet.ext.spring 2.0-M3 and I'm seeing the same > problem. > > To solve "No target class was defined for this finder ..." I had to > add an additional property "targetClass" in my spring config and add > a factory bean to instantiate a Class: > > <entry key="/realEstate"> > <bean class="org.restlet.ext.spring.SpringFinder"> > <lookup-method name="createResource" bean="realEstateResource" /> > <property name="targetClass" ref="realEstateResourceClass"></ > property> > </bean> > </entry> > > <bean id="realEstateResource" class="com.company.RealEstateResource" > scope="prototype"> > <property name="configuration" ref="freemarkerConfiguration" /> > </bean> > > <bean id="realEstateResourceClass" factory-bean="realEstateResource" > factory-method="getClass"/> > > This should make your problem go away since it will instantiate the > Resource correctly. But it's still not using Spring context so read > on. > > I've seen that the SpringFinder is not retrieving the bean > "realEstateResource" from the spring context but rather > instantiating "targetClass" using newInstance() and of course not > enjoying any of the dependencies injection. > > The reason why it's not working is because I'm extending > ServerResource instead of Resource. Now, the new ServerResource does > not extend Handler so it will be false in > org.restlet.resource.Finder line 450: > > if (Handler.class.isAssignableFrom((Class<? extends Handler>) > getTargetClass())) { > > which in turn calls "find(request, response)" instead of > "findTarget(request, response)". The consequence is that the lookup- > method we declared above (createResource) is never called. > > I think I can contribute a fix for this. This issue is being tracked as #892: http://restlet.tigris.org/issues/show_bug.cgi?id=892 That's the place to contribute a fix if you'd care to. Be sure to read the contribution guidelines first: http://www.restlet.org/community/contribute Rhett ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2396523 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2400142 |
||||||||||||||||
bgrodona
|
Hi,
I am running the 2.0 JEE Jars from the unstable URL you sent out earlier today (http://www.restlet.org/downloads/2.0/restlet-jee-2.0snapshot.zip) and am getting this error still today. I've been working on trying to get this working all day and am about to throw in the towel. I tried the earlier poster's suggestions for a fix using the targetClass solution, but then I cannot inject beans into my UserResource. Error: Message ID No target class was defined for this finder Complete Message org.restlet.ext.spring.SpringFinder$$EnhancerByCGLIB$$aac352c3_2@5e0f81b1 ----------- my config ----------- <bean id="router" class="org.restlet.ext.spring.SpringRouter"> <constructor-arg ref="feedbackRestApp" /> <property name="attachments"> <map> <entry key="/users"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="userResource"/> </bean> </entry> <entry key="/users/{email}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="userResource"/> </bean> </entry> </map> </property> </bean> <bean id="userResource" autowire="byName" scope="prototype" class="com.my.package.rest.v1.resource.UserResource"> <property name="userService" ref="userService"/> </bean> Also was getting a simular error using the SpringBeanRouter posted about here http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2400334 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2400410 |
||||||||||||||||
|
jlouvel
|
Hi Norton,
Please don't cross post. This list is for developers contributing code to Restlet. We will answer your question in the users discussion list: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24012 47 Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : norton borf [mailto:[hidden email]] Envoyé : vendredi 25 septembre 2009 22:51 À : [hidden email] Objet : RE: No target class was defined for this finder ... Hi, I am running the 2.0 JEE Jars from the unstable URL you sent out earlier today (http://www.restlet.org/downloads/2.0/restlet-jee-2.0snapshot.zip) and am getting this error still today. I've been working on trying to get this working all day and am about to throw in the towel. I tried the earlier poster's suggestions for a fix using the targetClass solution, but then I cannot inject beans into my UserResource. Error: Message ID No target class was defined for this finder Complete Message org.restlet.ext.spring.SpringFinder$$EnhancerByCGLIB$$aac352c3_2@5e0f81b1 ----------- my config ----------- <bean id="router" class="org.restlet.ext.spring.SpringRouter"> <constructor-arg ref="feedbackRestApp" /> <property name="attachments"> <map> <entry key="/users"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="userResource"/> </bean> </entry> <entry key="/users/{email}"> <bean class="org.restlet.ext.spring.SpringFinder"> <lookup-method name="createResource" bean="userResource"/> </bean> </entry> </map> </property> </bean> <bean id="userResource" autowire="byName" scope="prototype" class="com.my.package.rest.v1.resource.UserResource"> <property name="userService" ref="userService"/> </bean> Also was getting a simular error using the SpringBeanRouter posted about here http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24003 34 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=24004 10 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=2401497 |
||||||||||||||||
Tim Peierls
|
In reply to this post
by Cheng Lee
[Resurrecting an old thread to provide some context.]
Router.attach(String pathTemplate, Class<?> targetClass) has an unbounded wildcard only because it's trying to support both ServiceResource and (deprecated) Handler. If it weren't for the latter, the signature could be:
Route attach(String pathTemplate, Class<? extends ServerResource> targetClass); Is it too late to fix this? How about providing route attachResource(String pathTemplate, Class<? extends ServerResource> targetResourceClass);
? --tim On Tue, Sep 15, 2009 at 12:07 AM, Cheng Lee <[hidden email]> wrote: I'm using org.restlet.ext.spring 2.0-M3 and I'm seeing the same problem. |
||||||||||||||||
|
jlouvel
|
Some javascript/style in this post has been disabled (why?)
Hi
Tim, This
is only temporary, in Restlet 2.1, we’ll be able to remove the deprecated code
and use a stricter signature. Best
regards, De : [hidden email]
[mailto:[hidden email]] De la part de Tim Peierls [Resurrecting an old thread to provide some context.] Router.attach(String pathTemplate, Class<?>
targetClass) has an unbounded wildcard only because it's trying to support both
ServiceResource and (deprecated) Handler. If it weren't for the latter, the
signature could be: Route attach(String pathTemplate, Class<? extends
ServerResource> targetClass); Is it too late to fix this? How about providing route attachResource(String pathTemplate, Class<? extends
ServerResource> targetResourceClass); ? --tim On Tue, Sep 15, 2009 at 12:07 AM, Cheng Lee <[hidden email]> wrote: I'm using org.restlet.ext.spring
2.0-M3 and I'm seeing the same problem. |
||||||||||||||||
|
Tim Peierls
|
In reply to this post
by Tim Peierls
Won't that cause compilation problems for anyone already extending Router?
--tim On Mon, Nov 2, 2009 at 8:47 AM, Jerome Louvel <[hidden email]> wrote:
|
||||||||||||||||
|
jlouvel
|
Some javascript/style in this post has been disabled (why?)
Tim, I
haven’t thought about that point indeed. My
feeling is that extending Router is sufficiently rare so that a little API
breakage wouldn’t cause too much harm… This isn’t ideal but I prefer keeping
the simple ‘attach’ method name. I also need to test to see how an IDE like
Eclipse behaves, like if it offers a quick fix. Best
regards, De : [hidden email]
[mailto:[hidden email]] De la part de Tim Peierls Won't that cause compilation problems for anyone already
extending Router? --tim On Mon, Nov 2, 2009 at 8:47 AM, Jerome Louvel <[hidden email]>
wrote: Hi Tim, This is only temporary, in Restlet 2.1,
we’ll be able to remove the deprecated code and use a stricter signature. Best regards, De : [hidden email]
[mailto:[hidden email]]
De la part de Tim Peierls
Objet : Re: No target class was defined for this
finder ... [Resurrecting
an old thread to provide some context.] Router.attach(String
pathTemplate, Class<?> targetClass) has an unbounded wildcard only
because it's trying to support both ServiceResource and (deprecated) Handler.
If it weren't for the latter, the signature could be: Route
attach(String pathTemplate, Class<? extends ServerResource> targetClass); Is
it too late to fix this? How about providing route
attachResource(String pathTemplate, Class<? extends ServerResource>
targetResourceClass); ? --tim On
Tue, Sep 15, 2009 at 12:07 AM, Cheng Lee <[hidden email]>
wrote: I'm
using org.restlet.ext.spring
2.0-M3 and I'm seeing the same problem. |
||||||||||||||||
|
Tim Peierls
|
In reply to this post
by Tim Peierls
On Mon, Nov 2, 2009 at 9:50 AM, Jerome Louvel <[hidden email]> wrote:
Probably true. I brought it up because I was thinking (for the Guice extension) of providing a way of wrapping a Router instance to add an attach method to take an additional argument, a Qualifier annotation:
That would mean extending Router.
Usage sketch: // in application code QualifiedRouter router = QualifiedRouter.wrap(new Router(getContect())); ... router.attach("/contacts/sales", ContactResource.class, SalesContact.class);
router.attach("/contacts/tech", ContactResource.class, TechSupportContact.class); // in Guice binding code bind(ContactResource.class)
.annotatedWith(SalesContact.class) // SalesContact is an annotation declared with @Qualifier .to(SalesContactResourceImpl.class); bind(ContactResource.class) .annotatedWith(TechSupportContact.class) // TechSupportContact is an annotation declared with @Qualifier
.to(TechSupportContactResourceImpl.class); This would avoid coupling the Application initialization code to the concrete types used to handle /contacts/... requests. Not always a concern, but when it is, it's nice to have a way out.
--tim |
||||||||||||||||
|
jlouvel
|
Some javascript/style in this post has been disabled (why?)
Hi
Tim, That
looks like a useful feature. I’m just wondering why you wouldn’t just
instantiate a new QualifiedRouter class instead of relying on the static wrap()
method? Best
regards, De : [hidden email]
[mailto:[hidden email]] De la part de Tim Peierls On Mon, Nov 2, 2009 at 9:50 AM, Jerome Louvel <[hidden email]>
wrote: My feeling is that
extending Router is sufficiently rare so that a little API breakage wouldnt
cause too much harm Probably true. I brought it up because I was thinking (for the Guice
extension) of providing a way of wrapping a Router instance to add an attach
method to take an additional argument, a Qualifier annotation: That would mean extending Router. Usage sketch: // in application code QualifiedRouter router = QualifiedRouter.wrap(new
Router(getContect())); ... router.attach("/contacts/sales",
ContactResource.class, SalesContact.class); router.attach("/contacts/tech",
ContactResource.class, TechSupportContact.class); // in Guice binding code bind(ContactResource.class) .annotatedWith(SalesContact.class) // SalesContact is an
annotation declared with @Qualifier .to(SalesContactResourceImpl.class); bind(ContactResource.class) .annotatedWith(TechSupportContact.class) //
TechSupportContact isan annotation declared with @Qualifier .to(TechSupportContactResourceImpl.class); This would avoid couplingthe Application initialization code
tothe concrete types used to handle /contacts/... requests. Not always a
concern, but when it is, it's nice to have a way out. --tim |
||||||||||||||||
|
Tim Peierls
|
In reply to this post
by Tim Peierls
On Tue, Nov 3, 2009 at 4:42 AM, Jerome Louvel <[hidden email]> wrote:
Because my instinct is to avoid APIs that depend on explicit construction, which couples client code to an implementation type. For example, the wrap() method might choose a different concrete implementation of (abstract class) QualifiedRouter depending on which JSR-330-compliant DI framework was in use.
I guess I'm still having trouble getting over the absence of interfaces in Restlet. :-) --tim |
||||||||||||||||
|
jlouvel
|
Some javascript/style in this post has been disabled (why?)
Tim, We
now have three interfaces in Restlet API 2.0 !! J Regarding
the coupling, we are using an alternative helper pattern in Restlet so that the
actual implementation (of connectors for example) is delegated to a private
helper instance that can be easily switched. Therefore, we get the benefits of reducing
the number of artifacts in the API, while keeping the ability to switch
implementations. But I wouldn’t recommend our approach for all situations… It
just happens to work well, IMHO, for a public API like Restlet. It
is still possible to provide subclasses of the default implementation classes
(such as Router) in order to customize the behavior and still get code that
doesn’t depend on a special subclass. For example, how is this code: MyObject myObject =
new MySubClass(); So
different compared to: MyInterface
myObject = new MyInterfaceImpl(); You
could still externalize the instantiation using DI in both cases. BTW,
I’ve just stumbled on GIN “ (GWT INjection) is Guice for Google Web Toolkit
client-side code”: http://code.google.com/p/google-gin/ It
might be interesting to leverage in the future in Restlet edition for GWT? Best
regards, De : [hidden email]
[mailto:[hidden email]] De la part de Tim Peierls On Tue, Nov 3, 2009 at 4:42 AM, Jerome Louvel <[hidden email]>
wrote: That looks like a useful
feature. Im just wondering why you wouldnt just instantiate a new QualifiedRouter
class instead of relying on the static wrap() method? Because my instinct is to avoid APIs that depend on explicit
construction, which couples client code to an implementation type. For example,
the wrap() method might choose a different concrete implementation of (abstract
class) QualifiedRouter depending on which JSR-330-compliant DI framework was in
use. I guess I'm still having trouble getting over the absence of
interfaces in Restlet. :-) --tim |
||||||||||||||||
|
Tim Peierls
|
In reply to this post
by Tim Peierls
On Tue, Nov 3, 2009 at 10:09 AM, Jerome Louvel <[hidden email]> wrote:
It's a start! :-)
It does work well for Restlet, although I have the feeling that one of the reasons the road to OSGi-compatibility was not as smooth as you might have wished was due to the interaction of this pattern with classloader craziness.
If you were starting at the ground floor with a totally new incarnation of Restlet -- now that you're in a position, after years of experience, to define stable interfaces -- I'd strongly recommend using dependency injection to provide concrete implementations of interfaces instead of the helper pattern and class hierarchies.
Please note that this in no way prevents me from being a fierce advocate of Restlet as it is now!
Agreed, but it gets complicated when you want to extend something simultaneously in different ways. Would the following approach be more acceptable to you? interface QualifiedAttacher { Route attach(String template,
Class<? extends ServerResource> resourceType, Class<? extends Qualifier> qualifierType);
} public class Jsr330Util {
... public QualifiedAttacher qualified(Router router) { ... }
} // and in use:
import static .....Jsr330Util.qualified; Route route = router.attach("/simple", MyResource.class); Route route2 = qualified(router).attach(
"/qualified", MyOtherResource.class, MyQualifier.class);
Yes. GIN has some restrictions because it all gets compiled down to Javascript, but I'll try to bear these in mind when working on the JSE version so we don't rule out this possibility.
--tim |
||||||||||||||||
|
jlouvel
|
Some javascript/style in this post has been disabled (why?)
Hi
Tim, Thanks
for the enlightening discussion. I’ve also read Guice motivation paper and I
find it truly compelling: http://code.google.com/p/google-guice/wiki/Motivation I
might change my mind regarding interfaces for a future Restlet 3.0 version,
especially as the API is indeed getting more stable. BTW, I’ve added our
discussion as a reference to this task: “Reconsider
usage of interfaces” http://restlet.tigris.org/issues/show_bug.cgi?id=384 Regarding
your alternative design suggestion for qualified attachments, I don’t really
have a preference at this point. My advice would be to design the Guice extension
is a way that is the most natural to Guice users. We don’t want to force
Restlet API style on them; we want to have a reasonable and working bridge
between the two projects. Thanks
also for considering GIN for a future Guice extension in Restlet edition for
GWT. Best
regards, De : [hidden email]
[mailto:[hidden email]] De la part de Tim Peierls On Tue, Nov 3, 2009 at 10:09 AM, Jerome
Louvel <[hidden email]> wrote: We now have three interfaces in Restlet API
2.0!!J It's a start! :-)
It does work well for Restlet, although I
have the feeling that one of the reasons the road to OSGi-compatibility was not
as smooth as you might have wished was due to the interaction of this pattern
with classloader craziness. If you were starting at the ground floor
with a totally new incarnation of Restlet -- now that you're in a position,
after years of experience, to define stable interfaces -- I'd strongly
recommend using dependency injection to provide concrete implementations of
interfaces instead of the helper pattern and class hierarchies. Please note that this in no way prevents me
from being a fierce advocate of Restlet as it is now!
Agreed, but it gets complicated when you
want to extend something simultaneously in different ways. Would the following approach be more
acceptable to you? interface
QualifiedAttacher { Route
attach(String template, Class<?
extends ServerResource> resourceType, Class<?
extends Qualifier> qualifierType); } public
class Jsr330Util { ... public
QualifiedAttacher qualified(Router router) { ... } } // and in
use: import
static .....Jsr330Util.qualified; Route
route = router.attach("/simple", MyResource.class); Route
route2 =qualified(router).attach( "/qualified",
MyOtherResource.class, MyQualifier.class);
Yes. GIN has some restrictions because it
all gets compiled down to Javascript, but I'll try to bear these in mind when
working on the JSE version so we don't rule out this possibility. --tim |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
