eclipse/microprofile-sandbox

microprofile-sandbox's Issues

More detail on MicroProfile Working Group Proposal

Is there more detail the group can add to the doc? Some things like "Decisions are “lazy consensus” by default" could use specifics.

concurrency: support context propagator SPI

In order for mp-concurrency to replace Reactive Contexts which is currently used by RESTEasy to provide context propagation, it would be very useful if there could be an SPI to declare custom context propagators.

For example, RxJava 1 and 2 both support a plugin system where it is relatively easy to implement automatic context propagation with a context API such as mp-concurrency and Reactive Contexts.

Supporting an SPI for context propagators is as simple as defining an interface with a single setup method, and an entry in META-INF/services to declare implementations.

With this in hand, mp-concurrency could provide two optional dependencies that provide implementations that hook into RxJava 1 and 2 in order to use mp-concurrency context propagation to propagate contexts automatically to all RxJava pipelines, rather than require users to implement it themselves or depend on a third-party library.

@NestedLRA instead of @LRA?

Why have a different annotation for nested LRAs (@NestedLRA)? Surely from a modularity perspective it would be better to just use @lra and if there's an LRA associated with the thread/unit-of-work when it encounters another @lra then it is automatically nested? Then a developer doesn't have to worry about nesting and code can be moved seamlessly between applications and scopes without having to be modified.

Also what happens if an LRA isn't active when @NestedLRA is called?

Add "deprecationReason" in ... #GraphQL

Add deprecationReason in
@type
@inputType
@field
@inputfield

I think it's equally relevant on these annotations than on @query.

Update spec draft according to change made (if approved by majority) #GraphQL

Changes:

• Put a "value" field in every annotations.
• Merging Type and FieldsOrder annotations.
• Merging InputType and InputFieldsOrder annotations.
• Adding deprecationReason in:
  @type
  @inputType
  @field
  @inputfield

Basic readme needed for sandbox concurrency spec

The concurrency spec needs a basic readme like the other specs in the MicroProfile sandbox

concurrency: add SPI for context providers

In order for mp-concurrency to replace Reactive Contexts which is currently used by RESTEasy to provide context propagation, we need to be able to define context providers via an SPI. Otherwise, context providers would be a fixed list and not support contexts that are external to MP/EE.

This can be as simple as defining a ContextProvider interface which supports:

• capturing a context
• setting a context
• restoring a context (in RESTEasy setting and restoring are different operations because the context is a stack with push/pop)

Where "the context" can be an opaque type that nobody outside of the context provider cares about (a type parameter would do).

Implementations of the ContextProvider can be listed with a META-INF/services file.

initial interfaces for microprofile concurrency

After some discussion on the mailing list, we came up with an initial set of interfaces for a Microprofile Concurrency spec that will improve the ability to use CompletableFutures in managed environments. This issue will add them to a Microprofile Concurrency project in the sandbox.

Changes provided under pull #11

Remove LRA files from the sandbox

The LRA project (and the commits made to this repo) has moved to https://github.com/eclipse/microprofile-lra so, apart from the README, the related files need to be deleted.

Create the API annotations #GraphQL

