Spec should declare a vendor-neutral way to start JAX-RS server in Java SE environment

[glassfishrobot]

JAX-RS declares Java SE as one of several possible environments. Unfortunately it does not declare how to start a JAX-RS server application in pure Java SE. As a consequence, all vendors provides different methods to do so, leading to vendor-locked-in applications.

To get rid of the vendor-lock-in I'd like to propose that the JAX-RS specification defines a vendor-neutral API how a JAX-RS server application can be started in a pure Java SE environment.

This does not imply any assumptions upon how a JAX-RS implementation reacts upon such an API invocation other than "the application is started on the specified endpoint defined by the root URI appended by @ApplicationPath (if existing)".

A proposed API could look like this and is up to further discussion among the expert group:

JAXRS.start(URI rootURI, Application application)

Affected Versions

[2.1]

[glassfishrobot]

@glassfishrobot Commented
Reported by mkarg

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAX_RS_SPEC-504

[glassfishrobot]

• Issue Imported From: https://github.com/jax-rs/api/issues/509
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[mkarg]

@jansupol @asoldano @andymc12 Vendors comments requested. :-)

[mkarg]

@deki CXF comments requested. :-)

[deki]

For me this is a minor enhancement because most setups that I know run inside a container like Tomcat or Spring Boot so there is no need for a start API.

From CXF point of view it's easy to delegate from the new API to the existing JAXRSServerFactoryBean that we already have in place.

[andymc12]

Is there a lot of user demand for this? I worked on the Embeddable EJB implementation back in Java EE 7 - similar idea with an EJBContainer ec = EJBContainer.createEJBContainer(properties);. It seemed like a good idea at the time, but I never saw much customer adoption.

And I agree with @deki that there are already a lot of setups that make it easy to deploy JAX-RS apps.

If we do this, I would propose that it be optional - i.e. that a JAX-RS implementation could still be compliant even if they do not provide an implementation of this API.

[jansupol]

I can see a usage for such a declaration; microservices does not necessarily need full Servlet container to run JAX-RS application, microprofile defines JAX-RS but no Servlet.

JAX-RS standard was built on top of Servlet container from the beginning though, there can be consequences of what part of the implementation should be mandatory and what optional. The Async features for instance.

[ggam]

@jansupol while the Servlet container is usually taken for granted, are you sure the spec mandates it? El lun., 9 abr. 2018 19:40, jansupol <notifications@github.com> escribió:

…

I can see a usage for such a declaration; microservices does not necessarily need full Servlet container to run JAX-RS application, microprofile defines JAX-RS but no Servlet. JAX-RS standard was built on top of Servlet container from the beginning though, there can be consequences of what part of the implementation should be mandatory and what optional. The Async features for instance. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#509 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAucPhzr-QbYGz5tkgl01c9dvPxF0b8ks5tm5zvgaJpZM4TLuCs> .

[mkarg]

Regarding user demand: Well, I wouldn't have reactivated this task if not!

[mkarg]

@ggam The JAX-RS spec explicitly says that Servlets are NOT mandated, and JAX-RS MUST be able to run on pure Java SE, too.

[mkarg]

@andymc12 The proposal is not that an implementation MUST support Java SE, but only that IF it supports Java SE it MUST support this particular API to boot it.

[jansupol]

Well, see Section 2. For Java SE the Spec. says it may work:

An implementation MAY support zero or more endpoint types of any desired type ... How the resulting endpoint class instance is used to publish the application is outside the scope of this specification.

But the environment the implementation must work at is Servlet container.

[ggam]

But as Markus said, the spec doesn't mandate a Servlet Container even on Java EE. That means for example HttpServletRequest is not guaranteed to be there and injectable, which is pretty common. Anyway that's unrelated to this issue. El lun., 9 abr. 2018 20:33, jansupol <notifications@github.com> escribió:

…

Well, see Section 2. For Java SE the Spec. says it may work: An implementation MAY support zero or more endpoint types of any desired type ... How the resulting endpoint class instance is used to publish the application is outside the scope of this specification. But the environment the implementation must work at is Servlet container. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#509 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAucLxQbEHy-SRyMbgZ_aeOkiQxV1Ldks5tm6mGgaJpZM4TLuCs> .

[jansupol]

I am trying to say the implementation of async server operations is relied on Servlet 3.1, and without it, async should be optional.

[mkarg]

I do not understand what we talk about here. All that this issue wants is in case an implementation supports Java SE it shall use a common API to boot it. Everything else is out of scope of this issue. So we now discussing async here?

[jansupol]

Ah, we want just to specify a way to boot it, without defining what it should be capable of? Alright, it still can be useful for switching the implementations for JAXRS apps in microservices world... Sounds good.

[mkarg]

Yes, @jansupol, the sole thing this issue tries to provide is a uniform API for possibly existing Java SE bootstrap, not anything more. And yes, the use case I had in mind actually is JAX-RS Microservices.

[mkarg]

To better illustrate what I intend with this issue, I have set up a preliminary PR #619. Inline code comments welcome! :-)

[asoldano]

@mkarg I've commented on the PR

[mkarg]

Closed by #619.