[JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ]
Tomas Remes commented on CDI-78:
--------------------------------
[~antoinesabot-durand] This is still unclear to me what should happen when I inject {{InjectionPoint}} in decorator. Section {{6.5.4. Contextual reference for a bean}} states:
{quote}
The container must ensure that every injection point of type InjectionPoint and qualifier @Default
of any dependent object instantiated during this process receives:
• an instance of InjectionPoint representing the injection point into which the dependent object
will be injected, or
• a null value if it is not being injected into any injection point.
{quote}
Will I get null or instance of {{InjectionPoint}} for the IP injected into decorator?
> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-78
> URL: https://issues.jboss.org/browse/CDI-78
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Labels: F2F2016
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
What, if any, guarantees are made about invoking asynchronous event observer methods?
by Laird Nelson
I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
If I fire an asynchronous event without any special notification options,
my understanding is that the container will arrange for that event to be
delivered to asynchronous observers.
Is (appropriate) asynchronous observer method invocation guaranteed to
happen at some point? Section 10.2.2 seems to hint that it is:
"Event fired [sic] with the fireAsync() method is [sic] fired
asynchronously. *All the resolved asynchronous observers* (as defined in
Observer resolution) *are called* in one or more different threads."
To me, this says that if I use fireAsync() to fire an event, then if I have
a (resolved) asynchronous observer method for it it will be notified before
the container closes no matter what.
(I believe I am observing a race condition somewhere in here that might
show that Weld's default asynchronous event delivery machinery does not
actually get around to delivering the event I've queued up before the
container closes. Sometimes the event is received, sometimes it is not.
Obviously if there is no such guarantee this could be permitted behavior.)
Best,
Laird
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang edited comment on CDI-702 at 5/22/17 5:27 AM:
----------------------------------------------------------
[~meetoblivion] The issue is that the CDI extension does something different from other classes in the ear. e.g.
{noformat}
myApp.ear
lib\myLib.jar (LibExtensionA.class, LibOne.class)
myWarA.war (WarAExtension.class, myWarAServlet.class)
myWarB.war (WarBExtension.class, myWarBServlet.class)
{noformat}
The myWarAServlet will not be able to see classes in myWarB.war. Why are the CDI extensions special? How come all extension classes can see everything in the ear. Basically, my argument is that CDI extensions should follow the same classloading criteria instead of defining itself visibility rules with even being documented.
was (Author: emilyj):
[~meetoblivion] The issue is that the CDI extension does something different from other classes in the ear. e.g. {{myApp.ear
lib\myLib.jar (LibExtensionA.class, LibOne.class)
myWarA.war (WarAExtension.class, myWarAServlet.class)
myWarB.war (WarBExtension.class, myWarBServlet.class)}}
The myWarAServlet will not be able to see classes in myWarB.war. Why are the CDI extensions special? How come all extension classes can see everything in the ear. Basically, my argument is that CDI extensions should follow the same classloading criteria instead of defining itself visibility rules with even being documented.
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
> lib\myLib.jar (LibExtensionA.class, LibOne.class)
> myWarA.war (WarAExtension.class, myWarAServlet.class)
> myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-702:
---------------------------------
[~meetoblivion] The issue is that the CDI extension does something different from other classes in the ear. e.g. {{myApp.ear
lib\myLib.jar (LibExtensionA.class, LibOne.class)
myWarA.war (WarAExtension.class, myWarAServlet.class)
myWarB.war (WarBExtension.class, myWarBServlet.class)}}
The myWarAServlet will not be able to see classes in myWarB.war. Why are the CDI extensions special? How come all extension classes can see everything in the ear. Basically, my argument is that CDI extensions should follow the same classloading criteria instead of defining itself visibility rules with even being documented.
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
> lib\myLib.jar (LibExtensionA.class, LibOne.class)
> myWarA.war (WarAExtension.class, myWarAServlet.class)
> myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-702:
--------------------------------
Thanks Emily, makes it clearer.
I'm not convinced this is a CDI issue. For EE, we don't really specify the visibility, that's part of the EE umbrella spec. I actually suspect your app server in this case is defining the classes to look for.
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
> lib\myLib.jar (LibExtensionA.class, LibOne.class)
> myWarA.war (WarAExtension.class, myWarAServlet.class)
> myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-702:
---------------------------------
My view is that the observable should follow the classloading visibility rules. Why extensions are special? This violent the classloading rules.
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
> lib\myLib.jar (LibExtensionA.class, LibOne.class)
> myWarA.war (WarAExtension.class, myWarAServlet.class)
> myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-702:
---------------------------------
Here are Martin's and Antoine's comments during our previous discussion:
Martin:
{noformat}
1. I'm not talking about class loading and using classes but observing
ProcessAnnotatedType event -> any WAR can see PAT type and is able to
observe it.
2. The CDI spec does not define any visibility boundaries for events
(unlike for typesafe resolution). See for example CDI-518.
So yes, from EE.8.3.1 Web Container Class Loading Requirements it is
clear that portable apps must not depend on having access to classes
from the second WAR.
On the other hand, CDI extensions are defined as application wide
components which should be imho able to process container lifecycle
events from all bean archives.
{noformat}
Antoine:
{noformat}
Class loading in Java EE platform is far from being a consensus. Vendors are doing different things here, so definition of class visibility is not universal.
Visibility problem in EAR were never solved in CDI for this reason, see https://issues.jboss.org/browse/CDI-129 to have an history on that.
When we relaunched this discussion during CDI 2.0, conclusion was that we agreed on our disagreement with OWB team and that clarification should be done at Java EE spec level (I let you dig in ML archive to check the discussion we had with Mark Struberg at that time).
Even if CDI spec tries to cover all, there are still small differences between Weld and OWB making the switch from one to the other not transparent every time.
I’m sorry you fall in one of these gap, but that doesn’t make Weld buggy, only put one of this difference into light.
Antoine
{noformat}
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
> lib\myLib.jar (LibExtensionA.class, LibOne.class)
> myWarA.war (WarAExtension.class, myWarAServlet.class)
> myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-702:
---------------------------------
John, I provided an example. Please let me know if you still feel confused.
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
> lib\myLib.jar (LibExtensionA.class, LibOne.class)
> myWarA.war (WarAExtension.class, myWarAServlet.class)
> myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang updated CDI-702:
----------------------------
Description:
We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
e.g.
myApp.ear
lib\myLib.jar (LibExtensionA.class, LibOne.class)
myWarA.war (WarAExtension.class, myWarAServlet.class)
myWarB.war (WarBExtension.class, myWarBServlet.class)
In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
LibOne, myWarAServlet and myWarBServlet.
This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
was:
We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> e.g.
> myApp.ear
> lib\myLib.jar (LibExtensionA.class, LibOne.class)
> myWarA.war (WarAExtension.class, myWarAServlet.class)
> myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of
> LibOne, myWarAServlet and myWarBServlet.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-702 at 5/19/17 7:27 AM:
-----------------------------------------------------------
For the record: the *Observer resolution* section in the CDI spec does not mention "accessibility" or "observability" at all (unlike dependency injection). An event is delivered to an observer method if it belongs to an enabled bean and an event type is assignable. Also accessibility rules do not help e.g. if there is an extension with a similar observer:
{code:java}
void observe(ProcessAnnotatedType<?> event) {
if (event.getAnnotatedType().isAnnotationPresent(Named.class)) {
event.veto();
}
}
{code}
It should be able to observe all PAT events for all types in a CDI application (of course, we assume the Weld interpretation of {{@ApplicationScoped}}). That's what CDI spec currently requires.
So this issue is more about defining boundaries for events delivery.
was (Author: mkouba):
For the record: the *Observer resolution* section in the CDI spec does not mention "accessibility" or "observability" at all (unlike dependency injection). An event is delivered to an observer method if it belongs to an enabled bean and an event type is assignable. Also accessibility rules do not help e.g. if there is an extension with a similar observer:
{code:java}
void observe(ProcessAnnotatedType<?> event) {
if (event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
event.veto();
}
}
{code}
It should be able to observe all PAT events for all types in a CDI application (of course, we assume the Weld interpretation of {{@ApplicationScoped}}). That's what CDI spec currently requires.
So this issue is more about defining boundaries for events delivery.
> Observers in CDI extensions can see classes they should not be able to
> ----------------------------------------------------------------------
>
> Key: CDI-702
> URL: https://issues.jboss.org/browse/CDI-702
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
> Reporter: Emily Jiang
> Priority: Critical
>
> We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension class can see everything in an .ear regardless where the extension class resides. It completely ignores classloading hierarchy.
> This kind of contradicts with the classloading rules, where separate .war archives packaged under the same .ear should not be able to see each other's class by default, unless they both use the same classloader.
> We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that CDI spec is unclear on the "observer resolution". I would like to relaunch the discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months