Move the Java Client API to milestone 1.1

[mmusgrov]

MP LRA is a CDI first project and we have quickly agreed on the right set of annotations to drive the specification.

The goal of the client API is to provide a programmatic equivalent to the annotations and we are still discussing the best form that this API should take.

The impression we have from external communities is that LRA is a complex and potentially difficult specification to implement and anything we can do to simplify it will aid its acceptance and take up.

Given that LRA is a CDI first project and that the programmatic API is equivalent to the annotations I question why we need it. The original motivation came from a member of the Camel community who did not wish to use annotations. However, since we plan to address interoperability in milestone 1.1 as a set of REST endpoints this will meet that communities needs and the Java API will then become redundant.

I therefore would like to move the provision of a Java client API to be a discussion item for milestone 1.1. This will enable the group to fully concentrate on the "CDI first" approach to the specification and will give us a better chance of agreeing (both internally and more broadly within the MP community) on what should comprise the initial version of the specification.

[tomjenkinson]

+1

[xstefank]

This concerns LRAClient or LRAManagement or both?

[mmusgrov]

It does not apply to your issue #88 but yes, it does apply to both LRAClient and LRAManagement.

[xstefank]

Currently annotations apply only to JAX-RS resources not any CDI beans. I believe LRAClient was added because of this purpose but I wasn't participating in the spec when this decision has been made. LRAManagement functionality can be covered in LRAClient I believe.

[mmusgrov]

@xstefank So do you agree we should move more slowly and defer the discussion of the programmatic API until 1.1?

[mmusgrov]

I will add it to Monday's agenda.

[xstefank]

then we will not be CDI first project. If we are CDI then we should require that annotations work on any CDI bean (if it is possible to implement). So I am not really sure if we want to drop LRAClient interface as this is what the users can use in CDI right now.

[mmusgrov]

Perhaps I am using the wrong terminology but when I say CDI first I mean driven by the annotations.

The programmatic API duplicates the behaviour provided by the annotations. The latter is the primary focus of the specification and the former merely duplicates the functionality provided by those annotations.

As I stated in the issue description my goal is to simplify the project and stay with just the annotations for the initial release. We can revisit things like interop and the programmatic API in a subsequent release. My concern is that we are moving too slowly and the discussions around the Java programmatic API have taken up the majority of our time to the detriment of the spec overall. Since the Java API is not adding anything extra over and above what the annotations provide, we need to be pragmatic and reduce the scope of our work deferring the extra stuff to later.

[mmusgrov]

We could switch to moving @lra to be a CDI annotation (note that @compensate and @complete are no longer tied to JAX-RS) but I wanted this to be a project for services to be able to propagate a transaction context and JAX-RS resources was the natural mechanism to do that.

[tomjenkinson]

I had the same understanding as Mike. Injecting LRAClient is not really as much CDI as it is raw injection.

TBH I thought @lra was a CDI annotation...

[mmusgrov]

When JAX-RS was created CDI wasn't available in the Java SE so they are different. But there appears to be a plan to deprecate JAX-RS annotations in favour of making them pure CDI ones: jakartaee/rest#569

[xstefank]

OK, I agree that this is possibly a good idea and something I was already thinking about previously. If we take similar approach as for instance MP Fault Tolerance we can make all LRA annotations interceptor bindings so they are usable in any CDI bean, it will still work for JAX-RS resources as long as they are also CDI beans - most containers already do this by default I think. So I think I can +1 this if no one brings better reason why not to do it :)

[mmusgrov]

Do we really want to be changing @lra from a JAX-RS annotation to CDI interceptor at this late stage of the project plus that was already discussed in the sandbox and we agreed to go with JAX-RS annotations. If the group does vote for that it must be in a 1.x milestone.

[xstefank]

I may still have in mind CDI first project. But if you mean by it annotations driven as per previous comment you are right we can stick to JAX-RS only. But this is decision for the community. We should add this to hangout agenda.

[mmusgrov]

You are being quite contrary, I raised this issue to reduce the scope of the work we have to do and now you want to widen the scope again. We already discussed JAX-RS versus CDI interceptors in the sandbox and decided on JAX-RS and I do not want to revisit it now. I already said in my last comment that if the community want to resurrect this discussion then it is a 1.x milestone and therefore is not a topic for discussion until the first release is out.

[xstefank]

You are right. I was just pointing out differences. We can say in the spec that annotations are JAX-RS specific.

[mmusgrov]

The spec says:

The life cycle of an LRA is controlled via the LRA annotation (@lra).
The annotation SHOULD be applied to JAX-RS annotated methods otherwise it MAY have no effect.