Okay, so I answered that without even realizing that providerServices is
being used in the constructor. It wouldn't be set before the constructor is
called.
On Mon, Jul 18, 2011 at 11:10 AM, John G. Lussmyer
<Cougar_at_casadelgato.com>wrote:
> So, I tried that.
> providerServices never gets set. It's null.
>
>
> On 7/15/2011 9:57 PM, Ryan Stewart wrote:
>
> If the constructor is the problem, I believe you could also inject into a
> field instead:
> @Provider
> public class MyUnmarshallerResolver implements
> ContextResolver<Unmarshaller> {
> @Context ProviderServices providerServices;
>
> public MyUnmarshallerResolver() {
> providerServices.getProvidersAndServices..
> }
> ...
> }
>
> If your @Providers are coming from Spring, then you're using
> jersey-spring, and making it a spring bean is the "normal" way of doing it
> then.
>
> On Fri, Jul 15, 2011 at 4:39 PM, John G. Lussmyer <Cougar_at_casadelgato.com>wrote:
>
>> Getting back to this now...
>>
>> I think I figured out how to use the suggested code, but it has pointed
>> out another issue with our setup.
>>
>> Our @Provider classes don't seem to be able to be automatically found.
>> The only way we've been able to get them to be loaded and available is if
>> we load it via the Spring applicationContext - which of course requires a
>> default no-param constructor.
>>
>> How can we get them to be found by whatever system is "normal" for jersey?
>>
>>
>>
>> On 7/12/2011 2:56 PM, Pavel Bucek wrote:
>>
>>> you should be able to do it via injected instance of ProviderServices:
>>>
>>> @Provider
>>> public class MyUnmarshallerResolver implements
>>> ContextResolver<Unmarshaller> {
>>> public MyUnmarshallerResolver(@Context ProviderServices
>>> providerServices) {
>>> providersServices.getProvidersAndServices..
>>>
>>> }
>>> ...
>>> }
>>>
>>> let me know whether it helped - if not, I should be able to create better
>>> sample.
>>>
>>> Regards,
>>> Pavel
>>>
>>>
>>>
>>> On 7/12/11 8:00 PM, John G. Lussmyer wrote:
>>>
>>>> Thank you, that does help.
>>>> I also found that we already have an @Provider for our JAXBContext -
>>>> which brings up the question, is there a standard way for me to get the
>>>> JAXBContext created by that @Provider to use in my Unmarshaller @Provider?
>>>>
>>>> On 7/12/2011 7:58 AM, Pavel Bucek wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> you can set your own Unmarshaller instance by implementing
>>>>> ContextResolver<Unmarshaller>:
>>>>>
>>>>> @Provider
>>>>> public class MyUnmarshallerResolver implements
>>>>> ContextResolver<Unmarshaller> {
>>>>> ...
>>>>> }
>>>>>
>>>>> See:
>>>>> http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/ContextResolver.html
>>>>>
>>>>> Regards,
>>>>> Pavel
>>>>>
>>>>> On 7/12/11 4:42 PM, cougar_at_casadelgato.com wrote:
>>>>>
>>>>>> We are using jersey with jaxb generated classes.
>>>>>> We'd like to enable input data validation, but I've been unable to
>>>>>> figure out just how to do this.
>>>>>> Is there a tutorial somewhere for this?
>>>>>>
>>>>>> It looks like I'll need to generate a schema from the xsd file, but
>>>>>> all
>>>>>> the instructions for using it involve setting up an unmarshaller -
>>>>>> which jersey seems to do internally, so I don't have access to it.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> --
>> John G. Lussmyer mailto:Cougar_at_CasaDelGato.Com
>> Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com
>>
>>
>>
>
>
> --
> --
> John G. Lussmyer mailto:Cougar_at_CasaDelGato.Com <Cougar_at_CasaDelGato.Com>
> Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com
>
>