Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] [External] : CDI Meeting 29/06/2021
I will try to answer some of these questions since the proposal is pretty much lifted from concepts in Micronaut :)

> I started calling it "bound methods", as that seems a bit more appropriate than "executable methods". All methods are executable 

So in Micronaut we have a separate interface called MethodReference that has all the metadata about a method: https://docs.micronaut.io/latest/api/io/micronaut/inject/MethodReference.html hence in this case the method isn't executable but just has information. This is like if we included methods in the current Java model API proposal, it is unlikely you would include execution there since the methods can't be executed :)

So ExecutableMethod is named such to different that it is a MethodReference that can be executed https://docs.micronaut.io/latest/api/io/micronaut/inject/ExecutableMethod.html

> I thought that invoke() takes no parameters, but here, it takes the instance

It takes the instance you can execute the method on by default. What you refer to as "bound methods" is called a MethodExecutionHandle in Micronaut https://docs.micronaut.io/latest/api/io/micronaut/inject/MethodExecutionHandle.html

That is again a separate concept but is also a valid use case.

> Could you clarify what does the "process"[1] property on Executable interface mean in practice?

So in Micronaut if you set "process" to true then Micronaut will produce an index of methods that should be processed when the application starts up. Consumers can implement an interface (which seems to have been modelled as an event in the proposal) called ExecutableMethodProcessor:

https://docs.micronaut.io/latest/api/io/micronaut/context/processor/ExecutableMethodProcessor.html

An example use case in Micronaut is for example @Scheduled which processes all methods that have job scheduling. 

https://github.com/micronaut-projects/micronaut-core/blob/e22417185d8cee2edeef736384a2eadddf7b5385/context/src/main/java/io/micronaut/scheduling/annotation/Scheduled.java#L39

Note that the ExecutableMethod is processed and the job scheduled but the bean is not created at that method hence the distinction between ExecutableMethod and MethodExecutionHandle:

https://github.com/micronaut-projects/micronaut-core/blob/e22417185d8cee2edeef736384a2eadddf7b5385/context/src/main/java/io/micronaut/scheduling/processor/ScheduledMethodProcessor.java#L91

It is also useful to be able to lazily process methods. This is the case of the HTTP methods in Micronaut which are also @Executable but not processed on startup but instead when a bean is created that uses them (such as the HTTP router):

https://github.com/micronaut-projects/micronaut-core/blob/e22417185d8cee2edeef736384a2eadddf7b5385/router/src/main/java/io/micronaut/web/router/AnnotatedMethodRouteBuilder.java#L47

In this case "process" would be "false" and it would happen only when a concrete bean is created.

How these concepts in Micronaut translate into CDI clearly interesting :)

>  if so, then the ExecutableMethod interface needs to be independent of AnnotatedMethod 

It should be independent I agree however there needs to be a way to retrieve the annotation info somehow.

> Is it intended that the only way to get hold of ExecutableMethod reference is via extension? 

In Micronaut this is not the case, they are also available as part of the bean definition API (the equivalent of the Bean interface in CDI)

Cheers


On Wed, Jun 30, 2021 at 2:16 PM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
Yea I thought I might be missing something in "producer method bean instance that is being produced". If it read "bean instance produced by the producer method", that would probably be too easy to understand :-)

LT

On Wed, Jun 30, 2021 at 2:10 PM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
Good pointer, but I think you are misreading it.
The 3rd case means that the producer method parameter (that is a dependent bean) is a dependent of the product of the producer method - of the bean it creates. In other words, that dependent bean will exist so long as does the bean created by given producer method.

On Wed, Jun 30, 2021 at 11:49 AM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
On Wed, Jun 30, 2021 at 11:39 AM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
One more notable thing - the method execution might spawn a new @Dependent bean (as a parameter of the method) - what do we do with that?
Technically this dependent bean should be scoped to the bean that it is dependent on (the bean to which the executable method belongs), but is that expected? It would mean the same instance would then be reused for several invocations up until the calling bean instance is destroyed.

I think CDI already defines this behavior for several other cases: https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#dependent_objects What seems particularly similar is the 3rd case, where an instance of a `@Dependent` bean, which is injected into a producer method, is a dependent object of the bean instance that declares the producer method (if I understand correctly -- that sentence is a little hard to read :-) ).

LT
 

On Wed, Jun 30, 2021 at 10:20 AM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
On Tue, Jun 29, 2021 at 8:48 PM Tomas Langer <tomas.langer@xxxxxxxxxx> wrote:
- Executable methods in CDI: I have created the example showing how it could be used: https://github.com/tomas-langer/cdi-exec-methods

Thanks!

From what you said on the call yesterday, I thought that invoke() takes no parameters, but here, it takes the instance on which the method should be invoked. I thought that the instance, similarly to the parameters, would be looked up from the CDI container. Would that make [more] sense?

Also, I'm not quite sure what the `Executable.process` attribute means, could you please elaborate on that?

All in all it seems like a great idea.

I know Matěj mentioned a couple of things that probably deserve explicit treatment. Here's my take on it -- in general, we should do what CDI already does in similar cases.

- What contexts are active during the method invocation? I'd expect the usual CDI rules for context propagation to apply, and nothing more (or less). This may lead to `ContextNotActiveException` when e.g. one parameter of the bound method is `@RequestScoped` and the request context is not active when `boundMethod.invoke()` is called -- but that's nothing unusual.
- Assuming that `boundMethod.invoke()` takes no parameter and looks up the instance from the CDI container, what happens when the bean is `@Dependent`? I'd expect the usual CDI rules for calling producer or observer methods on dependent beans: the bean instance is created for that single invocation and is destroyed immediately after the invocation finishes.
- When can the bound method be invoked? I'd probably expect something like "after the application is deployed", so perhaps forbid that during Portable Extension execution -- but maybe the `process` attribute has a meaning here?

(Yea sorry, I started calling it "bound methods", as that seems a bit more appropriate than "executable methods". All methods are executable :-) )

LT
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev


--
Graeme Rocher

Back to the top