[
https://issues.apache.org/jira/browse/CXF-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664513#action_12664513
]
Andrzej Michalec commented on CXF-1982:
---------------------------------------
Ah, now I see. You said very important thing applying to CXF implementation --
currently PUT ANNOTATIONS ON INTERFACE/ABSTRACT TYPE
So by example, I confirm that following modification of my previous example
works fine in this case:
public interface SubService {
@GET
@Produces("text/xml")
SubService getThis();
@GET
@Path("/value")
@Produces("text/plain")
String getValue(@Context UriInfo ui);
}
---------------
@XmlRootElement(name = "subservice")
public class SubServiceImpl implements SubService {
private String value = "sub value";
public SubService getThis() {
return this;
}
public String getValue(UriInfo ui) {
return value + ui.getAbsolutePath();
}
}
It was not obvious to me, since googling for examples reveals that majority
JAX-RS implementations allow dynamic/runtime resolution of URIs.
This way I cannot do what I tried from the very beginning:
@XmlRootElement(name = "subservice")
public class SubServiceImpl implements SubService {
.... // content as above plus:
@Path("/value-new")
public String getNonInterfaceMethod() {
return ...
}
}
attempt to call for "/sub/value-new" results with:
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: No resource method found on a subresource
locator SubService
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:174)
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:64)
...
for me it means URI resolution is STATIC based on compile types, not runtime
types while JAX-RS spec says dynamic resolution is a must
I think that we can either rename this defect (or close it and open new) that
stresses failure on dynamic resolution.
Documentation you pointer URL to, should also be more specific on this
limitation.
cheers,
andy.
PS. I feel guilty taking so much your time, but docs are not clean leading to
confusion like this... so thanx once more for supersonic responses ;)
> Sub-resource locator fails on subtyping
> ---------------------------------------
>
> Key: CXF-1982
> URL: https://issues.apache.org/jira/browse/CXF-1982
> Project: CXF
> Issue Type: Bug
> Components: REST
> Affects Versions: 2.1.3, 2.2
> Environment: Tomcat 5.5.x
> Reporter: Andrzej Michalec
> Attachments: beans.xml, web.xml
>
>
> Attempt to use subresource locator with subtyping lead to following problem:
> 2009-01-15 03:31:28 org.apache.cxf.jaxrs.JAXRSServiceFactoryBean
> checkMethodDispatcher
> WARNING: No resource methods found for resource class
> org.apache.cxf.jaxrs.model.ClassResourceInfo
> 2009-01-15 03:31:28
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
> destroySingletons
> INFO: Destroying singletons in
> org.springframework.beans.factory.support.defaultlistablebeanfact...@1891d5d:
> defining beans
> [cxf,org.apache.cxf.bus.spring.BusApplicationListener,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.resource.ResourceManager,org.apache.cxf.configuration.Configurer,org.apache.cxf.binding.BindingFactoryManager,org.apache.cxf.transport.DestinationFactoryManager,org.apache.cxf.transport.ConduitInitiatorManager,org.apache.cxf.wsdl.WSDLManager,org.apache.cxf.phase.PhaseManager,org.apache.cxf.workqueue.WorkQueueManager,org.apache.cxf.buslifecycle.BusLifeCycleManager,org.apache.cxf.endpoint.ServerRegistry,org.apache.cxf.endpoint.ServerLifeCycleManager,org.apache.cxf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.transport.servlet.ServletTransportFactory,org.apache.cxf.jaxrs.JAXRSBindingFactory,jaxRsServer];
> root of factory hierarchy
> 2009-01-15 03:31:28 org.springframework.web.context.ContextLoader
> initWebApplicationContext
> SEVERE: Context initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'jaxRsServer': Error setting property values; nested exception is
> org.springframework.beans.PropertyBatchUpdateException; nested
> PropertyAccessExceptions (1) are:
> PropertyAccessException 1:
> org.springframework.beans.MethodInvocationException: Property 'serviceBeans'
> threw exception; nested exception is java.lang.NullPointerException
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1278)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1010)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:472)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
> ...
> To reproduces on CXF 2.2 use following code snippet (it also fails in CXF
> 2.1.3-stable using @ProduceMime):
> @Produces("text/xml")
> public class RootService {
> @GET
> @Path("/")
> public String getThis() {
> return "<root>Root service</root>";
> }
> //@GET disabled to delegate to sub-resource
> //when SubService is returned it works fine
> //when java.lang.Object is returned it FAILS with Spring autowiring...
> weird
> @Path("/sub")
> public SubService getSub() {
> return new SubService();
> }
> }
> -------------
> @Produces("text/xml")
> @XmlRootElement
> public class SubService {
> private String value = "sub value";
>
> @GET
> public Object getThis() {
> return this;
> }
> @GET
> @Path("/value")
> public String getValue() {
> return value;
> }
> }
> I believe JAX-RS specification clearly points out that
> "[...]implementation MUST dynamically determine the class of object returned
> rather than relying on the static sub-resource locator return type since the
> returned instance may be a subclass of the declared type with potentially
> different annotations[...]"
> As reference see Jboss example returning java.lang.Object from locator:
> http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1.0-beta-7/userguide/html/JAX-RS_Resource_Locators_and_Sub_Resources.html
> If there are some assumed limitation please provide workarounds for dynamic
> subresources.
> (Side note: effective behavior is very similar to CXF-1762 suffering from
> method dispatching problems; maybe solution is similar).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
