> On Jun 2, 2022, at 12:03 PM, Mark Struberg wrote:
>
> I had an idea about how we could implement CDI-4.0 without all the overhead
> it brings.
Can you elaborate on the overhead you're concerned about? (not a challenge --
I'm not very familiar with the details yet)
-David
smime.p7s
Well, about the scanning we already handle build time scanning thanks se
api (disableDiscovery + extension for explicit registration /
prescannedmetada service, this is what we use to be graal friendly).
About javax/jakarta: the whole point is to decoralate from the spec which
went in a bad
Hi Romain,
I would love to elaborate that further. I would remove the scanning part in
example (or make it pluggable). Then we could easily implement compile-time
scanning or something like that.
Maybe the core should start with a set of Beans and only do the runtime stuff.
Setup could be done
Hi Arne,
What I'm looking for is basically be able to use most of CDI programming
model (contexts, SE scanning, interceptors, ...) maybe not decorators - no
strong opinion on them.
The impl would use a default defining service which would be the
classloader implementation to be any java version
Hi,
I know, I am late to the party.
I actually like the idea of an own API and maybe adding CDI-(and/or CDI-lite)
support on top of it.
Romain, could you elaborate further, how this API should look like and what
part of our current impl could be moved into it (and which parts should be
moved
Hello,
Just noticed while doing Johnzon report that OWB is also due but nothing is
filled in.
Is it ok?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
