I'm okay with this, I'm not a fan of META-INF/services. It's a little too
magical for me. Of course this would not have to break other things that
rely on this functionality but don't interact with Jersey like the newer
JDBC drivers.
However, I would like this change better if you guys would also stop using
META-INF/services yourselves. Personally, even for internal stuff I would
like to see Features uses when possible. Makes looking at code to see
what's REALLY going on a lot easier.
IMO, wiring should be intentional and traceable not magical.
On Mon, Apr 28, 2014 at 5:02 AM, Michal Gajdos <michal.gajdos_at_oracle.com>wrote:
> Hi,
>
> we'd like to disable automatic lookup and registration of JAX-RS extension
> providers using META-INF/services mechanism in Jersey 2.x and it's
> important for us to know your opinions about this before we actually do it.
> Contracts that would be removed from the SPI discovery by default include
> MessageBodyReader, MessageBodyWriter and ExceptionMapper.
> Automatic registration via META-INF/services has been introduced in Jersey
> 1.x to register default MBWs/MBRs required by JAX-RS spec and we've
> migrated this mechanism into Jersey 2 to make these two versions compatible
> in this regard. Jersey 2.x however takes a different approach to register
> default providers required by JAX-RS. The reason for the proposed removal
> is to make co-existence of Jersey 1 (Client) and Jersey 2 libraries on the
> same class-path possible without these interfering with each other.
> For backward compatibility, we plan to introduce a new module in Jersey
> 2.x which would enable automatic SPI registration of JAX-RS providers via
> META-INF/services in case this module is present on an application
> class-path. Additionally, for popular 3rd party libraries that rely on the
> old discovery mechanism (currently we are only aware of Jackson 2) we would
> introduce an integration module that would automatically register the
> library providers into the client/server runtime when the module is put on
> a class-path together with the 3rd party library.
>
> Any comments are welcome.
>
> Michal
>