-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
On 28/04/2014 8:02 AM, Michal Gajdos 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