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
Feedback of CDI F2F
by Antoine Sabot-Durand
Hi all,
We had a great time in Paris last week in our Face to Face meeting.
First I'd like to thank all the participant who brought their ideas,
experience and knowledge to this nice meeting:
- Martin Kouba (Mr Weld)
- Tomas Remes (Mr TCK)
- Antonio Goncalves (Mr Java EE)
- Emily Jiang (Ms Liberty Profile)
- Yann Blazart (Mr End user on OpenWebBeans)
And as a guest star: Emmanuel Bernard (Mr Third Party Spec)
I initially wanted to share the feedback here, but it's too long, so I'm
preparing a blog post on the website. It'll be published tonight or
tomorrow morning.
Antoine
9 years, 1 month
F2F participants
by Antoine Sabot-Durand
Hi guys,
So the meeting is starting friday in Paris. So far beyond the Red Hat guys
I have only 2 or 3 participants:
- Antonio
- Emily
- Werner (maybe)
Did I forget someone ?
Antoine
9 years, 1 month
[JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-383:
---------------------------------------
In Servlet 3.1 spec §11.3.4 Notifications At Shutdown
{quote}
On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown.
{quote}
> Clarify that session context is also destroyed at shutdown/undeploy
> -------------------------------------------------------------------
>
> Key: CDI-383
> URL: https://issues.jboss.org/browse/CDI-383
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Contexts
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
>
> Section 6.7.2. states "The session context is destroyed
> when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request
> in which invalidate() was called, after all filters and ServletRequestListener s have been called."
> The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-497:
---------------------------------------
In Servlet 3.1 §7.5 it's written :
{quote}
The session invalidation will not take effect until all servlets using that session have exited the service method
{quote}
> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
> Key: CDI-497
> URL: https://issues.jboss.org/browse/CDI-497
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
> Fix For: 2.0 (discussion)
>
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
Re: [cdi-dev] Opening CDI F2F meeting to the community
by Werner Keil
Guys,
Only getting this digest now, but wanted to reply in any case. Sorry, I
could not make it this time. Primarily due to more travel coming up, as
DevoXX BE in Antwerp also invited me and 2 JSR 363 EG members to talk.
A significant number of EG members, especially those in Paris or France are
likely to go there, if they're not already at JavaOne (I should be at the
EC F2F and JavaOne, as long as PMO approves the travel request to go there
and tickets are still available ;-) thus I will meet almost all of those in
Paris now at either of these occasions or both.
Enjoy the stay and see you soon,
Werner
On Sat, Sep 26, 2015 at 2:55 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. [JBoss JIRA] (CDI-383) Clarify that session context is also
> destroyed at shutdown/undeploy (Martin Kouba (JIRA))
> 2. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods
> (Martin Kouba (JIRA))
> 3. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods
> (Tomas Remes (JIRA))
> 4. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods
> (Martin Kouba (JIRA))
> 5. No meeting tomorrow (Antoine Sabot-Durand)
> 6. [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop
> event propagation after being handled by an observer
> (Martin Kouba (JIRA))
> 7. [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage
> of the returned CompletionStage (Martin Kouba (JIRA))
> 8. F2F participants (Antoine Sabot-Durand)
> 9. Opening CDI F2F meeting to the community (Antoine Sabot-Durand)
> 10. [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from
> javax.enterprise.inject.Instance (Martin Kouba (JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 17 Sep 2015 08:01:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context
> is also destroyed at shutdown/undeploy
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12495319.1372413710000.40095.1442491260731(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.sy...
> ]
>
> Martin Kouba commented on CDI-383:
> ----------------------------------
>
> Well, an HTTP session does not have to be destroyed after a container is
> shut down. This is not defined in the servlet spec and I did not find
> anything relevant in the Java EE spec. See also CDITCK-482 comments.
> However, if we redefine this and state that it's destroyed after an HTTP
> session is invalidated, we would probably break backward compatibility (see
> also CDI-497).
>
> > Clarify that session context is also destroyed at shutdown/undeploy
> > -------------------------------------------------------------------
> >
> > Key: CDI-383
> > URL: https://issues.jboss.org/browse/CDI-383
> > Project: CDI Specification Issues
> > Issue Type: Bug
> > Components: Contexts
> > Affects Versions: 1.1.PFD
> > Reporter: Marko Luk?a
> >
> > Section 6.7.2. states "The session context is destroyed
> > when the HTTPSession times out, after all HttpSessionListener s have
> been called, and at the very end of any request
> > in which invalidate() was called, after all filters and
> ServletRequestListener s have been called."
> > The first part of the above sentence should not only say that the
> context is destroyed after all listeners have been called specifically in
> the event of a session timeout. It should specify that this is also true
> when the session is being destroyed as a result of server shutdown or
> web-app undeploy.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 17 Sep 2015 09:26:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async
> observer methods
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12578938.1437573301000.40527.1442496360658(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy...
> ]
>
> Martin Kouba commented on CDI-547:
> ----------------------------------
>
> So we have three options:
> * add overloaded {{resolveObserverMethods()}} with an extra {{boolean}}
> param to distinguish between {{fire()}} and {{fireAsync()}}, the original
> method follows {{fire()}} semantics
> * add a new method, e.g. something like
> {{resolveObserverMethodsForFireAsync()}}
> * do not add any methods, and let a consumer filter out sync/async
> observers as needed, i.e. sync + async observers for {{fireAsync()}} and
> sync for {{fire()}}
>
> The other question is ordering. IMO this depends on the result of CDI-541.
> I.e. if async observers would not honor ordering the set does not have to
> be "ordered" at all.
>
> > Resolving sync/async observer methods
> > -------------------------------------
> >
> > Key: CDI-547
> > URL: https://issues.jboss.org/browse/CDI-547
> > Project: CDI Specification Issues
> > Issue Type: Clarification
> > Reporter: Jozef Hartinger
> >
> > There's the [BeanManager.resolveObserverMethods()|
> http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanMa...]
> method for resolving observer methods.
> > With addition of sync/async events and observers it is not unclear what
> the semantics of this methods are. We'll most likely need to add new or
> overloaded methods to make it possible to resolve observers for sync/async
> events.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 17 Sep 2015 09:46:01 -0400 (EDT)
> From: "Tomas Remes (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async
> observer methods
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12578938.1437573301000.40630.1442497561573(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy...
> ]
>
> Tomas Remes commented on CDI-547:
> ---------------------------------
>
> Yes maybe the third option looks as the best one to me. Because when you
> introduce new method then there is a question: What all should it return in
> case of ASYNC version? It would make sense to return all ASYNC + SYNC
> observers but I think this will bring only more confusion.
>
> > Resolving sync/async observer methods
> > -------------------------------------
> >
> > Key: CDI-547
> > URL: https://issues.jboss.org/browse/CDI-547
> > Project: CDI Specification Issues
> > Issue Type: Clarification
> > Reporter: Jozef Hartinger
> >
> > There's the [BeanManager.resolveObserverMethods()|
> http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanMa...]
> method for resolving observer methods.
> > With addition of sync/async events and observers it is not unclear what
> the semantics of this methods are. We'll most likely need to add new or
> overloaded methods to make it possible to resolve observers for sync/async
> events.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 17 Sep 2015 09:53:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async
> observer methods
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12578938.1437573301000.40685.1442497980220(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy...
> ]
>
> Martin Kouba commented on CDI-547:
> ----------------------------------
>
> Yep, it would return both ASYNC + SYNC, the same result one would expect
> for {{fireAsync()}}. That's why the proposed name contains *ForFireAsync*.
>
> The third option may also bring confusion - we will always return observer
> methods for {{fireAsync()}}.
>
> > Resolving sync/async observer methods
> > -------------------------------------
> >
> > Key: CDI-547
> > URL: https://issues.jboss.org/browse/CDI-547
> > Project: CDI Specification Issues
> > Issue Type: Clarification
> > Reporter: Jozef Hartinger
> >
> > There's the [BeanManager.resolveObserverMethods()|
> http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanMa...]
> method for resolving observer methods.
> > With addition of sync/async events and observers it is not unclear what
> the semantics of this methods are. We'll most likely need to add new or
> overloaded methods to make it possible to resolve observers for sync/async
> events.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 21 Sep 2015 07:10:08 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] No meeting tomorrow
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CABu-YBRpr14+t9-VnBcJAjUssyAChWZ53U+NAmnSAuhbgZ=
> 0Lw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Guys,
>
> I'll focus on the F2F meeting preparation. So no meeting tomorrow
>
> Regards,
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150921/f0e51a71/at...
>
> ------------------------------
>
> Message: 6
> Date: Mon, 21 Sep 2015 09:14:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false)
> - stop event propagation after being handled by an observer
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12420873.1286476929000.222.1442841240177(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.sys...
> ]
>
> Martin Kouba commented on CDI-20:
> ---------------------------------
>
> I'm not so sure it's a good idea to allow any observer to abort processing
> of an event. This would be another way to kill the original concept of
> decoupled interactiion. Ordering might be sometimes handy but to allow to
> abort the processing seems to me a bit too much. For some use cases it
> might be better to implement a mutable thread-safe event payload with a
> flag (as mentioned above) and let the observers handle this alone (e.g. the
> first one marks the payload as handled and others just skip the processing).
>
> > @Observes(propagate = false) - stop event propagation after being
> handled by an observer
> >
> ----------------------------------------------------------------------------------------
> >
> > Key: CDI-20
> > URL: https://issues.jboss.org/browse/CDI-20
> > Project: CDI Specification Issues
> > Issue Type: Feature Request
> > Components: Events
> > Affects Versions: 1.0
> > Environment: any
> > Reporter: Walter White
> > Fix For: 2.0 (discussion)
> >
> >
> > I would like to have the ability to stop event propagation after it is
> handled by any observer only for certain situations. Is it possible to add
> a property to the annotation indicating whether the propagation should
> continue after being handled by the observer? Alternatively, would it be
> more concise to add a qualifier annotation which specifies the propagation.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 21 Sep 2015 10:50:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify
> the usage of the returned CompletionStage
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12585540.1442846959000.631.1442847000016(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
> Martin Kouba created CDI-563:
> --------------------------------
>
> Summary: Event.fireAsync() - clarify the usage of the
> returned CompletionStage
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple
> exceptions thrown during an asynchronous event" and the
> {{Event.fireAsync()}} javadoc is too general. However, the
> {{CompletionStage}} itself does not define an unambiguous contract for its
> methods. E.g. what thread is used to execute a given callback? Or what's
> the _"stage's default asynchronous execution facility"_? I believe this is
> left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}}
> under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be
> performed by the thread that completes the current CompletableFuture, or by
> any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent
> action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This
> might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point
> of view. I think the spec should clarify the contract of a returned
> {{CompletionStage}}.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 23 Sep 2015 08:20:50 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] F2F participants
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CABu-YBSeNMo=
> a8N6NdmMRJxUMncuGTpDdV2WyUesoLTMqPDQdw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
> So the meeting is starting friday in Paris. So far beyond the Red Hat guys
> I have only 2 or 3 participants:
>
> - Antonio
> - Emily
> - Werner (maybe)
>
> Did I forget someone ?
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/acb3047c/at...
>
> ------------------------------
>
> Message: 9
> Date: Wed, 23 Sep 2015 10:03:07 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] Opening CDI F2F meeting to the community
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CABu-YBQqFRYHWRi3=
> 6L0eK+i7SWKdEu-9Uu-BUeTU5dGzgjg+w(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> As a lot of EG members won't make it for our meeting, if you follow this ml
> are in Paris on Friday and/or Saturday you can join us for our meeting.
> Send me a private email if you are interested.
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/7533fdae/at...
>
> ------------------------------
>
> Message: 10
> Date: Sat, 26 Sep 2015 08:55:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean
> metadata from javax.enterprise.inject.Instance
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12564784.1425452571000.17380.1443272100093(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.sy...
> ]
>
> Martin Kouba updated CDI-515:
> -----------------------------
> Fix Version/s: (was: 2.0 (discussion))
>
>
> > Allow to obtain Bean metadata from javax.enterprise.inject.Instance
> > -------------------------------------------------------------------
> >
> > Key: CDI-515
> > URL: https://issues.jboss.org/browse/CDI-515
> > Project: CDI Specification Issues
> > Issue Type: Feature Request
> > Affects Versions: 1.2.Final
> > Reporter: Martin Kouba
> > Fix For: 2.0 (proposed)
> >
> >
> > Sometimes it might be useful to obtain Bean metadata from the
> {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata).
> The method could be named {{getBean()}} and should have similar
> restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}}
> if appropriate).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> _______________________________________________
> 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 58, Issue 15
> ***************************************
>
9 years, 1 month
[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-458:
-----------------------------
Fix Version/s: 2.0 (proposed)
(was: 2.0 (discussion))
> Give the possibility to deactivate an observer in ProcessObserverMethod
> -----------------------------------------------------------------------
>
> Key: CDI-458
> URL: https://issues.jboss.org/browse/CDI-458
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 (proposed)
>
>
> Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{(a)WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage.
> We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-526) Include filters
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-526:
-----------------------------
Fix Version/s: 2.0 (proposed)
> Include filters
> ---------------
>
> Key: CDI-526
> URL: https://issues.jboss.org/browse/CDI-526
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Fix For: 2.0 (proposed)
>
>
> CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g:
> {code:XML}
> <exclude name="com.acme.rest.*" />
> {code}
> With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.:
> {code:XML}
> <include name="my.application.*" />
> {code}
> Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-526) Include filters
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-526:
----------------------------------
We can make use of Weld non-portable feature:
bq. If both include filters and excludes filters are specified, only class names which match at least one include filter and don't match any exclude filter are scanned.
> Include filters
> ---------------
>
> Key: CDI-526
> URL: https://issues.jboss.org/browse/CDI-526
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Fix For: 2.0 (proposed)
>
>
> CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g:
> {code:XML}
> <exclude name="com.acme.rest.*" />
> {code}
> With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.:
> {code:XML}
> <include name="my.application.*" />
> {code}
> Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
