Hello, I will try to address the comments from previous e-mails:
From Arjan Tijms: - Interceptors on programmatically created beans - I understand there should be a way to get appropriate decorated instance, that would apply all interceptors when methods are invoked on the returned instance; I think this must be handled with care with regard to the new features we discuss, as a bean computed at build time would already know about all its interceptors. Bean.create in such a case returns an already decorated instance. Why cannot this be done using extension to add an interceptor binding to the bean before it is set up? - Access to injection point in Bean#create() - Do you envision what change in API would be useful here? What is the needed (additional) metadata you want to obtain from the injection point? I guess some sort of “synthetic” injection point could be created when requesting this programmatically. Or we could add support for parameters to @Produces methods, that could be explicitly defined when invoking this...
From Matej Novotny: - Bean Metadata - there is a need for build-time processing API, but the runtime model I think should be built into the existing model in CDI to make it capable of reflection free handling, with the reflected methods being deprecated. If two models are really needed, we can work on your PR to come up with a model good for both annotation processing and byte code processing. We could have a `jakarta.cdi.lite` model for build time annotation metadata, and have the current CDI meta model extend it to add the reflection methods (that may be used in EE or existing extension and beans). - Extensibility - agreed, the extensibility model should be designed in cooperation, to make sure it works for either build time approach; I will add the link to the document. Luckily there are not three parties, we have written the document with Graeme, so we should be on the same page here - beans.xml - see below, this one is a bit longer; can you please explain how you approach this for build time and runtime in your proposal? Maybe I am missing some use case that requires a different approach - reduction of scope - this is a complicated topic, I can see problems starting with jakarta.inject (Provider should be deprecated and extend Supplier, and Supplier used instead, maybe consider adding NonBinding as it belongs to Qualifier, and I would consider some additional scopes as they make sense in general, such as Dependent and RequestScope), and jakarta.annotation-api (I have doubts about the security, sql package, ManagedBean class, Resource class - seems like a mixture of classes that are from different areas, not all of them have meaning in SE; we should also add Nullable and Nonnul annotations), there are some areas in interceptor API that may be improved, and of course the areas in the CDI spec itself. The question here is whether these should be dropped from the specification (e.g. deprecated and eventually removed), or just not part of a profile, or a combination of both - Extensibility #2: - “Lite” would only implement build-time - SE and EE would support existing portable extension - I think we should aim at providing a capability to “transform” output of a build-time extension into a portable extension; this would not work for synthetic beans created at runtime and for beans added by other portable extensions (as the build time extension would not know about them). I think we should go through a few use cases to see if this would be useful at all, or would just bring confusion - My concern - if we create “Lite” with build time extension (only), and “SE” and “EE” with portable extensions (only), we would end up with two sets of extensions for each feature (such as a “OpenTracingLite” and “OpenTracingExtension”) - this may be a good solution, I am myself not sure about it
Beans.xml and bean discovery: You (Matej) consider class path scanning is needed at build time, we were thinking about class path scanning free approach. Each archive that is a bean archive should have appropriate “META-INF/services” with a service that provides the list of beans in that archive. If done this way, there is no need for beans.xml. This of course implies that each bean archive is compiled with build-time processing. We could have a component, that would add such metadata on existing bean archives (yet I think this can be vendor specific).
How would this work? - build time of a bean archive: the processor (annotation or byte code) generates a META-INF/service/jakarta.cdi.lite.BeanDefinitionProvider with a list of (generated) implementations for each bean in the archive - build time of my application: we process the current application source (or byte code) to create the service list (either via annotation processing or byte code scanning) - run time: we read all the BeanDefinitionProvider instances and create our bean landscape from them (the bean landscape is almost fully pre-computed, may be using some conditions to limit the list of beans being loaded) - in case we want to “enhance” a bean archive that is not our application (such as adding an interceptor to an existing bean), we would use a concept of “bean import”, with a configurable way to mark classes to be re-computed and provide an alternative with higher priority than the original bean
Thanks a lot on your comments, let’s continue this conversation!
Tomas
-------- Original message -------- Date: 10/20/20 5:43 AM (GMT-05:00) Subject: Re: [cdi-dev] CDI future - problems and proposal
|
