The way @Inject works is not specified in 330, and it's better to
leave
it like this, otherwise we will loose Spring and Guice as implementations.
Yes, it's not. I'm afraid I'm lost in translation then. I will have to
read the thread again ;-)
Antonio
On Mon, Aug 31, 2015 at 10:11 AM, Martin Kouba <mkouba(a)redhat.com
<mailto:mkouba@redhat.com>> wrote:
Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a):
I don't see Events in a "Lite" version because the other DI
frameworks
don't use them. A "fatter" 330 with producers, programmatic
lookup and
bootstrap, could be "easily" implemented by Spring, Guice... If
we leave
events in a Lite version, then it won't be the case, and Weld
and OWB
will be the only two implementations.
For me, a Lite version would just be about DI. If Weld uses events
internally to archieve basic DI, well, it's just an implementation
decision, not a spec. I would not even try to standardize the way
@Inject works (like Romain said, @Inject doesn't work the same
in Weld
or Spring), let's leave it like this.
If you don't standardize how @Inject works then what's the purpose
of having something like CDI Lite and many implementations which
work differently? A user of implementation "A" will not be able to
switch to implementation "B" easily. And that's one of the most
important benefits of standardization...
If you take back Antoine sentence
"/This would allow using CDI in constrained environment like
mobile or
embedded devices/", then I don't think events would fit here.
Antonio
On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg
<struberg(a)yahoo.de <mailto:struberg@yahoo.de>
<mailto:struberg@yahoo.de <mailto:struberg@yahoo.de>>> wrote:
> For me, a Light version of CDI is clearly the features
number. That's why I don't see events in it.
We did discuss this last year on the f2f meeting. The
problem lies
within our Extension mechanism. Without events you also
need to drop
the Extension mechanism. And to be honest, this is THE
major hit in
all CDI…
Sorry to be the bad guy busting all those ideas. I really
don’t want
to, but better now than too late down the road ;)
It’s really tricky as many features are heavily based on
each other.
E.g. by removing scanning you could get rid of
javassist/asm/etc ?
nope, we also have our class proxies which need bytecode
tinkering.
So remove interceptors and decorators too? Well yea, but we
still
have normalscoping -> what is left? basically spring
prototype and
singleton. Hmm. that’s not that much compared to full CDI.
And all
that for only 200kByte?
(Btw we also discussed generating the bytecode classes at build
time, but then we still miss the dynamics we get from
Extensions,
e.g. PAT adding an interceptor annotation)
Just to give you a rough idea how this all works together
when it
comes to implementation details…
Please feel free to ask Jozef and me for further infos on
‚dependencies‘.
LieGrue,
strub
> Am 30.08.2015 um 18:09 schrieb Antonio Goncalves
<antonio.goncalves(a)gmail.com
<mailto:antonio.goncalves@gmail.com>
<mailto:antonio.goncalves@gmail.com
<mailto:antonio.goncalves@gmail.com>>>:
>
> For me, a Light version of CDI is clearly the features
number.
That's why I don't see events in it.
>
> For me, a CDI Lite would just focus on DI. If CDI has
@Produces
and Spring has @Bean, then it's because 330 lakes this
functionality.
>
> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>
<mailto:rmannibucau@gmail.com <mailto:rmannibucau@gmail.com>>>
wrote:
> Lite can have several definition, let's try to list them
up if it
can help:
>
> - binary size: for me until 3M for an app it is "Lite"
> - features number: the whole IoC set of feature is light
since
you almost always need it, it means you can do lighter but it
wouldnt be used - check spring, who uses only spring-ioc
and not
context or more?
> - features complexity: sure we are not light here but
supporting
scopes already breaks "Lite-ness" IMO so not a real issue
>
> So my view is CDI "SE" is light enough - as a spec and
spec can't
affect implementations so seems the fight is not on the
right side
to me.
>
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>
> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves
<antonio.goncalves(a)gmail.com
<mailto:antonio.goncalves@gmail.com>
<mailto:antonio.goncalves@gmail.com
<mailto:antonio.goncalves@gmail.com>>>:
> It's funny, I feel I'm in Rod Johnson shoes back in Java
EE 6
where he forked 330 because he found CDI was doing too
much ;o)
>
> For me, "CDI Lite" was just basic dependency injection.
The fact
that CDI can now run on SE (like JPA....), is good... but
for me it
has nothing to do with Light : it's the entire thing that can
bootstrap in SE. Good.
>
> So what is Lite for you guys ?
>
> Antonio
>
> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>
<mailto:rmannibucau@gmail.com <mailto:rmannibucau@gmail.com>>>
wrote:
> 2015-08-30 15:22 GMT+02:00 John D. Ament
<john.d.ament(a)gmail.com <mailto:john.d.ament@gmail.com>
<mailto:john.d.ament@gmail.com
<mailto:john.d.ament@gmail.com>>>:
> Personally, I'm not in favor of a slimmed down runtime.
It was
tried with EJB, but never implemented properly (most
implementations
that support EJB-lite actually support the entire thing,
except for
deprecated stuff).
>
>
> +1, most of CDI is basic and quickly any light version
will miss
events or other thing - in particular in maintaining micro
services
from experience. Size of an implementation can easily be <
1M so not
sure it would bring anything. Only important point is what
Antoine
started to do ie ensuring EE and SE parts are clearly
identified and
split in the spec.
>
> I think if we define SE properly we won't have a need
for this.
>
> John
>
> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves
<antonio.goncalves(a)gmail.com
<mailto:antonio.goncalves@gmail.com>
<mailto:antonio.goncalves@gmail.com
<mailto:antonio.goncalves@gmail.com>>>
wrote:
> @Antoine, so which content do you see in CDI Lite ? Are
you sure
about events ?
>
> I'm in favor of a "fatter" 330 that would have :
> • @Inject : already there
> • @Qualifier : already there
> • Producers and disposers
> • Programatic lookup
> • Java SE Bootstrap
> When you say "The goal here is not to propose a new EE
profile
but a subspec", 330 could already be seen as a subspec. If
you put
events apparts, what would be missing in this list in your
point of
view ? And what obstacles do you see in archieving this ?
>
> To boostrap CDI we have a CDIProvider, why not having an
InjectionProvider just to bootstrap 330 (then, CDIProvider
could
extend InjectionProvider, so it bootstraps the all thing) ?
>
> Antonio
>
> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand
<antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>
<mailto:antoine@sabot-durand.net
<mailto:antoine@sabot-durand.net>>> wrote:
> Yes Arjan, I think it's the first reason. We really
should work
with them to understand what should be added to CDI 2.0 to
have it
as a first citizen DI in their spec.
>
> Le sam. 29 août 2015 à 23:15, arjan tijms
<arjan.tijms(a)gmail.com <mailto:arjan.tijms@gmail.com>
<mailto:arjan.tijms@gmail.com
<mailto:arjan.tijms@gmail.com>>> a écrit :
> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> <antonio.goncalves(a)gmail.com
<mailto:antonio.goncalves@gmail.com>
<mailto:antonio.goncalves@gmail.com
<mailto:antonio.goncalves@gmail.com>>> wrote:
> > I remember talking with the JAX-RS guys (Java EE),
years ago
(back in EE6),
> > and their answer for not adopting CDI was "too heavy".
>
> I can't find an exact reference anymore, but I somewhat
remember that
> one of the reasons was also simply that CDI as a general
solution
> finished late in Java EE 6, while JAX-RS finished
earlier and had all
> the work for their own DI solution already done.
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG
| Devoxx
France
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all
other
ideas provided on this list, the provider waives all patent and
other intellectual property rights inherent in such
information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all
other
ideas provided on this list, the provider waives all patent and
other intellectual property rights inherent in such
information.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG
| Devoxx
France
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG
| Devoxx
France
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all
other
ideas provided on this list, the provider waives all patent and
other intellectual property rights inherent in such
information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <
http://www.antoniogoncalves.org> | Twitter
<
http://twitter.com/agoncal> | LinkedIn
<
http://www.linkedin.com/in/agoncal> | Pluralsight
<
http://pluralsight.com/training/Authors/Details/antonio-goncalves>
|
Paris JUG <
http://www.parisjug.org> | Devoxx France
<
http://www.devoxx.fr>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and
other intellectual property rights inherent in such information.
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <
http://www.antoniogoncalves.org> | Twitter
<
http://twitter.com/agoncal> | LinkedIn
<
http://www.linkedin.com/in/agoncal> | Pluralsight
<
http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
Paris JUG <
http://www.parisjug.org> | Devoxx France <
http://www.devoxx.fr>