Implementing a StringReaderProvider that delegates generic type extraction to other providers

[Stephane Bailliez]

I'm trying to figure out if it is possible to implement a
StringReaderProvider that delegates extraction of the generic type to other
providers.

In some way the logic would be similar to the
MultivaluedParameterExtractorFactory but I cannot find any way to actually
get ahold of the list of providers (StringReaderWorkers) in such a provider.

I see that everything is initialized 'manually' in WebApplicationImpl and
the StringReaderFactory is created, configured and injected manually but I
don't seem to find any extension point to be able to get it via normal
injection.

Any pointers ?

If you wonder what this is for, this is to support Google Guava Optional<T>
for @QueryParam. I have something that works right now, but that required
me to define manually the list of the StringReaderProvider, as well as
reimplemented an entire queryparam injectable provider so that is not
really optimal while it seems everything could be done within one single
StringReaderProvider since this is basically just a wrapper around a type.

Cheers,

-- stephane

[George Sapountzis]

Post by Stephane Bailliez
I'm trying to figure out if it is possible to implement a
StringReaderProvider that delegates extraction of the generic type to other
providers.

In order to do this, you would need for StringReaderProvider to be a
"component" i.e. support injection (this seems possible in jersey, see
[1]).

Then in your user-defined StringReaderProvider you should be able to
extract the type parameter and delegate extraction to the injected
StringReaderWorkers. The above seems like circular dependency
injection (where one part gets resolved with @Context and the other
part gets resolved with ServiceLoader) which I don't know how it gets
resolved in jersey but may be possible to do using setter injection
...

You actually need an extension point that is a decorator/adapter
around StringReaderWorkers (I don't think there is such an extension
point in jersey but can be emulated with param injectables).

Post by Stephane Bailliez
In some way the logic would be similar to the
MultivaluedParameterExtractorFactory but I cannot find any way to actually
get ahold of the list of providers (StringReaderWorkers) in such a provider.
I see that everything is initialized 'manually' in WebApplicationImpl and
the StringReaderFactory is created, configured and injected manually but I
don't seem to find any extension point to be able to get it via normal
injection.
Any pointers ?
If you wonder what this is for, this is to support Google Guava Optional<T>
to define manually the list of the StringReaderProvider, as well as
reimplemented an entire queryparam injectable provider so that is not really
optimal while it seems everything could be done within one single
StringReaderProvider since this is basically just a wrapper around a type.

I did this in samson for Form<T> and actually used user-defined
form/query param injectables as
StringReaderWorkers/MultivaluedParameterExtractorProvider decorators.
You can avoid the manual definition of StringReaderProvider since
StringReaderWorkers is an injectable interface, see [2][3][4]

regards,
George

[1] public static class RootElementProvider extends
JAXBStringReaderProviders implements StringReaderProvider
[2] https://github.com/gsapountzis/samson
[3] https://github.com/gsapountzis/samson/blob/master/samson-jersey/src/main/java/samson/jersey/JFormProviderInjectableProvider.java
[4] https://github.com/gsapountzis/samson/blob/master/samson-jersey/src/main/java/samson/jersey/FormParamInjectableProvider.java

[Stephane Bailliez]

Post by George Sapountzis
I did this in samson for Form<T> and actually used user-defined
form/query param injectables as
StringReaderWorkers/MultivaluedParameterExtractorProvider decorators.
You can avoid the manual definition of StringReaderProvider since
StringReaderWorkers is an injectable interface, see [2][3][4]

Oh sweet, I missed that, thanks for the pointer !

Your samson project looks definitely useful, I'll keep an eye on it, looks
like something we may need at some point

-- stephane