Hi Craig, Paul-
Thanks for responding, and I think that does answer my question.
What this seems to mean is that JAX-RS is not a stand-alone
specification, and any implementation of it is essentially useless
without extra features outside the realm of what's covered by JAX-RS
itself (specifically the ability to access any kind of application
state or services), which in turn seems to imply that there's
essentially no such thing as _portable_ JAX-RS code, and never will
be.
I suppose that this is no big deal for users who are already committed
to using big JEE application server stacks (and who additionally don't
mind waiting a while for EE6 and Web Beans to sort themselves out
before being able to develop anything).
But for users (like me) who are interested in lighter-weight, or at
least non-JEE, development stacks (in my case OSGi + a java web server
like Jetty, Grizzly, or Simple, perhaps not even using the Servlet api
at all) this is disappointing. JAX-RS looks initially like it could
be a great new baggage-free _standard_ for unifying the common task
of writing a web application and an accompanying web service. And
most of the glowing introductions to JAX-RS technology in articles and
documentation strongly imply this.
But it seems that to use JAX-RS in a non-JEE environment is really to
use JAX-RS-Jersey-Spring, or JAX-RS-Jersey-Guice, or
JAX-RS-Resteasy-Spring, or JAX-RS-Restlet, etc all of which do things
differently. Which is kind of a bummer.
I suppose I should just be happy that open source libraries and
tooling is getting better at supporting RESTful web development (and
Jersey seems like it's playing a big role here). I just wish I didn't
feel a little mislead with respect to JAX-RS....
Thanks,
-Dave Fogel