On 10.04.2013, at 22:33, "Markus KARG" <markus_at_headcrashing.eu> wrote:
> I wonder what kind of filter you are writing that implies the need for a
> database connection?
That was just an example, could be anything, that depends on the library user's 'backend'
A logging service to stream a log to is probably a better example or just configuration information (in order to avoid a discussion about a 'database connection' being a thread-serializing bottleneck').
The point is really: how to leverage JAX-RS's DI without depending on Jersey/RESTeasy/CXF or Glassfish/JBoss specifically.
Presumably this would add another layer of indirection to the JAX-RS implementations. But since 'Features' make such a nice bag for bundled third party filters and interceptors it is odd that there is no way to hook something into those filters beyond attributes of annotations (e.g. @Cacheable("max-age=60") )
Jan
>
>> -----Original Message-----
>> From: Jan Algermissen [mailto:jan.algermissen_at_nordsc.com]
>> Sent: Mittwoch, 10. April 2013 18:50
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Custom Providers
>>
>> Hi,
>>
>> facing the task of writing a general library of some filters for JAX-RS
>> 2 I really find it confusing, that there is no JAX-RS framework-level
>> way to write a custom provider. (For example to inject a library-user
>> provided database connection of some sort into a filter or feature).
>>
>> As it looks, one has to hard-wire some components of such a library
>> with parts of a particular JAX-RS implementation (to get @Context
>> injection) or particular container (to get CDI). Both seems quite odd,
>> actually. Or you have to come up with solutions for every
>> implementation/container and have users pick.
>>
>> Would be curious how others feel about that. Maybe an issue for 2.x or
>> 3.0?
>>
>> Or am I missing something entirely?
>>
>>
>> Jan
>>
>
>