> 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.
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