[JBoss JIRA] (CDI-564) Async events simplification ad clarification
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-564:
----------------------------------------
Summary: Async events simplification ad clarification
Key: CDI-564
URL: https://issues.jboss.org/browse/CDI-564
Project: CDI Specification Issues
Issue Type: Clarification
Components: Events
Affects Versions: 2.0-EDR1
Reporter: Antoine Sabot-Durand
Following our F2F meeting, we decided to simplify Asynchronous event:
* {{FireAsync() }}should only triggers async observers
* Exception handling should be done with JDK 8 {{CompletionException}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-559) typo on page 113
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-559?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand resolved CDI-559.
--------------------------------------
Fix Version/s: 2.0-EDR2
Resolution: Done
> typo on page 113
> ----------------
>
> Key: CDI-559
> URL: https://issues.jboss.org/browse/CDI-559
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 2.0-EDR1
> Environment: n/a
> Reporter: Emily Jiang
> Assignee: Antoine Sabot-Durand
> Priority: Trivial
> Fix For: 2.0-EDR2
>
>
> On CDI 2.0 spec page 113
> @javax.enterprise.event.ObservesAsync+`should be @javax.enterprise.event.ObservesAsync in bold
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-559) typo on page 113
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-559?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-559:
----------------------------------------
Assignee: Antoine Sabot-Durand
> typo on page 113
> ----------------
>
> Key: CDI-559
> URL: https://issues.jboss.org/browse/CDI-559
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 2.0-EDR1
> Environment: n/a
> Reporter: Emily Jiang
> Assignee: Antoine Sabot-Durand
> Priority: Trivial
> Fix For: 2.0-EDR2
>
>
> On CDI 2.0 spec page 113
> @javax.enterprise.event.ObservesAsync+`should be @javax.enterprise.event.ObservesAsync in bold
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-458 started by Antoine Sabot-Durand.
------------------------------------------------
> 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
> Assignee: 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, 2 months
[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-458:
----------------------------------------
Assignee: Antoine Sabot-Durand
> 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
> Assignee: 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, 2 months
Adding / vetoing CDI extensions programmatically
by Antonin Stefanutti
Hi CDI mates,
I’ve been developing a couple of CDI extensions over the last couple of years and been facing this recurrent situation:
- I develop the extension against the latest CDI release version (1.2 for the time being),
- As the extension gets used, comes the requests to run the extension in previous CDI versions,
- As any real-world extensions heavily rely on the CDI SPI, they never happen to be backward-compatible,
- And that’s understandable that the end-users won’t upgrade its runtime environment for just one extension.
One option is to rewrite the extension against the oldest required CDI version (generally 1.0 as a lot of people still use that version as part of Java EE 6) by working around lacking functionalities from the CDI SPI at the cost of code readability or even removed features that are impossible to re-implement.
To avoid that, it is obviously possible to create a separate branch / module dedicated to porting the extension to the oldest possible CDI version, but then comes the packaging / distribution problem:
- You assign different versions to the branches, unfortunately that does not work for projects that include their own CDI extension into the same codeline (like Apache Camel, JBoss Infinispan, …) as it doesn’t make sense to impact the whole project versioning for one possible container / runtime among others possible,
- Or you create two artifacts / modules whose name (or classifier) somehow contains the CDI compatible version.
That’s not very ideal either, and in any case, that’s the end user burden to make the decision which artifact to choose from a list that will grow over time with CDI 2.0 and future CDI versions.
Which leads to my point... As there exists a way to add / veto annotated types and beans programmatically, one solution that will help addressing the above problems, both for the extension developers and users, would be to have the ability to add / veto extensions dynamically. That way, multiple version / part of the extension could be packaged into a single artifact and activated dynamically during the application initialisation phase based on some runtime criteria, in my use case the CDI environment version. The point here is not to discuss potential implementations, but we could imagine having an AfterExtensionDiscovery of BeforeTypeDiscovery lifecycle event from which adding or vetoing extensions would be possible, or some mechanisms in the beans.xml file to include / exclude an extension...
So before discussing implementation details, I’d like your opinion on that use case, whether it’s valid or other options exist.
Thanks,
Antonin
9 years, 2 months
EDR1 merged into master + asciidoctor sources cleaning
by Antoine Sabot-Durand
Hi all,
I just merged EDR1 to master (and kept a tag for master status before EDR1).
I also reviewed all Asciidoctor source file to switch their format to 1
sentence by line and switch to new format for literal in Asciidoctor.
Took me a few hours to be sure that spec before and after stays exactly the
same (detected 4 or 5 formatting errors in the process)
This new format will make pull requests easier to read : instead of having
a whole paragraph changed when a word is updated, only the matching
sentence will be affected.
Antoine
9 years, 2 months
[JBoss JIRA] (CDI-537) Event firing on JavaEE component classes- JPA entity listener
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-537?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-537:
----------------------------------
Yes, I think we should do some work on the spec level. Both the JPA and CDI specs should be aware of the chicken-and-egg problem during bootstrap - the CDI container must support injection of JPA components but JPA entity listeners must be able to inject CDI beans as well. In other words, the entity listeners should be instantiated after the CDI container is initialized. Thus, ProcessInjectionTarget events for these components must be fired before the listeners exist and then later on used by the JPA. Note that the JPA spec states:
bq. "The persistence provider is responsible for using the CDI SPI to create instances of the entity listener class"
> Event firing on JavaEE component classes- JPA entity listener
> -------------------------------------------------------------
>
> Key: CDI-537
> URL: https://issues.jboss.org/browse/CDI-537
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java EE integration
> Affects Versions: 1.2.Final
> Reporter: Emily Jiang
>
> In CDI 1.2 spec
> 11.5.7. ProcessInjectionPoint event
> The container must fire an event for every injection point of every Java EE component class
> supporting injection that may be instantiated by the container at runtime, including every managed bean declared using @ManagedBean, EJB session or message-driven bean, bean, interceptor or decorator.
> The JavaEE component classes are mentioned in JavaEE platform EE.5-1, which includes servlets, servlet filters, entity listeners etc.
> My concern is about entity listeners in JPA. Eclipse link has done all the injection for entity listeners. It does not fire the event, @See createEntityListenerAndInjectDependancies(...)
> JPA spec section 3.5.1 does not mention this event requirement. How can the eclipse cdi implementation satisfy the CDI spec?
> [1] http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundat...]
> I had an initial discussion with Jozef.
> Jozef wrote: "
> Doing this using purely CDI APIs can be a bit tricky. One option that will most likely work is to combine BeanManager.resolveObserverMethods() method with a custom implementation of ProcessInjectionTarget interface. That way you can resolve the matching observer methods and then call their notify() method to deliver the event. Exception handling needs to be implemented to match the spec.
> We should update the spec to define a more direct route and for the JPA spec to mention this requirement."
> My response:
> "+1 on revisiting this on the CDI spec. I think adding an additional method on the BeanManager api, e.g. fireProcessInjectionTarget would be good. Effectively, it is to promote this very method on WeldManager to BeanManager."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-383:
-----------------------------------
+1. But it's not only related to @SessionScoped. Basically @PreDestroy is not reliable for _all_ beans of passivating contexts as you can see in my @ViewScoped bean example.
> 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, 2 months
