Getting injection point from Bean#create
by arjan tijms
Hi,
In a producer method it's trivial to get access to an InjectionPoint
instance representing the point where the value produced by the
producer will be injected.
When registering a Bean manually from an extension using
AfterBeanDiscovery#addBean, this is not immediately obvious.
After some fumbling with the CDI APIs I came up with the following
code that seems to work on both Weld and OWB (didn't test CanDI yet).
It uses a small "dummy" class, which is used to grab an InjectionPoint off:
In a Bean:
public Object create(CreationalContext<Object> creationalContext) {
InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
creationalContext
);
With InjectionPointGenerator being the following class:
public class InjectionPointGenerator {
@Inject
private InjectionPoint injectionPoint;
}
And resolve being the following method:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
As mentioned, while this seems to work, I wonder if it's the best approach.
Kind regards,
Arjan
8 years, 9 months
- 4
- 8
JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
by Nigel Deakin
Over in the JMS 2.1 expert group I've just published some proposals to allow any CDI managed bean in a Java EE
application to listen for JMS messages. This would be implemented as a standard CDI portable extension and would become
a mandatory part of a full Java EE 8 application server.
I would welcome any comments from the CDI spec experts here. If you're interested in helping, please take a look at
https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
and send comments or questions to me or to the public users(a)jms-spec.java.net alias.
Thanks,
Nigel
JMS 2.1 specification lead
9 years, 2 months
- 7
- 46
Time to start working on CDI lite
by Antoine Sabot-Durand
Hi guys,
CDI lite is one of the big feature we are expected to deliver for version
2.0. I think it's time to start discussing about its design.
The big picture is to provide a consistent subset of CDI that could be
implemented like Dagger is (code generated with process annotation). This
would allow using CDI in constrained environment like mobile or embedded
devices.
IMO CDI lite should be targeted to Java SE (I don't think it would make
sense for Java EE). So, from a specification perspective, we''l probably
have to split core part in 2 and se part as well (gosh).
I'm not sure regarding API. today they only weight 72 KB, so creating a
subset only for the sake of the weight doesn't make sense. the only reason
would be to have something clearer for the end user. but that could be
tricky.
Antoine
9 years, 2 months
- 8
- 23
Re: [cdi-dev] Time to start working on CDI lite
by Werner Keil
Unless CDI 2 still ended up redefining the @Inject (aka JSR 330) standard
at least as MR, there is no change of that spec. So if it is free for
implementations to decide how @Inject works or if some (like Tapestry)
prefer their own parallel @Inject annotations side-by-side, that won't
change with a "CDI lite" profile or module.
Werner
On Mon, Aug 31, 2015 at 10:28 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Time to start working on CDI lite (Antonio Goncalves)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2015 10:28:04 +0200
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Martin Kouba <mkouba(a)redhat.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CA+ZZq9-76Q8nug_q-uJmGTuxC9imzc9My2YHLHf7JoRmNZRCfA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
> Antonio
>
> On Mon, Aug 31, 2015 at 10:11 AM, Martin Kouba <mkouba(a)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>> 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>>:
> >> >
> >> > 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>> 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>>:
> >> > 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>> wrote:
> >> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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>>
> >> 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>> 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>> a ?crit :
> >> > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> > <antonio.goncalves(a)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>
> >> > 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>
> >> > 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>
> >> > 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
> >> 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>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/639a074c/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 57, Issue 45
> ***************************************
>
9 years, 2 months
- 1
- 0
Re: [cdi-dev] Time to start working on CDI lite
by Werner Keil
Good points by both of you.
@Mark about your earlier posts
Sure, 330 started a bit later than 299, and I know best (because I was one
of the few EC members also actively participating in discussion threads
like Google Groups to help them find synergies) there was a bit of "pissing
contest" or "not invented here" friction between Spec Leads and experts of
299 and 330 (in itself the "least common denominator" of several other
ideas including Spring or Guice)
We saw these things go pretty wrong in cases like JSR 310 (the Spec Lead
just figured everything was "crap" that hd did not invent, and only a bit
of naming or feature cropping was possible by JDK architects and Oracle,
but a lot of things are reinvented even when it comes to formatting, etc.
not at all in line with other parts Java SE) or 107 vs. 347 (where the
latter simply gave up due to lack of interest or resources, despite
proposed by the compnay that also leads the CDI spec) but for most parts
I'd say, it went reasonably well for 330 and 299+
Werner
On Mon, Aug 31, 2015 at 10:11 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Time to start working on CDI lite (Romain Manni-Bucau)
> 2. Re: Time to start working on CDI lite (Martin Kouba)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2015 10:00:58 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=
> 7MzVcBrhnoeUpo6ZAMpDu_04SOWSttWc-hRJL4wm8vpDw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> @Antonio: spring and guice have events, they just dont work the same way
> CDI defined them but not a big deal IMO to support them (just one more
> processor for spring for instance).
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-31 9:57 GMT+02:00 Antonio Goncalves <antonio.goncalves(a)gmail.com>:
>
> > 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 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>
> 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>:
> >> >
> >> > 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> 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>:
> >> > 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> wrote:
> >> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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> 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> 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> a
> >> ?crit :
> >> > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> > <antonio.goncalves(a)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
> >> > 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
> >> > 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
> >> > 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>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/4d1b9468/at...
>
> ------------------------------
>
> Message: 2
> Date: Mon, 31 Aug 2015 10:11:54 +0200
> From: Martin Kouba <mkouba(a)redhat.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>, Mark Struberg
> <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <55E40C4A.4090905(a)redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> 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>> 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>>:
> > >
> > > 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>> 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>>:
> > > 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>> wrote:
> > > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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>>
> > 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>> 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>> a ?crit :
> > > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> > > <antonio.goncalves(a)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>
> > > 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>
> > > 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>
> > > 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
> > 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
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 57, Issue 43
> ***************************************
>
9 years, 2 months
- 1
- 0
Re: [cdi-dev] Time to start working on CDI lite
by Werner Keil
Antonio/all,
JSR 330 was never a "subspec" of CDI, but CDI simply extended it. Just like
e.g. Portlet, JSP or JSF all extend and build around a standard like
Servlets.
Antoine mentioned Dagger, so if a CDI "lite" aims at SE, would the minimum
version also be SE 8 or could it be more widely usable, at least on the
Spec/API side?
We all know, Android is a bit of a red hering for Oracle with all that
lawsuit mess going on seemingly forever. Especially Dagger now that Google
took ownership again with 2.0 also aims at Android among other SE
environments. The minimum JVM version is Java SE 7 according to the POM.
If there's anything similar to a CDI lite as a subset, it's probably
CLDC/Java ME. Compared to Java SE it has a much smaller footprint with even
the same class often being reduced in its number of methods. Not sure, if
the latter was really necessary for CDI lite, but reducing the number of
overall API elements should help to get it small and useful enough for SE.
Werner
On Sun, Aug 30, 2015 at 3:22 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Time to start working on CDI lite (Antoine Sabot-Durand)
> 2. Re: Time to start working on CDI lite (Antoine Sabot-Durand)
> 3. Re: Time to start working on CDI lite (Antonio Goncalves)
> 4. Re: Time to start working on CDI lite (John D. Ament)
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 30 Aug 2015 14:06:33 +0200
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> @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> 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> a
> > ?crit :
> >
> >> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> <antonio.goncalves(a)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 <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>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/6d57ffc9/at...
>
> ------------------------------
>
> Message: 4
> Date: Sun, 30 Aug 2015 13:22:04 +0000
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>, Antoine
> Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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).
>
> 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> 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> 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> a
> >> ?crit :
> >>
> >>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>> <antonio.goncalves(a)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 <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
> > 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/64394d4f/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 57, Issue 31
> ***************************************
>
9 years, 2 months
- 2
- 1
Re: [cdi-dev] Time to start working on CDI lite
by Werner Keil
Well for whatever reason Antonio sounded rather uneasy about events. If
it's not size it must be for another reason, but take the idea of
optionality for things that might have a relatively large footprint in the
end.
Werner
On Sun, Aug 30, 2015 at 9:33 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Time to start working on CDI lite (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Aug 2015 21:32:49 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Werner Keil <werner.keil(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=
> 7NFQhQL8AUGbBgj0r1qj8UM2xy4WpTrtxTepMutBs94Mg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-30 21:20 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>:
>
> > Well if we found a way to offer some level of modularity and optionality
> > (despite SE or EE 8 not putting a strong emphasis on either yet) I would
> > certainly see it as an option. This could keep the size for some apps
> down
> > if they use other event systems already.
> >
> >
> strictly yes, in practice the event bus is rarely more than few kb so does
> it worth the time the EG would spend on it?
>
>
> > Werner
> >
> > On Sun, Aug 30, 2015 at 9:11 PM, <cdi-dev-request(a)lists.jboss.org>
> wrote:
> >
> >> Send cdi-dev mailing list submissions to
> >> cdi-dev(a)lists.jboss.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> or, via email, send a message with subject or body 'help' to
> >> cdi-dev-request(a)lists.jboss.org
> >>
> >> You can reach the person managing the list at
> >> cdi-dev-owner(a)lists.jboss.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of cdi-dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Re: Time to start working on CDI lite (Romain Manni-Bucau)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Sun, 30 Aug 2015 21:11:24 +0200
> >> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
> >> To: Werner Keil <werner.keil(a)gmail.com>
> >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> >> Message-ID:
> >> <CACLE=
> >> 7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw(a)mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >>
> >> 2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>:
> >>
> >> > As there is well-established event handling on the SE and ME side, in
> >> most
> >> > cases based on java.util.EventObject, I could imagine CDI events being
> >> > either outside a "lite" profile or at least optional, should we
> consider
> >> > optionality.
> >> >
> >> >
> >> not sure I agree, SE has an event hierarchy but its listener model is
> not
> >> as usable as CDI most of the time because of the register side
> >>
> >>
> >> > Werner
> >> >
> >> > On Sun, Aug 30, 2015 at 6:10 PM, <cdi-dev-request(a)lists.jboss.org>
> >> wrote:
> >> >
> >> >> Send cdi-dev mailing list submissions to
> >> >> cdi-dev(a)lists.jboss.org
> >> >>
> >> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> >> or, via email, send a message with subject or body 'help' to
> >> >> cdi-dev-request(a)lists.jboss.org
> >> >>
> >> >> You can reach the person managing the list at
> >> >> cdi-dev-owner(a)lists.jboss.org
> >> >>
> >> >> When replying, please edit your Subject line so it is more specific
> >> >> than "Re: Contents of cdi-dev digest..."
> >> >>
> >> >>
> >> >> Today's Topics:
> >> >>
> >> >> 1. Re: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
> >> >> 2. Re: Time to start working on CDI lite (Antonio Goncalves)
> >> >>
> >> >>
> >> >>
> ----------------------------------------------------------------------
> >> >>
> >> >> Message: 2
> >> >> Date: Sun, 30 Aug 2015 18:09:41 +0200
> >> >> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> >> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
> >> >> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> >> >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> >> >> Message-ID:
> >> >> <CA+ZZq9-YFcTKuZr=+6v=
> >> >> wH-w670E++qgBrN36DsToFEidUzenQ(a)mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> 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>
> >> >> 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 <https://twitter.com/rmannibucau> | Blog
> >> >> > <http://rmannibucau.wordpress.com> | Github
> >> >> > <https://github.com/rmannibucau> | LinkedIn
> >> >> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> >> > <http://www.tomitribe.com>
> >> >> >
> >> >> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> >> >> antonio.goncalves(a)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> wrote:
> >> >> >>
> >> >> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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> 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> 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>
> >> >> a
> >> >> >>>>>> ?crit :
> >> >> >>>>>>
> >> >> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> >> >>>>>>> <antonio.goncalves(a)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 <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
> >> >> >>>>> 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
> >> >> >>>> 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
> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> 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>
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL:
> >> >>
> >>
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/at...
> >> >>
> >> >> ------------------------------
> >> >>
> >> >> _______________________________________________
> >> >> cdi-dev mailing list
> >> >> cdi-dev(a)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.
> >> >>
> >> >> End of cdi-dev Digest, Vol 57, Issue 35
> >> >> ***************************************
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > cdi-dev mailing list
> >> > cdi-dev(a)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.
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL:
> >>
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/717fde38/at...
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)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.
> >>
> >> End of cdi-dev Digest, Vol 57, Issue 37
> >> ***************************************
> >>
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)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.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/4880ea38/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 57, Issue 39
> ***************************************
>
9 years, 2 months
- 2
- 1
Re: [cdi-dev] Time to start working on CDI lite
by Werner Keil
Well if we found a way to offer some level of modularity and optionality
(despite SE or EE 8 not putting a strong emphasis on either yet) I would
certainly see it as an option. This could keep the size for some apps down
if they use other event systems already.
Werner
On Sun, Aug 30, 2015 at 9:11 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Time to start working on CDI lite (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Aug 2015 21:11:24 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Werner Keil <werner.keil(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=
> 7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil(a)gmail.com>:
>
> > As there is well-established event handling on the SE and ME side, in
> most
> > cases based on java.util.EventObject, I could imagine CDI events being
> > either outside a "lite" profile or at least optional, should we consider
> > optionality.
> >
> >
> not sure I agree, SE has an event hierarchy but its listener model is not
> as usable as CDI most of the time because of the register side
>
>
> > Werner
> >
> > On Sun, Aug 30, 2015 at 6:10 PM, <cdi-dev-request(a)lists.jboss.org>
> wrote:
> >
> >> Send cdi-dev mailing list submissions to
> >> cdi-dev(a)lists.jboss.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> or, via email, send a message with subject or body 'help' to
> >> cdi-dev-request(a)lists.jboss.org
> >>
> >> You can reach the person managing the list at
> >> cdi-dev-owner(a)lists.jboss.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of cdi-dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Re: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
> >> 2. Re: Time to start working on CDI lite (Antonio Goncalves)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 2
> >> Date: Sun, 30 Aug 2015 18:09:41 +0200
> >> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
> >> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> >> Message-ID:
> >> <CA+ZZq9-YFcTKuZr=+6v=
> >> wH-w670E++qgBrN36DsToFEidUzenQ(a)mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> 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>
> >> 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 <https://twitter.com/rmannibucau> | Blog
> >> > <http://rmannibucau.wordpress.com> | Github
> >> > <https://github.com/rmannibucau> | LinkedIn
> >> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> > <http://www.tomitribe.com>
> >> >
> >> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> >> antonio.goncalves(a)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> wrote:
> >> >>
> >> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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> 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> 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
> >
> >> a
> >> >>>>>> ?crit :
> >> >>>>>>
> >> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> >>>>>>> <antonio.goncalves(a)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 <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
> >> >>>>> 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
> >> >>>> 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>
> >> >>
> >> >
> >> >
> >>
> >>
> >> --
> >> 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>
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL:
> >>
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/at...
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)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.
> >>
> >> End of cdi-dev Digest, Vol 57, Issue 35
> >> ***************************************
> >>
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)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.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/717fde38/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 57, Issue 37
> ***************************************
>
9 years, 2 months
- 2
- 1
Re: [cdi-dev] Time to start working on CDI lite
by Werner Keil
As there is well-established event handling on the SE and ME side, in most
cases based on java.util.EventObject, I could imagine CDI events being
either outside a "lite" profile or at least optional, should we consider
optionality.
Werner
On Sun, Aug 30, 2015 at 6:10 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
> 2. Re: Time to start working on CDI lite (Antonio Goncalves)
>
>
> ----------------------------------------------------------------------
>
> Message: 2
> Date: Sun, 30 Aug 2015 18:09:41 +0200
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CA+ZZq9-YFcTKuZr=+6v=
> wH-w670E++qgBrN36DsToFEidUzenQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> >
> 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 <https://twitter.com/rmannibucau> | Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> antonio.goncalves(a)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> wrote:
> >>
> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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> 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> 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> a
> >>>>>> ?crit :
> >>>>>>
> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>>>>>> <antonio.goncalves(a)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 <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
> >>>>> 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
> >>>> 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>
> >>
> >
> >
>
>
> --
> 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>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 57, Issue 35
> ***************************************
>
9 years, 2 months
- 2
- 1
Re: [cdi-dev] cdi-dev Digest, Vol 57, Issue 33
by Werner Keil
Looking at the requirements for SE Embedded (on the lower side of SE)
probably helps:
http://www.oracle.com/technetwork/java/embedded/embedded-se/documentation...
The 3 MB binary app size Romain mentioned is a good example. Could be a bit
steep for Embedded, but as an upper end it sounds reasonable.
Btw. although Rod Johnson and Bob Lee were listed as co Spec Leads, pretty
much every initial contribution and effort came from Google/Bob:
https://jcp.org/en/jsr/detail?id=330
The EG had a couple of others like Tapestry, but I am not sure, when it
e.g. adopted JSR 330 instead of its own DI library if it ever fully
supported it to date?
Werner
On Sun, Aug 30, 2015 at 4:11 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Time to start working on CDI lite (Romain Manni-Bucau)
> 2. Re: Time to start working on CDI lite (Werner Keil)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Aug 2015 16:02:32 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=
> 7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves(a)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
> > > wrote:
> >
> >> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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> 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> 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> a
> >>>>> ?crit :
> >>>>>
> >>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>>>>> <antonio.goncalves(a)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 <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
> >>>> 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
> >>> 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>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/db8e0477/at...
>
>
> End of cdi-dev Digest, Vol 57, Issue 33
> ***************************************
>
9 years, 2 months
- 2
- 1