I tried moving the use of it to the getContext() method.
Still wasn't set.
On 7/21/2011 10:12 AM, Ryan Stewart wrote:
> 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 <mailto: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 <mailto: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
>> <mailto: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
>> <mailto:Cougar_at_CasaDelGato.Com>
>> Electric Vehicle Battery Monitoring Systems,
>> http://www.CasaDelGato.com
>>
>>
>>
>
>
> --
> --
> 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
Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com