Discovery of JAX-RS resources in MicroProfile

NottyCode commented 6 years ago

There was an issue raised against the Open API TCK to resolve how JAX-RS resources get discovered. The issue was closed with a reference to issue #32 based on a discussion on the hangout. I wasn't on the hangout, but reading issue 32 I'm concerned that this issue might be lost so I'm raising this to specifically cover it.

The example sited from section 11.2 of the JAX-RS specification is incomplete for how CDI discovery works, so perhaps the MicroProfile spec could provide a modern and complete example.

rmannibucau commented 5 years ago

You should read messages so let me repeat:

breaking changes cant affect any element of the stack which has its own ecosystem or you break that ecosystem which is very highly a blocker for users
it is good to be thread safe by default and it is ee default for years....this is not app scope though
it is fine we disagree but you opinion does not repredent the majority if you read that thread so community disagree with you for now

struberg commented 5 years ago

Oh gosh, @kenfinnigan this sentence might be very controversial:

MicroProfile is planning to break backwards compatibility once a year,

We are fine to break backwards compatibility with our OWN specs. But we certainly will not break backward compatibility with official EE specs we refer to. At least that is my understanding. Feel free to bring this up to our next mp hangout agenda.

kenfinnigan commented 5 years ago

@rmannibucau, I don't see why breaking changes can't affect any element of the stack. That's precisely why they're called breaking changes. Furthermore, if we're not going to accept any breaking changes and stick with what's been done before, then MicroProfile might as well close up shop and merge with JakartaEE. The whole point of MicroProfile is to push the envelope faster than Java EE could before, sticking with what works doesn't fit that mandate in my view.

I never said my opinion represented the majority, I'm merely trying to open a discussion about whether we want to make such a change. Conversely, I wouldn't consider the few people who have commented here as creating a majority for your opinion either.

@struberg, well it's what we've decided to date, that there could be a breaking change release every year. Doesn't mean to say there will be, but we're planning for one a year.

I wouldn't consider the change I've been describing as breaking either the CDI or JAX-RS specifications. I consider it to be clearly defining behavior between those two specifications when executing in a MicroProfile environment.

rmannibucau commented 5 years ago

@kenfinnigan right, since now JakartaEE is @ eclipse then no more need of microprofile umbrella anymore. Personally I really hope it will bring more CDI-friendly API (vs copy of SE API). Anyway, your change is breaking user code since today it is spec-ed as request scoped (whatever derived it is - proxied or not using @dependent) and therefore the bean does not have to handle any concurrency and you change would break that game and break jwt-auth injections (+ jaxrs params injection as it has been mentionned). So yes it is a big breaking change which shouldn't even enable to pass MP tck strictly speaking - I didn't check if there were covering on that point but since it is in the spec it should.

struberg commented 5 years ago

@kenfinnigan I attend the mp meetings as well. We decided that we can break OUR apis once a year. And also only if needed! There is a difference between evolving our stuff and breaking other stuff.

kenfinnigan commented 5 years ago

@rmannibucau I don't believe such a change would break any TCK. MicroProfile does not require passing the CDI or JAX-RS TCKs.

@struberg for sure it's not guaranteed to happen every year, but initially I could see that being the case is things are still evolving rapidly. In my view MicroProfile doesn't need to be compatible with Java EE applications today. My reason for that is because we just end up in a situation where no progress or advancements are made if we don't say "something needs to change".

Now I'm absolutely not saying the change I'm proposing has to be that change to break things, but we at least need to be prepared to make those decisions otherwise we become stale.

rmannibucau commented 5 years ago

@kenfinnigan I agree sometimes you must break things. Typically that MP state that anything outside CDI is not supported where JAX-RS has a SE mode would make sense but being based on CDI I strongly think MP can't go against its defaults.

konbk commented 4 years ago

Hi, heavy WildFly user here,

@kenfinnigan, As I understand, you would like MicroProfile to specify different behavior than that already defined in Java EE/Jakarta EE for resources without any scope annotations. Currently, JAX-RS resources in WildFly are not CDI beans by default but behave mostly like request scoped beans. WildFly successfully implements Java EE/Jakarta EE and MicroProfile. But after the proposed change, how do you imagine WildFly implementing two contradicting specifications at the same time?

arjantijms commented 3 years ago

But after the proposed change, how do you imagine WildFly implementing two contradicting specifications at the same time?

Did anyone ever take this question into account? I'm curious about that too, and since in Piranha we implement both EE and MP I may face this exact same problem. @kenfinnigan any thoughts on this?

