Ladislav Thon

I was able to build a proof of concept. Here's how the outcome looks like: https://ladicek.github.io/cdi-tck/#legal_bean_types The proof of concept code itself is here: https://github.com/Ladicek/specref The required changes to CDI...

@starksm64 I used the `io.smallrye` package name, because I thought that's where we would put it, but I _didn't_ make this official in any way yet. So no, there's nothing...

Also we probably should have 2 variants of the same test -- one for context registered through BCExtension, and another one for context registered through PExtension.

This is only meant for manual usage, right? Because I _think_ if you just do `mvn clean install`, the root module will be built first and hence won't produce anything,...

+1 from me. I actually expected to find a provision in the CDI specification saying that observer methods must be declared `void` and was surprised that I didn't -- even...

The specific context we had in mind is programmers declaring asynchronous observers that return `CompletionStage` or similar asynchronous types. To a lot of users, that gives the impression that the...

That's a very creative combination of interceptors and observers indeed. The specification says that observer method invocations are business method invocations and hence are intercepted, so it seems perfectly valid.

I'm closing this and removing from the 4.1/5.0 milestone. I'm fairly convinced we agreed that we won't pursue this, because this _absence of observer method return type validation_ has likely...

I assume the problem with case b) is that you can potentially call `activate`/`deactivate` on the same RCC multiple times. That is solved by using a flag, similarly to case...

I'd say that even the `try`/`finally` way of using RCC should be paired with a flag -- unless you're absolutely sure your method can't possibly be called recursively. I believe...