Disable automatic registration of JAX-RS providers via META-INF/services mechanism

[Michal Gajdos]

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

[cowwoc]

-1. Please find another way to make the two co-exist.

1. Jersey 1.x to 2.x migration is already hell. Don't make it any harder.
2. I question the cost/benefit of making any change at all, because
what percentage of Jersey users actually need to run both at the
same time?
3. You're putting the burden on the wrong person. If anything, the
person wanting to run both versions should experience extra burden,
not the person who only wants to run one version.

My suggestion: Release a new version of Jersey 1.x which contains the
Jersey version number in META-INF/services. When Jersey 2.x runs across
a META-INF/services associated with Jersey 1.x it can ignore it. Anyone
wishing to run Jersey 1.x and 2.x on the same classpath must upgrade to
this newer version of Jersey 1.x.

Gili

Post by Michal Gajdos
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

[Robert DiFalco]

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.

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

[c***@public.gmane.org]

Post by Robert DiFalco
I'm okay with this, I'm not a fan of META-INF/services. It's a little

too

Post by Robert DiFalco
magical for me. Of course this would not have to break other things

that

Post by Robert DiFalco
rely on this functionality but don't interact with Jersey like the

newer

Post by Robert DiFalco
JDBC drivers.
However, I would like this change better if you guys would also stop

using

Post by Robert DiFalco
META-INF/services yourselves. Personally, even for internal stuff I

would

Post by Robert DiFalco
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.

I actually agree with Robert on this one. One of the annoying things I
just ran into is the fact that Provider JARs include
META-INF/services/javax.ws.rs.ext.MessageBodyReader with different
values. This prevents me from unpacking all JARs into a centralized
location, which would simplify things greatly for running Jetty from an
executable JAR file.

At the very least, please make sure there are no filename collisions.
Instead of requiring each plugin to provide
META-INF/services/javax.ws.rs.ext.MessageBodyReader it could:

1. Provide META-INF/services/com.company.MyReader
2. Jetty would use Reflection to inspect the class file to figure out
what kind of Provider it is (whether it's a reader or not).

This requires one extra step on Jetty's behalf (#2) but would be a lot
easier to deal with.

Also, I see you guys already have META-INF/jersey-module-version which
indicates which version of Jersey a user is running. Why don't you use
that to differentiate between Jersey 1.x and 2.x running on the same
server?

Gili