kenfinnigan commented 3 years ago

I don't believe it's been looked into, but I could imagine it behaves differently depending on the type of application.

By that I mean, as soon as MP dependencies are included, JAX-RS scope would switch to MP desired behavior

ederks85 commented 3 years ago

As an end user, I’m not sure that I like where this is going for implementations that implement both Jakarta EE and MicroProfile. And there we can even distinguish between implementations that support both, and are compatible with both.

It feels to me that this behavior contradicts the very vision both platforms are based upon. However, maybe it’s actually a good move as long as we can keep it understandable by defining the scenarios or profiles or whatever helps.

At least I hope that anybody agrees that if we take a route like Ken suggested, it will be the first where as an end user, you need to start thinking about how to use Jakarta EE and MP, instead of just going along with it.

I’m not pretending to have the answers right now, but just my two cents for now.

Edwin

On Mon, 14 Dec 2020 at 02:42, Ken Finnigan notifications@github.com wrote:

I don't believe it's been looked into, but I could imagine it behaves differently depending on the type of application.

By that I mean, as soon as MP dependencies are included, JAX-RS scope would switch to MP desired behavior

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/eclipse/microprofile/issues/50#issuecomment-744115719, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAPLV3TL3BBEKL3SISHOCDSUVUOXANCNFSM4FKVQW3A .

Emily-Jiang commented 3 years ago

Nothing right now blocks end users if you stick with Jakarta EE spec.

In order to enable your application compatible, stick to what Jakarta EE platform spec defined and don't use some additional features provided by some runtime, why means:

Annotate explicitly with CDI bean defining annotation on your JAX-RS resources, such as RequestScoped etc.

If you don't use CDI annotation and you have beans.xml, the resources will be defaulted to Dependent Scoped. Anything else you will run into the defined behaviour by different runtime. Jakarta EE platform spec said very clearly:

Only CDI-managed JAX-RS resources supports injection and interceptors, which means you need to explicitly make JAX-RS resources to be CDI beans via bean-defining annotations or beans.xml.

In the future JAX-RS spec, it might be better to update @Path to automatically be a bean defining annotations with the similar behaviour of RequestScoped. In this case, there won't be any ambiguity.

rmannibucau commented 3 years ago

@Emily-Jiang not sure where the Only CDI-managed JAX-RS resources supports injection and interceptors, which means you need to explicitly make JAX-RS resources to be CDI beans via bean-defining annotations or beans.xml. comes from but it is clearly not the case in Jakarta due to EJB, war etc specifications and TCK. Overall point is that any microprofile specification can only rely on CDI discovery, so only CDI beans can be JAX-RS resources by construction - anything else is vendor dependent which is fine but not usable by the specs. Maybe @Path defining means CDI would know about JAX-RS which is not an option if we want things to stay simple, clear and usable (why would we duplicate discovery in 2 spec, in particular when one rely on the other). So at the end Microprofile only defines CDI for the discovery, in an EE container it can be defined as such (Microprofile integration will only be active for CDI beans, including EJB) and we are good. All other options are broken at some point and will need to fork Microprofile way more than needed for what it does IMHO.

Emily-Jiang commented 3 years ago

@rmannibucau see here , quoted from Java EE8 platform spec doc I did not argue about the CDI discovery. If you re-read my earlier comments again, I mentioned CDI bean-defining annotation or beans.xml, which covers the ground of CDI discovering all beans.

rmannibucau commented 3 years ago

@Emily-Jiang this document is highly likely wrongly phrased since any web component must support EE injections for current deployment (whatever it is for the app, either CDI or actual EE as @Resource/@EJB) and also support EJB which have its enriched injection set too. This is in TCK as well so guess it is an "unlucky" phrasing/note. Now, the overall point of this ticket - and original one to be very concrete - was to write in microprofile spec:

Microprofile implementation are only required to support CDI discovery
EE vendors (or other vendors) can extend that to EE discovery mecanism - including vendor specific ones - but it is outside of the scope of Microprofile to define those
bis: note that it includes GraalVM build time discoveries which bypasses CDI extensions at runtime - but once again it is outside of the scope of MP
probably write that CDI discovery can depend on Microprofile container since there is nothing done at Microprofile on that area today. Concretely it means a servlet based CDI container will use web discovery (with WEB-INF/beans.xml support to give an example of a specific difference you can encounter), a CDI SE based container will use SeContainer discovery etc...

