[JBoss JIRA] (CDI-578) define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-578?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-578:
-------------------------------------
Fix Version/s: 2.0 .Final
> define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-578
> URL: https://issues.jboss.org/browse/CDI-578
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Fix For: 2.0 .Final
>
>
> The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111
> If you have an observer
> {code}
> public void clearCacheAfterTx((a)Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...}
> {code}
> and you fire the event
> {code}
> clearCacheEvent.fire(new ClearCacheEvent());
> {code}
> In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server.
> The problem is that you cannot enlisten a Synchronisation at the tx anymore.
> I think we should define/clarify how it should behave in the various phases.
> E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine.
> At the end we need a matrix of the the event phases + possible Exceptions
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-129:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
> Key: CDI-129
> URL: https://issues.jboss.org/browse/CDI-129
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Labels: F2F2016, application-scoped, visibility
> Fix For: TBD
>
>
> Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> We could (ab-)use @Singleton for that, but this is currently not well defined at all.
> Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-30) An API for managing built in contexts designed for other frameworks
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand updated CDI-30:
------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.0 (discussion))
> An API for managing built in contexts designed for other frameworks
> -------------------------------------------------------------------
>
> Key: CDI-30
> URL: https://issues.jboss.org/browse/CDI-30
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Nicklas Karlsson
> Assignee: John Ament
> Fix For: 2.0 .Final
>
>
> In order to allow CDI to play well in the general ecosystem, it needs to have SPIs. These SPIs need to allow other libraries to do things like register beans (CDI extensions), look up a bean manager, and get managed versions of its classes.
> CDI has no way currently to support a framework starting and stopping built in contexts. These built in contexts are not really clear in how they are started, other than the container is responsible for starting them. This means its near impossible for an external library which is not Java EE aware to start these built in contexts. Being able to reuse these contexts allow developers to build their beans once and reuse them in many use cases.
> These use cases may include:
> 1. Quartz Scheduler/CDI Integration. A Prototype of this is available in DeltaSpike, where jobs can be managed beans, by overriding the InstanceJobFactory, and can have contexts started via an annotation. To bring it a step further, Quartz, in order to mirror Java EE capabilities, may want to say that during the execution of a job, an instance of a request context is active. To do this, the developer should not need to do anything, but instead Quartz may automatically register a job listener that starts and stops the context (see: http://www.quartz-scheduler.org/documentation/quartz-2.2.x/cookbook/JobLi...)
> 2. Camel-CDI. Camel may want to say that during the execution of a route, a request context is active.
> 3. Netty/CDI (or any arbitrary network based server). During the reception of a message over TCP, a request is active. Likewise, for the entire TCP connection a session context is active.
> 4. Sparkjava/CDI. Assuming that sparkjava isn't running in a servlet container, during the execution of an arbitrary reactive method call, a request context is available for use.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
Cleaning the backlog for feature freeze
by Antoine Sabot-Durand
Hi all,
I made some housekeeping in our ticket in prevision of CDI 2.0 final
release.
You can now use the following filters in Jira:
- Targeted for 2.0 final [1]. It contains 27 tickets with 8 of them being
worked on. Contains feature and clarification that we should be able to
deliver for 2.0
- Discussed for 2.0 [2]. A remaining stock of tickets (9), that are still
under discussion. Some of them may make it for CDI 2.0
I created a new version "Discussed for 2.1" in which I put mostly tickets
linked to other specs or interesting one that can be fir in 2.0 release
If you think something important is missing, it's still time to add things
here.
Thanks for your feedbeck,
[1]: https://issues.jboss.org/browse/CDI-633?filter=12328604
[2]: https://issues.jboss.org/browse/CDI-631?filter=12328671
7 years, 6 months
[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-616:
-----------------------------------
> Do nothing but add clarification in the spec : Injection in transient field is not supported.
We probably are talking about thesame thing, but the wording is not quite as discussed on the ML as far as I interpret it.
Why should the injection itself not be supported? I think what we agreed on is that we just don't do anything for RE-injecting it in case of deserialisation.
At least that was I understood during our discussion. Not sure we need to clarify anything as this is standard Java behaviour: the developer is responsible to get back any transient fields himself by default.
> Injection point declared as transient is not useful
> ---------------------------------------------------
>
> Key: CDI-616
> URL: https://issues.jboss.org/browse/CDI-616
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Concepts
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
> Priority: Minor
> Fix For: 2.0 .Final
>
>
> An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes?
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise.
> =>
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach.
> Any other better suggestions?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-627:
-----------------------------------
plz review the pull request.
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg reassigned CDI-627:
---------------------------------
Assignee: Mark Struberg
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-627:
-------------------------------------
Sprint: Sprint 1
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-616:
-------------------------------------
Sprint: Sprint 1
> Injection point declared as transient is not useful
> ---------------------------------------------------
>
> Key: CDI-616
> URL: https://issues.jboss.org/browse/CDI-616
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Concepts
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
> Priority: Minor
> Fix For: 2.0 .Final
>
>
> An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes?
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise.
> =>
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach.
> Any other better suggestions?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
