Provide an annotation to supply opaque data during participant registration

[mmusgrov]

The client API for participants to join an LRA includes a method parameter that the caller may optionally use to supply [https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/client/LRAClient.java#L301](opaque data) that will be provided back to the participant when its compensation/completion method is subsequently triggered. There is no corresponding facility in the Java annotations used for registering participants.

The proposal is to include an annotation that annotation based participants can use to register the equivalent data.

Please refer to the section of the spec that describes [https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asciidoc/microprofile-lra-spec.adoc#322-compensating-activities](participant registration) and the javadoc for the annotation - for example [https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/annotation/Compensate.java#L42](the @compensate annotation).

Note that reliable participants may wish to manage there own data by durably recording which LRAs the are participating in. However this git issue makes it easier to write reliable participants.

[mmusgrov]

@tomjenkinson There is a problem with providing an annotation for spec implementations to call to get the extra data via an annotation which makes this issue invalid for the following reason:

if a JAX-RS method has an @lra annotation then the implementation must register the participant before invoking the method. But the participant may only know which data he wants to associate with the join request during the method call which is too late.

I propose that we reject this issue and add a spec note to say that the feature is only available in the LRAClient API..

[tomjenkinson]

I think that the specification could be expressed in a manner to cover that case by saying the @LRAData method is called during the @lra method and that it is expected that business logic is called exactly once by the implementation. You are expected to prepare the compensation data during @LRAData.

[tomjenkinson]

It would need to return a String to match the LRA Client API

[tomjenkinson]

The @LRAData method needs at least access to the LRA ID in order that @ApplicationScoped JAX-RS resource can refer to it from a map

[tomjenkinson]

The business logic should not be making changes that require @compensate or @confirm to be called.

[tomjenkinson]

@ParticipantData not @LRAData

[mmusgrov]

Can we move this issue back to milestone 1. We have had two queries about it from the community so I think it is a big issue for them to have to manage their own durability requirements. - we used to have an implementation of it so it will be simple to add back in.

[rdebusscher]

@mmusgrov We have left it out due to the fact that we have postponed the LRAClient API.

Can we have opaque user data with annotations only?

[xstefank]

@rdebusscher there is a proposal in above discussion discussing adding annotation @ParticipantData

[rdebusscher]

Enum can only take constants. And within MicroProfile we do not have access to EL expressions to have some Participant Data which are dependent on the request.

Or is it the idea to annotate a method parameter with @ParticipantData which becomes then the Opaque Data?

[xstefank]

IIRC it would be a separate method annotated with @ParticipantData which only returns the opaque data and will be invoked once when the LRA is starting (when someone invokes some other method which is annotated by @LRA)

[rdebusscher]

And how is the link of this additional method annotated with @ParticipantData with the JAX-RS called method (like the request parameters, headers, ...)

Can you give a small example?

[xstefank]

I am guessing, but when you are starting LRA in our case it's a container request filter, so we can scan the rest of the method in the resource class and check dynamically for @ParticipantData annotation and invoke it from the filter.

However, I don't think this is the only solution to this problem. Personally I can also see an option similar to Fallback annotation from Fault Tolerance, when you can specify method name or class name (of class implementing spec interface) in the LRA annotation itself which gets invoked when LRA is starting. This would allow implementations to avoid scanning all resource methods and checking for data annotation.

EDIT: sorry, after second read, I see that is not what you were asking. Passing parameters from @LRA method to data method can be done in the filter as it has access to the requestContext which can be basically passed to the data method if needed I think.

The only issue I can see now is on which instance of the resource class should the data method be invoked. Can we mandate that JAX-RS resource method is always a CDI bean so the instance can be retrieved programmatically?