[JBoss JIRA] (CDI-538) Fix parameterized types discrepancies
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-538?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-538:
-------------------------------------
Reporter: Antonin Stefanutti (was: Antoine Sabot-Durand)
> Fix parameterized types discrepancies
> -------------------------------------
>
> Key: CDI-538
> URL: https://issues.jboss.org/browse/CDI-538
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.2.Final
> Reporter: Antonin Stefanutti
> Fix For: 2.0-EDR1
>
>
> In the SPI, the spec states the following:
> {quote}
> * For a producer method with method return type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerMethod<T, X>}}.
> * For a producer field with field type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerField<T, X>}}.
> {quote}
> But the Javadoc and impl behavior is
> {quote}
> * For a producer method with method return type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerMethod<T, X>}}.
> * For a producer field with field type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerField<T, X>}}.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (CDI-538) Fix parameterized types discrepancies
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-538:
----------------------------------------
Summary: Fix parameterized types discrepancies
Key: CDI-538
URL: https://issues.jboss.org/browse/CDI-538
Project: CDI Specification Issues
Issue Type: Bug
Components: Portable Extensions
Affects Versions: 1.2.Final
Reporter: Antoine Sabot-Durand
In the SPI, the spec states the following:
{quote}
* For a producer method with method return type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerMethod<T, X>}}.
* For a producer field with field type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerField<T, X>}}.
{quote}
But the Javadoc and impl behavior is
{quote}
* For a producer method with method return type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerMethod<T, X>}}.
* For a producer field with field type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerField<T, X>}}.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (CDI-538) Fix parameterized types discrepancies
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-538?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-538:
-------------------------------------
Fix Version/s: 2.0-EDR1
> Fix parameterized types discrepancies
> -------------------------------------
>
> Key: CDI-538
> URL: https://issues.jboss.org/browse/CDI-538
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0-EDR1
>
>
> In the SPI, the spec states the following:
> {quote}
> * For a producer method with method return type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerMethod<T, X>}}.
> * For a producer field with field type {{X}} of a bean with bean class {{T}}, the container must raise an event of type {{ProcessProducerField<T, X>}}.
> {quote}
> But the Javadoc and impl behavior is
> {quote}
> * For a producer method with method return type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerMethod<T, X>}}.
> * For a producer field with field type {{T}} of a bean with bean class {{X}}, the container must raise an event of type {{ProcessProducerField<T, X>}}.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
On @RequestScoped hack
by Jozef Hartinger
Hi all,
unfortunately I did not make it to the meeting yesterday. After reading
the transcript I found out that the @RequestScoped hack is still being
added to the EDR. What do I mean by "@RequestScoped hack"?
By that I am referring to the following part of the spec:
"
In Java SE:
The request scope is active during any method invocation.
The request context is destroyed when the container is shut down.
"
This is vague, almost undefined and not correctly implementable. Most
importantly, everyone seems to agree that it would be a bad idea for
this to end up in the final spec. Instead, it is supposed to be replaced
entirely by ContextControl API (https://issues.jboss.org/browse/CDI-530)
post EDR1.
Yet, we are adding this hack to EDR1 for the meantime. Why? The only
argument to back this was "supporting existing libraries and applications".
That seems reasonable, doesn't it? Well, no. Antoine took a detailed
look into probably the most prominent CDI library - DeltaSpike. Yes, you
can find @RequestScoped beans in DeltaSpike. You can find Servlet
artifact producers, JSF view root and navigation handlers, etc. And
that's it. Nothing one could really use outside of the EE stack.
That's not a coincidence. When a user marks a bean as @RequestScoped we
can assume they do it for a reason. The reason most likely would be to
scope the state per "task" (often HTTP request processing) and isolate
the state from the state of other tasks. That's very different from the
@Singleton-like behavior that the @RequestScoped hack adds. Therefore,
even if a library exists that relies on @RequestScoped it is not going
to work properly anyway. The @RequestScoped hack just suppresses a fast
failure and trades it for weird state inconsistencies later.
Another part of the argument is "existing applications". More specifically:
"struberg: well, I have a few customers with 10k++ classes. And some
core components use it heavily"
Does the @RequestScoped hack really address customers' problem? Remember
that the @RequestScoped hack is planned to be temporary and replaced
with proper context control post EDR1.
Are those customers planning to migrate to EDR1 implementation (Weld
Alpha probably) before the spec gets context control? Do they expect to
take their "10k++ class" Java EE applications, throw the EE container
out entirely and run the *unmodified* application in a plain Java SE
environment with CDI SE? Will their apps work even if their
@RequestScoped beans start behaving like singletons?
Probably not, right?
And then we have early adopters of CDI 2.0. Why should they be exposed
to magical hacks that we know are going to disappear later?
And let's not forget that:
* CDI implementations already have their own APIs for controlling
contexts that can be used if needed
* A CDI implementation may add such hack by itself - no need to have it
the spec temporarily
Therefore, I cannot see a single reason for polluting the spec with
temporary hacks.
Jozef
9 years, 6 months
Tomorrow's meeting Agenda
by Antoine Sabot-Durand
Hi Guys,
Tomorrow, we really need to close EDR1 a go for submission. It should be possible since our last discussion point is for Request Context behavior in SE.
I’d like also to set the final date of our F2F meeting in Paris (18th or 25th September)
Regarding the spec, I think that it would be nice to go for Quick Win tickets in Jira to have a rhythm change after the big features we worked on since octobre.
It could be great if you could take one or two ticket that you think are quick wins ones and send me them to discuss during the meeting.
What is a quick win ticket? A ticket that you think obvious and easy to solve regarding adoption of other EG members and way to solve it.
We’ll check during the meeting if your perception of quick win is shared among us ;).
So the agenda is:
1) Closing the EDR1
2) Closing discussion around F2F date
3) Discuss a first list of quick win tickets. Please send your wish list to me
Antoine
9 years, 6 months
[JBoss JIRA] (CDI-537) Event firing on JavaEE component classes- JPA entity listener
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-537?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang updated CDI-537:
----------------------------
Affects Version/s: 1.2.Final
Description:
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."
> 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.3.15#6346)
9 years, 6 months
