[JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-500:
-------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.0 (discussion))
> Clarify @Intercepted Bean metadata injection for EE components
> --------------------------------------------------------------
>
> Key: CDI-500
> URL: https://issues.jboss.org/browse/CDI-500
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component.
> See the CDI spec, "5.5.8. Bean metadata":
> {quote}
> Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate:
> * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and
> * ...
> {quote}
> However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection":
> {quote}
> The component classes listed in Table EE.5-1 with support level "Standard"
> all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled—which it is by default—these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand closed CDI-516.
------------------------------------
Release Notes Text: Should be resolved with CDI-633
Resolution: Duplicate Issue
> Firing events with dynamic parameterized types
> ----------------------------------------------
>
> Key: CDI-516
> URL: https://issues.jboss.org/browse/CDI-516
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antonin Stefanutti
> Fix For: 2.0 (discussion)
>
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
> // Represents the runtime type for T
> Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
> String uri = endpointUri(type, ip.getQualifiers());
> if (context.hasEndpoint(uri) == null) {
> // Work around to pass the dynamic type
> TypeLiteral<T> literal = new TypeLiteral<T>() {};
> for (Field field : TypeLiteral.class.getDeclaredFields()) {
> if (field.getType().equals(Type.class)) {
> field.setAccessible(true);
> field.set(literal, type);
> break;
> }
> }
> // Here we used the dynamic type
> Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
> context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
> }
> return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-518:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Clarify boundaries of the ServletContext event
> ----------------------------------------------
>
> Key: CDI-518
> URL: https://issues.jboss.org/browse/CDI-518
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Fix For: TBD
>
>
> {quote}
> An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
> context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
> • any java.lang.Object for other types of application.
> {quote}
> Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
Re: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Werner Keil
The confusion between the existing BeanManager.fireEvent()
(JIRA comments sometimes just call it "fire") and this newly proposed
method should be avoided.
Backward-compatibility means the existing ones should still work as they do
of course.
What's the rationale behind just wanting to call it "event". It would
return an Event object. All but the void methods (including fireEvent)
follow certain conventions like
- get*
- create*
- is*
- are*
depending on what they return.
Why would a non-void non-static method of an existing interface that
returns something suddenly break with these conventions? If the existing
fireEvent method did not exist, it may be less problematic, though other
than the static accessor method current() in the CDI class, I am not aware
of interfaces doing that so far.
However having fireEvent in the same interface, just calling a "getter"
method event() makes that even more ambiguous and easy to misinterpret.
Werner
On Fri, Oct 7, 2016 at 1:59 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-224) Support Decoration of no interface
> beans (Antoine Sabot-Durand (JIRA))
> 2. [JBoss JIRA] (CDI-526) Include filters
> (Antoine Sabot-Durand (JIRA))
> 3. [JBoss JIRA] (CDI-613) Container should be able to receive
> information about the context in which it was bootstraped
> (Antoine Sabot-Durand (JIRA))
> 4. [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
> (Antoine Sabot-Durand (JIRA))
> 5. [JBoss JIRA] (CDI-613) Container should be able to receive
> information about the context in which it was bootstraped
> (Antoine Sabot-Durand (JIRA))
> 6. [JBoss JIRA] (CDI-612)
> ObserverMethodConfigurator.notifyWith() should probably accept a
> functional interface whose method throws java.lang.Exception
> (Antoine Sabot-Durand (JIRA))
> 7. [JBoss JIRA] (CDI-601) Add container lifecycle event fired
> before container destroys all contexts (Antoine Sabot-Durand (JIRA))
> 8. [JBoss JIRA] (CDI-593) Mention
> javax.enterprise.inject.spi.Prioritized in spec text and improve
> its javadoc (Antoine Sabot-Durand (JIRA))
> 9. [JBoss JIRA] (CDI-592) Consider adding
> ObserverMethod.notify() method which also accepts EventMetadata
> (Antoine Sabot-Durand (JIRA))
> 10. [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean
> instance (Antoine Sabot-Durand (JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 4
> Date: Fri, 7 Oct 2016 07:33:00 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce
> BeanManager.event()
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12650965.1474369800000.72245.1475839980420(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [ https://issues.jboss.org/browse/CDI-633?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Antoine Sabot-Durand updated CDI-633:
> -------------------------------------
> Fix Version/s: 2.0 .Final
> (was: 2.0 (discussion))
>
>
> > Intoroduce BeanManager.event()
> > ------------------------------
> >
> > Key: CDI-633
> > URL: https://issues.jboss.org/browse/CDI-633
> > Project: CDI Specification Issues
> > Issue Type: Feature Request
> > Reporter: Martin Kouba
> > Fix For: 2.0 .Final
> >
> >
> > * this would allow to define the _specified type_ - the container may
> use the specified type to infer the parameterized type of the event types
> > * the method should return {{javax.enterprise.event.Event<Object>}}
> with no qualifiers
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-613) Container should be able to
> receive information about the context in which it was bootstraped
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12629498.1464972649000.72322.1475840820239(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [ https://issues.jboss.org/browse/CDI-613?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Antoine Sabot-Durand updated CDI-613:
> -------------------------------------
> Fix Version/s: TBD
> (was: 2.0 (discussion))
>
>
> > Container should be able to receive information about the context in
> which it was bootstraped
> > ------------------------------------------------------------
> ---------------------------------
> >
> > Key: CDI-613
> > URL: https://issues.jboss.org/browse/CDI-613
> > Project: CDI Specification Issues
> > Issue Type: Feature Request
> > Components: Java EE integration
> > Reporter: Antoine Sabot-Durand
> > Fix For: TBD
> >
> >
> > Today it's impossible to know what is the outside context of the CDI
> container (i.e what is the application or EE module it belongs to).
> > This is problematic for other spec like JPA who needs to retrieve their
> information (persistence units) from a portable extension.
> > This would help solving issues like WFLY-2387 in a portable way.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 7 Oct 2016 07:47:00 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-612)
> ObserverMethodConfigurator.notifyWith() should probably accept a
> functional interface whose method throws java.lang.Exception
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12629421.1464951703000.72324.1475840820290(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [ https://issues.jboss.org/browse/CDI-612?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Antoine Sabot-Durand updated CDI-612:
> -------------------------------------
> Fix Version/s: 2.0 .Final
> (was: 2.0 (discussion))
>
>
> > ObserverMethodConfigurator.notifyWith() should probably accept a
> functional interface whose method throws java.lang.Exception
> > ------------------------------------------------------------
> -----------------------------------------------------------------
> >
> > Key: CDI-612
> > URL: https://issues.jboss.org/browse/CDI-612
> > Project: CDI Specification Issues
> > Issue Type: Clarification
> > Affects Versions: 2.0-EDR1
> > Reporter: Martin Kouba
> > Fix For: 2.0 .Final
> >
> >
> > The regular observer methods may also throw checked exceptions (wrapped
> and rethrown as an (unchecked) {{ObserverException}}).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 7 Oct 2016 07:52:01 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle
> event fired before container destroys all contexts
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12626142.1463386462000.72386.1475841121230(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [ https://issues.jboss.org/browse/CDI-601?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Antoine Sabot-Durand resolved CDI-601.
> --------------------------------------
> Resolution: Duplicate Issue
>
>
> Duplicates CDI-625
>
> > Add container lifecycle event fired before container destroys all
> contexts
> > ------------------------------------------------------------
> --------------
> >
> > Key: CDI-601
> > URL: https://issues.jboss.org/browse/CDI-601
> > Project: CDI Specification Issues
> > Issue Type: Feature Request
> > Reporter: Martin Kouba
> > Fix For: 2.0 (discussion)
> >
> >
> > The name might be something like {{BeforeContainerShutdown}}. Note that
> we probably cannot change the name or semantics of {{BeforeShutdown}},
> which is fired after container destroys all contexts. The motivation is to
> allow the beans to perform some kind of cleanup before dependencies could
> be disposed (the ordering of destruction is not defined).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 7 Oct 2016 07:54:01 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention
> javax.enterprise.inject.spi.Prioritized in spec text and improve
> its
> javadoc
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12611926.1458825009000.72430.1475841241255(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [ https://issues.jboss.org/browse/CDI-593?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Antoine Sabot-Durand updated CDI-593:
> -------------------------------------
> Fix Version/s: 2.0 .Final
> (was: 2.0 (discussion))
>
>
> > Mention javax.enterprise.inject.spi.Prioritized in spec text and
> improve its javadoc
> > ------------------------------------------------------------
> ------------------------
> >
> > Key: CDI-593
> > URL: https://issues.jboss.org/browse/CDI-593
> > Project: CDI Specification Issues
> > Issue Type: Clarification
> > Reporter: Martin Kouba
> > Fix For: 2.0 .Final
> >
> >
> > * javadoc would definitely deserve some more info
> > * the spec text should mention this interface as well and describe basic
> use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}}
> and implementing this interface is globally enabled)
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 7 Oct 2016 07:55:00 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-592) Consider adding
> ObserverMethod.notify() method which also accepts EventMetadata
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12611754.1458745510000.72436.1475841300410(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [ https://issues.jboss.org/browse/CDI-592?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Antoine Sabot-Durand updated CDI-592:
> -------------------------------------
> Fix Version/s: 2.0 .Final
> (was: 2.0 (discussion))
>
>
> > Consider adding ObserverMethod.notify() method which also accepts
> EventMetadata
> > ------------------------------------------------------------
> -------------------
> >
> > Key: CDI-592
> > URL: https://issues.jboss.org/browse/CDI-592
> > Project: CDI Specification Issues
> > Issue Type: Feature Request
> > Components: Events
> > Reporter: Martin Kouba
> > Fix For: 2.0 .Final
> >
> >
> > {code:java}
> > // Make the original method also default so that new impls don't need to
> implement two methods
> > default void notify(T event) {
> > // No-op
> > }
> > // The container should always call this method...
> > default void notify(T event, EventMetadata metadata) {
> > notify(event);
> > }
> > {code}
> > This should not break existing implementations. The truth is a custom
> impl will not be forced to implement any {{notify()}} method. But I think
> the benefits are worth it.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 7 Oct 2016 07:59:00 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to
> unmanage a bean instance
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12584980.1442331236000.72464.1475841540189(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [ https://issues.jboss.org/browse/CDI-561?page=com.
> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Antoine Sabot-Durand updated CDI-561:
> -------------------------------------
> Fix Version/s: TBD
> (was: 2.0 (discussion))
>
>
> > Add the possibility to unmanage a bean instance
> > -----------------------------------------------
> >
> > Key: CDI-561
> > URL: https://issues.jboss.org/browse/CDI-561
> > Project: CDI Specification Issues
> > Issue Type: Feature Request
> > Components: Beans
> > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1
> > Reporter: Antoine Sabot-Durand
> > Fix For: TBD
> >
> >
> > CDI implementations make heavy uses of proxies to support normal scope
> and interceptor decorators. There are use case where being able to have a
> bean instance without its proxy could be useful
> > * Accessing the true class of the instance in a clean way
> > * Being able to capture an instance state to use its information outside
> CDI or as an event payload
> > The limitation we have on Async event is probably a good example. As we
> don't propagate active normal context at firing time, it's not possible to
> inject a bean with such a scope (except {{@ApplicationScoped}} since
> Application context is shared), it could be useful to give the possibility
> to copy such a bean instance to a standard pojo instance so it could be
> used as event payload for instance.
> > We could even imagine that the mechanism could be transparently
> activated if an asynchronous observer inject a {{@RequestScoped}} or
> {{@SessionScoped}} bean.
>
>
>
> --
> 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 71, Issue 8
> **************************************
>
7 years, 6 months
[JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager.
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-523:
-------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.0 (discussion))
> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
> Key: CDI-523
> URL: https://issues.jboss.org/browse/CDI-523
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Martin Andersson
> Fix For: 2.0 .Final
>
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
> @PersistenceContext
> @Produces @UserDatabase
> private EntityManager em;
>
> public void close(@Disposes @UserDatabase EntityManager em) {
> em.close();
> }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager.
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-523:
------------------------------------------
So example should be changed.
Do you have suggestion to demonstrated disposer with a basic example ?
> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
> Key: CDI-523
> URL: https://issues.jboss.org/browse/CDI-523
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Martin Andersson
> Fix For: 2.0 .Final
>
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
> @PersistenceContext
> @Produces @UserDatabase
> private EntityManager em;
>
> public void close(@Disposes @UserDatabase EntityManager em) {
> em.close();
> }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-526) Include filters
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-526:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> 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: TBD
>
>
> 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)
7 years, 6 months
[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-623 at 10/7/16 8:14 AM:
-------------------------------------------------------------------
During F2F meeting we agreed on the following wording:
{quote}If the container is unable to process configurator it will be treated as a deployment problem{quote}
was (Author: antoinesabot-durand):
During F2F meeting we agreed on the following wording:
{quote}If the container is unable to process configurator it will be treated as a deployement problem{quote}
> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
> Key: CDI-623
> URL: https://issues.jboss.org/browse/CDI-623
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: John Ament
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-623:
------------------------------------------
During F2F meeting we agreed on the following wording:
{quote}If the container is unable to process configurator it will be treated as a deployement problem{quote}
> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
> Key: CDI-623
> URL: https://issues.jboss.org/browse/CDI-623
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: John Ament
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-541:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
> Key: CDI-541
> URL: https://issues.jboss.org/browse/CDI-541
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
> Fix For: TBD
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority?
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>
> void observeMessage(@Observes @Priority(2000) Message message){}
> }
> {code}
> {code}
> public class Second {
>
> void observeMessage(@ObservesAsync @Priority(2100) Message message){}
> }
> {code}
> {code}
> public class Third {
>
> void observeMessage(@Observes @Priority(2200) Message message){}
> }
> {code}
> {code}
> public class Fourth {
>
> void observeMessage(@ObservesAsync @Priority(2300) Message message){}
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months