Side note: I'm not asking to define 3 in MP since it already belongs to CDI and there is no real point aligning it between vendors since user knows in which context he is and it does not impact the code at all. It is just about being clear of what is in the scope of the spec and what is not + clearly define how user code is discovered (issue being: not scanned/discovered code it silently ignored which is surprising and sometimes hard to debug for end users).

Hope it makes more sense this way.

Emily-Jiang commented 3 years ago

@Emily-Jiang this document is highly likely wrongly phrased since any web component must support EE injections for current deployment (whatever it is for the app, either CDI or actual EE as @Resource/@EJB) and also support EJB which have its enriched injection set too. This is in TCK as well so guess it is an "unlucky" phrasing/note.

I disagree with the above statement. End users relies on the Java EE/Jakarta EE spec to develop their applications. If you think the spec is wrong, the right approach is to raise an issue to get it corrected. From my understanding, the spec stated very clearly. Each Java EE component classes have the different requirements, so there was further clarification below the table.

Now, the overall point of this ticket - and original one to be very concrete - was to write in microprofile spec:
1. Microprofile implementation are only required to support CDI discovery

2. EE vendors (or other vendors) can extend that to EE discovery mecanism - including vendor specific ones - but it is outside of the scope of Microprofile to define those

3. bis: note that it includes GraalVM build time discoveries which bypasses CDI extensions at runtime - but once again it is outside of the scope of MP

4. probably write that CDI discovery can depend on Microprofile container since there is nothing done at Microprofile on that area today. Concretely it means a servlet based CDI container will use web discovery (with WEB-INF/beans.xml support to give an example of a specific difference you can encounter), a CDI SE based container will use SeContainer discovery etc...
Side note: I'm not asking to define 3 in MP since it already belongs to CDI and there is no real point aligning it between vendors since user knows in which context he is and it does not impact the code at all. It is just about being clear of what is in the scope of the spec and what is not + clearly define how user code is discovered (issue being: not scanned/discovered code it silently ignored which is surprising and sometimes hard to debug for end users).

Hope it makes more sense this way.

My take is that it is best for JAX-RS spec to fix this. I searched JAX-RS issues and found this issue is exactly what needed. I suggeset to close this very issue in MP and pursuit a fix from JAX-RS because JAX-RS is under active development. In my view, it is wrong to define a behaviour for Jakarta EE as this will lead to problems in the long run since Jakarta EE specs do not reside in MP and it might define a complete different behaviour.

rmannibucau commented 3 years ago

@Emily-Jiang

I disagree with the above statement.

Sadly there is nothing to agree or disagree, factually EE does not do what you write - take any container from liberty to tomee without forgetting wildfly and friends. It is also in the EE spec as well (from TCK to PDF/textual specs). Don't forget you use "CDI => injection" but you don't have the "Not CDI => x" part of the statement which is covered by the specs and does what I described.

So back to the point that for microprofile only CDI model exists, EE model is possible but out of official support - until EE integrated MP which is unlikely by design.

My take is that it is best for JAX-RS spec to fix this.

Here again it is just not possible without JAX-RS integrating MP which is by design not possible and not desired. The issue is "what is a bean for the spec" and since the spec can only rely on CDI as an IoC (= what sees beans/model) then the spec can only explicitly define what is supported for CDI, nothing to discuss there again. Once again it does not prevent any larger/enhanced support, it is just defining what is the spec about and what does mean portability for the spec.

Also note that the issue you mention - https://github.com/eclipse-ee4j/jaxrs-api/issues/556 - does not solve that issue at all, it is only for one particular case where you don't have a beans.xml which is not more common than the case you have one or the case you have one with trimming enabled etc...All these cases are covered by CDI so MP relies on CDI scanning for all its specs, including the ones using JAX-RS. It is by construction and complies with all vendors until you abuse the wording testing a EE bean (but not a CDI bean) is ignored - which shouldn't be tested, it should be let to vendors to decide. However, if a bean is a CDI bean and is not vetoed then it is taken into account by MP platform (CDI => MP is aware of it, anything else => vendor specific).

This enables EE and CDI to work together properly in all cases and all platform. Last note on that integration is that EE app not using CDI are legacy, must be MP "integrable" - to add metrics, tracing etc in a vendor fashion - but there is no point defining anything else at MP level except making the platform inconsistent as explained in the previous ticket and broken by a very fragile definition - note that EE has this issue already between spec duplicating the IoC in pre-CDI times. This is why, since MP has a native and natural definition of the discovery MP should just stick with it and not try to either not do its job - defining explicitly it - or do more - defining EE.

eclipse / microprofile

Discovery of JAX-RS resources in MicroProfile #50