Could not add the GraphQL label :(

Remove microprofile-sandbox/proposals/streams

If James is happy with it I will remove the folder at
https://github.com/eclipse/microprofile-sandbox/tree/master/proposals/streams

as Jame's vision became:
https://download.eclipse.org/microprofile/microprofile-reactive-messaging-1.0-RC1/

and we want to tidy up the sandbox.

I will drop a tag to record a commit where it is present.

@jroper are you OK with this?

Annotation descriptions are inconsistent for LRA

With reference to https://github.com/eclipse/microprofile-sandbox/tree/master/proposals/0009-LRA#java-annotations-for-lras

The doc spends over a page showing the @lra annotation with examples but then only talks about how the other annotations, such as @compensate, are used. For consistency and so someone can see precisely what annotations are being introduced, I suggest putting in as much detail for these other annotations as there is for @lra.

Create GraphQL README

Phillip Kruger is planning to move the proposal document into the README file (currently MD, but can be converted to AsciiDoc).
https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit#

concurrency: support `ThreadContext` lookup without CDI

In order for mp-concurrency to replace Reactive Contexts which is currently used by RESTEasy to provide context propagation, I suspect we will need to be able to obtain a TreadContext implementation without CDI, because RESTEasy-core does not depend on CDI.

Keeping the dependencies of mp-concurrency would allow it to be more broadly used. A CDI implementation could be provided as an optional dependency.

Define JWT bridge spec final name

As discussed in the last MicroProfile JWT and Jakarta Security Interlock Call on 6th of July, I think we need to define a final name for the new standalone spec, called jwt-bridge currently.

The current working name has some limitations, as it not defining the component specs scope clearly and inconsistencies just starting:

• Proposal name: jwt-bridge
• README.adoc headline: MicroProfile JWT Integration
• Spec document file name: microprofile-jwt-integration-spec.asciidoc
• Spec document headline: Eclipse MicroProfile Interoperable JWT RBAC

To prevent naming inconsistencies right from the beginning (as in MP JWT *) and that spec names a part of the Creation Review EF IP check, this need to be solved before the CR.
As changing names afterwards is confusing and a breaking change in almost all cases, we need to prevent it where possible.

So the goal is to agree on a short, self-explaining final name for this new component spec, that also reflects it's scope!
When found, we can create a PR to update existing names and then start the CR.

Disclaimer: Solving naming issues in the current MP JWT * spec is out of scope of this issue - this will be discussed here.

During the meeting we collected a list of potential names:

• Jan: MP JWT Web Profile
• Jan: MP JWT Web
• Werner: MP JWT Jakarta Bridge
• John, Majid: MP JWT Bridge
• Michael, Jan: MP JWT Security
• Majid: MP JWT Security Core

There was also discussion about being clearer in the scope by adding Jakarta (MP JWT Jakarta Security or MP JWT Jakarta Web) and allowed use of Jakarta inside a MP spec on the other hand.

Paul Buck is offering helping out the last from the EF side in the last MP Community Call on 11th of July.

We decided to get additional community input, discuss the name on the next interlock call on the 20th of July and finalize the name until the 25th of July to not delay the Creation Review.

I hope we can agree on a name in consensus, but the wider community discussion is open on this now!

As multiple different communities involved here, please try to add comments on this GitHub issue instead of creating a parallel thread on a (single) mailing list - not everybody has access configured to all lists.
However, if email is preferred, then use the [email protected] mailing list please.

Support JAR-based deployment without container

So far the microprofile like JEE have focus on container-based deployment. But with the general trend in the direction of microservices and orchestration platforms like kubernetes, there is not much use left for container architectures. Barely two applications get deployed within the same JVM process and as such there is no need to introduce a container layer between the orchestration infastructure and the application. This not only simplifies the architecture of the application, but also starts to enable much more simpler unit testing without having to (externally) launch the container or rely on technologies like Arquillian. A CDI Test Runner like Deltaspike could take care of testing in such an environment.

What would be needed by a microprofile vendor is a JAR for each specification (servlet engine, JAXRS, health, etc.). Application are then free to choose which features of microprofile to use. Currently lacking in specification is a configuration mechanism for the various parts of the application and an API to manage the http server/servlet engine.

the move would align with Java9/Jigsaw. Possibly would allow the use of AoT in the future. And vendors could, for example, further opt for a https://google.github.io/dagger/ CDI implementation that would move many of the preprocessing step of a tradition start into the compile phase, making applications more lightweight and faster to boot, while catching more errors at compile-time. This probably would also align quite well with projectfn and other projects in the area, as microprofile would gain the necessary speed to launch very quickly.

concurrency: support per-application SPI providers

In order for mp-concurrency to replace Reactive Contexts which is currently used by RESTEasy to provide context propagation, further to #16 we need to be able to declare providers per application, and not just globally.

When integrating Reactive Contexts in RESTEasy we noticed that in WildFly we had issues because it uses a modular class loader (JBoss Modules) and supports multiple independent deployments of applications.

In this particular case the WildFly distrib was loaded with RESTEasy and Reactive Contexts, and then we had two independent user applications (two .war files) that each had their own sets of context providers.

Having a global list of context providers held as a static variable did not work: we needed to have a per-deployment list of context providers.

On deployment, RESTEasy instantiates a new Reactive Contexts subsystem, and stores it in a thread-local (the assumption being that every RESTEasy deployment is tied initially to a separate thread). From there, every thread which serves RESTEasy request has that thread-local propagated and it is used to look up the set of context providers that participate in context propagation.

Update sandbox concurrency spec with SPI and config

Add the proposed SPI and config annotations to the MicroProfile Concurrency sandbox