Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] CDI future - problems and proposal 
Hi,
I agree with Matej, this is a very good document and starts an important discussion that we totally need to have: what is CDI Lite in its entirety.
It seems rather obvious to me that the extension model needs to be different, and we've already started that discussion, but indeed there's a lot more to debate. 

Here are some of my thoughts.

On 20. 10. 20 11:42, Matej Novotny wrote:

* Bean Metadata
  You describe the need to come up with new, reflection free view of metadata that we could use.
  This is something that we already included in the draft of extension SPI because we came to a similar conclusion; see this[1] link for the model.
  I think we should note it there and point to the PR/issue so that we improve that instead of creating duplicities. We are of course open to suggestions if you see the model unfit.
I think there's an intrinsic conflict: on one hand, the desire to "do things right", including providing a new metamodel that is free from reflection; on the other hand, the desire to break compatibility as little as possible.
The Build Compatbile Extension proposal includes a new metamodel out of sheer necessity, but whether that needs to be used at runtime, I don't know. I do think that a big part of the existing runtime model can be implemented in a build-time architecture, and those places that require reflection perhaps don't have to be supported in Lite.
In general I think the population of extension writers is a lot smaller than the population of CDI users, so I'd be willing to break more on the extension front and less on the user-facing front. 


* Extensibility
  The shape of the extension interface that you came up with is a lot like phases[2] we drafted in the extension SPI PR.
  We are now working to incorporate Graeme's suggestions[3] into it so that it's annotation processor compatible so it will change one way or another.
  However, I suggest you link it in the document and we should make it a joint effort - it looks like there are now three various parties willing to make a dedicates Lite extension SPI.
  So let's try and draft one SPI that works for us all.
Tangent: I'm sorry I went silent on this front, I had some other duties, but I got back to it this week and I should be able to continue the conversation in https://github.com/Ladicek/quarkus-fork/pull/7 soon enough (today or tomorrow). 


Other notes:

* beans.xml handling
  You made beans.xml optional - how do you intend to discover beans and how do you know in which of the dependencies (JARs), do they reside?
  I'd say it's way more practical to instead have beans.xml as a marker file (== ignoring its contents) denoting that a given archive is to be searched for beans.
  That way you can further optimize which archives are to be left alone and which are to be taken into account.
  Though maybe I am just misunderstanding how you intend to perform discovery, could you please elaborate?
Bean discovery is a very interesting topic. If anything, I think we agree that we only want the "annotated" mode, and that we don't want anything like multiple bean archives :-)
The rest is ... hard. It seems to me that CDI always assumed that the container would see the entire world at once (I might be wrong about that, but at least all existing implementations do that?). But if I understand correctly, with annotation processors, you'd want to do bean discovery (and run extensions, and perhaps more) "per partes", incrementally. That's an interesting constraint and I'm pretty sure that I myself can't see all the consequences.
But requiring people to modify their JARs, otherwise beans in those JARs won't be discovered, seems a bit harsh to me. Surely there _is_ a point in time where you get to see the whole world? (Maven plugin or Gradle plugin, for example.) This would of course require operating on bytecode instead of AST, and I can see how you don't want to do that, or at least minimize that work... 


* Reduction of scope
  Do you also see some other parts of CDI going away? I can imagine some not-so-used things such as specialization being a good candidate to drop.
  And there is probably more...
I think there are features that are either seldom used and error-prone, or bad fit for build-time approach, or in retrospect shouldn't be in CDI in the first place. Things like: 

- decorators
- specialization
- session scope
- conversation scope
- passivation
- non-contextual injection
I put together a document with all of CDI APIs and whether they should or should not, in my opinion, be part of CDI Lite: 

https://docs.google.com/document/d/1jS7EbHnyBBvZZxa56LmthKeoixm2FEHmqHwITGRLljQ/edit

It should mostly match the list above.


* Extensibility
  You stated that Lite implements only the new variant of extensions (whichever that will be) and that there is an optional module for runtime extensions to add.
  So, how would this optionality work in practice? E.g. would there have to be an impl doing it all? Because I don't think either side would want to consume that implementation.
  AOT approaches would want Lite OFC, but EE servers will require the runtime impl anyway.
  And if there is such impl, it would have to have dual bean metadata - existing model + new one that we both talked about.
  That can lead to a whole lot of undefined behaviour based on which extension changes what metadata and when.
  Not to mention that performing build time extension first means you alter metadata, create synth beans and perform validation. And being at build time, you could even create proxies at this point.
  Running standard ("full") extensions after all that doesn't make much sense as you would have to re-do the whole thing... unless I am missing something.
  I don't have an answer to this situation myself, but when I was pondering this over, I didn't see much use in supporting both simultaneously.
  Can you please elaborate on how do you see the co-existence of both working?
I think the only possible way that might be realistic is to run Build Compatible Extensions at runtime, together with Portable Extensions. That is, runtime implementations would still have to be fully runtime. I think the proposed extension execution phases in Build Compatible Extensions kinda sorta match the existing lifecycle, but the devil is in the detail obviously. 

LT

Back to the top