[cdi-dev] F2F at JavaOne?
Werner Keil
werner.keil at gmail.com
Wed Jul 27 03:50:12 EDT 2016
Hi,
I know for those in Europe, especially France or Czech Republic a F2F seems
planned even in the same month (Sep) which is why I cannot travel aside
from nearly 2 full work weeks that'll cost me and my clients.
Antoine and some of his colleagues have a few sessions related to CDI as
such and "somewhat related topics" including Docker, Microservices, etc.
Are enough others (I know Anatole has a talk, Otavio also does, at least
the one related to JSR 363 I plan to join) from the EG there who have time
to meet? Hopefully the JCP gets a room in the Hilton again, otherwise I'm
sure we could meet somewhere else.
WDYT?
Werner
On Wed, Jul 27, 2016 at 7:56 AM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at 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. Invitation mise ? jour: CDI weekly meeting - Toutes les
> semaines entre 18:00 et 19:00 le mardi (CET) (ASD Perso)
> (antoine at sabot-durand.net)
> 2. Re: Enabling programmatic/synthetic decorators added by
> extension (Martin Kouba)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Jul 2016 15:35:55 +0000
> From: antoine at sabot-durand.net
> Subject: [cdi-dev] Invitation mise ? jour: CDI weekly meeting - Toutes
> les semaines entre 18:00 et 19:00 le mardi (CET) (ASD Perso)
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <001a11c2832c2272ef05388ba8d0 at google.com>
> Content-Type: text/plain; charset="utf-8"
>
> Cet ?v?nement a ?t? modifi?.
>
> Titre : CDI weekly meeting
> Weekly meeting of the CDI EG and other community members discussing CDI 2.0
> specification.
> Date?: Toutes les semaines entre 18:00 et 19:00 le mardi Paris (modifi?)
> Lieu : IRC #cdi-dev channel on freenode
> Agenda?: ASD Perso
> Participants?:
> * Antoine Sabot-Durand- organisateur
> * cdi-dev
>
> D?tails de l'?v?nement :
>
> https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=fr
>
> Invitation de Google?Agenda?: https://www.google.com/calendar/
>
> Vous recevez ce message ? l'adresse cdi-dev at lists.jboss.org, car vous
> participez ? cet ?v?nement.
>
> Refusez cet ?v?nement pour ne plus recevoir de notifications le concernant.
> Vous avez ?galement la possibilit? de cr?er un compte Google ? l'adresse
> https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de
> notification pour l'int?gralit? de votre agenda.
>
> En transf?rant cette invitation, vous risquez d'autoriser tous les
> destinataires ? modifier votre r?ponse ? l'invitation. Pour en savoir plus,
> consultez la page suivante?:
> https://support.google.com/calendar/answer/37135#forwarding
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment-0001.html
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: text/calendar
> Size: 2031 bytes
> Desc: not available
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment-0002.bin
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: invite.ics
> Type: application/ics
> Size: 2091 bytes
> Desc: not available
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160726/6dc7ad8c/attachment-0003.bin
>
> ------------------------------
>
> Message: 2
> Date: Wed, 27 Jul 2016 07:56:48 +0200
> From: Martin Kouba <mkouba at redhat.com>
> Subject: Re: [cdi-dev] Enabling programmatic/synthetic decorators
> added by extension
> To: cdi-dev at lists.jboss.org
> Message-ID: <10bcc54a-777a-5931-1738-cdaeb5a7a593 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> For the record - in CDI 2.0 we have
> javax.enterprise.inject.spi.Prioritized interface (currently used for
> ObserverMethod).
>
> But since Weld 3.0.0.Alpha13 prioritized custom beans, interceptors and
> decorators are also supported, i.e. Weld treats them as if annotated
> with @Priority (see also WELD-2000 [1]). I think this approach is also
> worth standardizing.
>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WELD-2000
>
> Dne 26.7.2016 v 11:59 arjan tijms napsal(a):
> > Hi,
> >
> > Just wondering, has there been any progress made for this topic?
> >
> > Having the ability to dynamically add interceptors and/or add them when
> > building a Bean<T> using the programmatic APIs would still be incredibly
> > useful.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > On Fri, Mar 4, 2016 at 5:18 PM, arjan tijms <arjan.tijms at gmail.com
> > <mailto:arjan.tijms at gmail.com>> wrote:
> >
> > ProxyFactory sounds like a perfect solution indeed.
> >
> > I now got something working, more or less, emphasis on less.
> >
> > I first make a "normal" (but effectively dummy) decorator with
> > @Priority available:
> >
> > @Decorator
> > @Priority(PLATFORM_BEFORE + 200)
> > public abstract class HttpAuthenticationBaseDecorator implements
> > HttpAuthenticationMechanism, Serializable {
> >
> > private static final long serialVersionUID = 1L;
> >
> > @Inject
> > @Delegate
> > HttpAuthenticationMechanism delegateMechanism;
> >
> > @Override
> > public AuthStatus validateRequest(HttpServletRequest request,
> > HttpServletResponse response, HttpMessageContext httpMessageContext)
> > throws AuthException {
> > return delegateMechanism.validateRequest(request, response,
> > httpMessageContext);
> > }
> > // ...
> > }
> >
> >
> > Then I create a "dynamic/programmatic" decorator:
> >
> >
> > public class DynamicHttpAuthenticationDecorator implements
> > Decorator<HttpAuthenticationBaseDecorator> {
> >
> > private final Set<Type> types = new
> > HashSet<Type>(asList(HttpAuthenticationBaseDecorator.class,
> > Object.class));
> > private final Set<Type> decoratedTypes =
> > singleton(HttpAuthenticationMechanism.class);
> >
> > private final BeanManager beanManager;
> > private final InjectionPoint decoratorInjectionPoint;
> > private final Set<InjectionPoint> injectionPoints;
> >
> > public DynamicHttpAuthenticationDecorator(BeanManager
> beanManager) {
> >
> > decoratorInjectionPoint = new DecoratorInjectionPoint(
> > HttpAuthenticationMechanism.class,
> >
> >
> beanManager.createAnnotatedType(HttpAuthenticationBaseDecorator.class).getFields().iterator().next(),
> > this);
> >
> > injectionPoints = singleton(decoratorInjectionPoint);
> >
> > this.beanManager = beanManager;
> > }
> >
> > public HttpAuthenticationBaseDecorator
> > create(CreationalContext<HttpAuthenticationBaseDecorator>
> > creationalContext) {
> > return new AutoApplySessionDecorator(
> > (HttpAuthenticationMechanism)
> > beanManager.getInjectableReference(decoratorInjectionPoint,
> > creationalContext));
> > }
> >
> > public void destroy(HttpAuthenticationBaseDecorator instance,
> > CreationalContext<HttpAuthenticationBaseDecorator>
> creationalContext) {
> > creationalContext.release();
> > }
> >
> > public Set<Type> getTypes() {
> > return types;
> > }
> >
> > public Set<Type> getDecoratedTypes() {
> > return decoratedTypes;
> > }
> >
> > public Class<?> getBeanClass() {
> > return HttpAuthenticationBaseDecorator.class;
> > }
> >
> > public Type getDelegateType() {
> > return HttpAuthenticationMechanism.class;
> > }
> >
> > public Set<InjectionPoint> getInjectionPoints() {
> > return injectionPoints;
> > }
> > }
> >
> > This Decorator<T> "pretends" that it's for the dummy decorator, via
> > the getTypes(), but in create() it returns another actual Decorator.
> > Then I create the delegate injection point of that decorator by
> > grabbing the @Delegate annotated field from the real decorator,
> > wrapping that basically in an InjectionPoint and then using that
> > later with beanManager#getInjectableReference.
> >
> > Now after adding this via afterBeanDiscovery.addBean(new
> > DynamicHttpAuthenticationDecorator(beanManager)), and it actually
> > gets called at runtime (tested on Weld).
> >
> > Disadvantages are a fixed priority and the fact that the dummy
> > decorator is called as well.
> >
> > Have to say that implementing
> > the javax.enterprise.inject.spi.Decorator interface, especially the
> > part for grabbing the @Delegate is quite non-obvious.
> >
> > What do you think, is this guaranteed to work, or did I abuse the
> > CDI APIs too much here?
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Mar 2, 2016 at 11:14 PM, Thomas Andraschko
> > <andraschko.thomas at gmail.com <mailto:andraschko.thomas at gmail.com>>
> > wrote:
> >
> > +1
> >
> > in DeltaSpike we implemented an own mechanism + proxy to invoke
> > interceptors for partial beans.
> > We will probably enhance this for such usecases or even
> > producers: https://issues.apache.org/jira/browse/DELTASPIKE-1069
> >
> >
> > 2016-03-02 22:51 GMT+01:00 Romain Manni-Bucau
> > <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>>:
> >
> > +1, seems it is the way to fix several issues without
> > introducing a lot of new concepts/API and in term of
> > technical stack it is just standardizing what is there.
> >
> >
> > 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>
> >
> > 2016-03-02 22:48 GMT+01:00 Mark Struberg <struberg at yahoo.de
> > <mailto:struberg at yahoo.de>>:
> >
> > ProxyFactory?
> >
> > I?m really thinking about introducing something like
> > javax.proxy, maybe as own sub-spec PDF?
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 02.03.2016 um 16:31 schrieb arjan tijms
> > <arjan.tijms at gmail.com <mailto:arjan.tijms at gmail.com>>:
> > >
> > > Hi,
> > >
> > > I'm trying to add decorators and/or interceptors to a
> > Bean<T> that's added via an extension. There doesn't
> > seem to be any way to add interceptors, but decorators
> > seem almost possible.
> > >
> > > I've added a decorator in the following way:
> > >
> > >
> > > AnnotatedType<AutoApplySessionDecorator> annotatedType
> > =
> >
> beanManager.createAnnotatedType(AutoApplySessionDecorator.class);
> > >
> > > BeanAttributes<AutoApplySessionDecorator>
> > beanAttributes =
> > beanManager.createBeanAttributes(annotatedType);
> > >
> > > Bean<AutoApplySessionDecorator> bean =
> > beanManager.createBean(beanAttributes,
> > AutoApplySessionDecorator.class,
> > beanManager.getInjectionTargetFactory(annotatedType));
> > >
> > > afterBeanDiscovery.addBean(bean);
> > >
> > > Where the "AutoApplySessionDecorator" is an existing
> > (non-scanned) decorator just used as an example.
> > >
> > >
> > > While this seems to work, the problem is with the
> > enablement. @Priority is not processed in this way,
> > since it's only read from an AnnotatedType that's been
> > added to the deployment (see e.g. in Weld
> >
> org.jboss.weld.bootstrap.BeanDeployer.processPriority(AnnotatedType<?>)).
> > >
> > > beans.xml is not really an option here due to the
> > static nature of that and the fact that the decorator
> > needs to be enabled dynamically here, plus that the
> > implementation class of the decorator is a detail I
> > would not like to expose to the application.
> > >
> > >
> > > Is there any other way to either enable a (synthetic)
> > decorator programmatically, or to add Interceptors to a
> > programmatically added Bean<T>?
> > >
> > > Kind regards,
> > > Arjan Tijms
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org <mailto:
> cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at 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 at 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 68, Issue 17
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160727/799e8ad6/attachment-0001.html
More information about the cdi-dev
mailing list