Martin Grotzke wrote:
>
> On Wed, 2008-08-27 at 16:02 +0200, Paul Sandoz wrote:
>> Martin Grotzke wrote:
>>> On Wed, 2008-08-27 at 14:52 +0200, Paul Sandoz wrote:
>>>> Martin Grotzke wrote:
>>>>>> We can supply an implementation of an InjectableProvider that reuses
>>>>>> the Autowired annotation. That implementation can be equivalent to
>>>>>> that of our own @Inject annotation. So for Spring 2.5.x users they do
>>>>>> not require a Jersey specific annotation.
>>>>> Hmm, I'm somehow confused. Spring 2.5 users already can use the Spring
>>>>> annotations and don't have to use our @Inject. Spring does the whole job
>>>>> based on the spring 2.5 annotations. Though, I don't want to depend on
>>>>> the spring 2.5 annotations but still support spring 2.0.
>>>>>
>>>> On fields yes, but not for constructors and methods that Jersey is
>>>> responsible for invoking. It would only require supporting on 2.5.x.
>>> @Autowired is used by spring at bean creation time. So if you have a
>>> spring bean that has annotated some method with @Autowired spring would
>>> try to invoke this method when it creates the object. If there's any
>>> method argument that spring cannot supply:
>>>
>>> "By default, the autowiring will fail whenever zero candidate beans are
>>> available; the default behavior is to treat annotated methods,
>>> constructors, and fields as indicating required dependencies. This
>>> behavior can be changed as demonstrated below." [1]
>>>
>>> I'd prefer not to redefine the semantics of @Autowired in the context of
>>> jersey, as this might force users to change their software when the
>>> start using jersey.
>>>
>>> Or do you have restrictions in mind, when jersey should use spring's
>>> @Autowired annotation? Perhaps you might give an example how this should
>>> be used?
>>>
>> I incorrectly thought @Autowired could be a replacement @Inject,
>> especially for annotated parameters on resource class constructors and
>> methods e.g. think of a resource method that requires a reference to a
>> spring bean.
>>
>> But from what you describe it does not do what i expected it might i.e.
>> @Autowired is not meant to be used on constructor/method parameters.
> Yes for constructors, there you can use @Autowired. For method
> parameters spring tries to invoke this method with beans pulled from its
> own beanfactory - so yes/no for method parameters :)
>
> Though, it would be nice to support injection of spring beans via
> @Inject in method parameters.
>
It is already possible to use @Inject on constructor or method parameters.
>
>>
>>>> can be set to declare a default ResourceProvider when one is not
>>>> declared on a resource class. Thus the SpringServlet can set this
>>>> property (if not already set) and the SpringServlet ResourceProvider
>>>> implementation can look at the @Component annotation and choose to defer
>>>> to the singleton or per-request ResourceProvider implementations.
>>> Ok. I'll do a basic implementation (depending on spring 2.5) and send
>>> you a diff.
>>>
>> OK!
>
> Here it is. It's codified what I thought how it should work, and after
> having a look at ResourceProviderFactory.createProvider.
>
> Unfortunately it does not work, when running the
> SpringScopedResourceTest (or any other spring test) I get this
> exception:
>
> Aug 27, 2008 6:09:14 PM com.sun.jersey.api.core.PackagesResourceConfig init
> INFO: Provider classes found:
> [INFO] SpringServlet - -The spring Component annotation is present, we're using spring >= 2.5
> [ERROR] SpringResourceProvider - -Could not initialize resource provider for resource class com.sun.jersey.impl.wadl.WadlResource
> java.lang.NullPointerException
> at com.sun.jersey.spi.resource.ResourceConstructor.getConstructor(ResourceConstructor.java:78)
> at com.sun.jersey.impl.resource.PerRequestProvider.init(PerRequestProvider.java:79)
> at com.sun.jersey.spi.spring.container.servlet.SpringResourceProvider.init(SpringResourceProvider.java:156)
> at com.sun.jersey.spi.resource.ResourceProviderFactory.createProvider(ResourceProviderFactory.java:132)
> at com.sun.jersey.impl.model.ResourceClass.init(ResourceClass.java:182)
> at com.sun.jersey.impl.application.WebApplicationImpl.getResourceClass(WebApplicationImpl.java:258)
> at com.sun.jersey.impl.application.WebApplicationImpl.createWadlResource(WebApplicationImpl.java:866)
> at com.sun.jersey.impl.application.WebApplicationImpl.processRootResources(WebApplicationImpl.java:848)
> at com.sun.jersey.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:675)
> at com.sun.jersey.spi.spring.container.servlet.SpringServlet.initiate(SpringServlet.java:169)
>
> I think it's random that it complains when creating the WadlResource,
> before the exception was thrown when creating the SpringScopedResource.
>
> Do you have any idea what might be the reason?
>
Not sure, i will take a look later this week. I am a bit busy at the
moment getting Jersey in line with the final 311 API.
Thanks,
Paul.
> Cheers,
> Martin
>
>
>
>> Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109