From issues at jboss.org Fri May 4 02:33:01 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 4 May 2018 02:33:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570768#comment-13570768 ] Mark Struberg commented on CDI-702: ----------------------------------- The EE umbrella spec says that an application SHOULD provide isolation between WARs. There is no MUST though. Otoh the umbrella spec is rather clear that IF an app server chooses to provide isolation, then it also must provide it for all parts. Funnily right now one seems to get ProcessAnnotatedType for all classes (even from foreign WARs), but getBeans() later (at Runtime) does properly isolate. > 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.5.0#75005) From issues at jboss.org Fri May 4 02:42:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 4 May 2018 02:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570773#comment-13570773 ] Martin Kouba commented on CDI-702: ---------------------------------- bq. Funnily right now one seems to get ProcessAnnotatedType for all classes (even from foreign WARs), but getBeans() later (at Runtime) does properly isolate. Because {{BeanManager.getBeans()}} does refer [Inter-module injection|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#inter_module_injection] which follows accessibility 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.5.0#75005) From issues at jboss.org Fri May 4 04:10:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 4 May 2018 04:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570818#comment-13570818 ] Mark Struberg commented on CDI-702: ----------------------------------- [~mkouba] I would prefer to find real solutions for real problems. Not excuses by pointing to specs which we wrote *ourselves* and where we obviously failed in hindsight of real world problems... > 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.5.0#75005) From issues at jboss.org Fri May 4 04:44:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 4 May 2018 04:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570846#comment-13570846 ] Martin Kouba commented on CDI-702: ---------------------------------- First of all, I'm just trying to explain why the "funny" behavior and not to excuse anything. Also I don't think this is very "obvious failure". It could be very well a useful feature. But I don't want to start yet another @ApplicationScoped-like flame war. Anyway, pls describe your real world problem properly and feel free to propose a PR, eventually require a vote. > 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.5.0#75005) From issues at jboss.org Fri May 4 06:09:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 4 May 2018 06:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570926#comment-13570926 ] Matej Novotny commented on CDI-702: ----------------------------------- >From the comments I gather that people agree on current spec interpretation (that extensions are now allowed to observe everything) and the discussion is about changing that in spec. However, if we do that and twist it the other way around, you can then come back saying we _obviously failed_ by imposing unnecessary restrictions on extension observers. I am pretty sure other users would come back saying they have _real world problem_ because they now cannot observe events "globally" where they previously could (say hello to backwards compat. problems). To me it seems like it's just going one way or the other but you can always complain that the opposite should be go-to option... Besides I see current wording and interpretation as better because it allows you to integrate on a wider scale; being able to observe events from other WARs can be handy. > 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.5.0#75005) From issues at jboss.org Fri May 4 06:40:03 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 4 May 2018 06:40:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571364#comment-13571364 ] Mark Struberg commented on CDI-702: ----------------------------------- {quote}From the comments I gather that people agree on current spec interpretation (that extensions are now allowed to observe everything) and the discussion is about changing that in spec.{quote} No, The spec defines that Beans must adhere to isolation rules. But 1.) The spec says nothing about ProcessAnnotatedType and scanning in general. So this is undefined (ternary logic applies). 2.) According to the rules you pointed to (5.1.4) ProcessBean must also not get fired for a Bean of a foreign WAR. So at least this one is rather likely an impl bug, isn't? {quote}I am pretty sure other users would come back saying they have real world problem because they now cannot observe events "globally" where they previously could (say hello to backwards compat. problems).{quote} That's not portable right now anyway. There are 2 possible ways a container could treat this: a.) send the container events to extensions which are shared (an Extension in the ear lib/*.jar or an/ejb.jar would get all classes) b.) do a proper hierarchic BeanManager setup. > 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.5.0#75005) From issues at jboss.org Fri May 4 06:42:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 4 May 2018 06:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571364#comment-13571364 ] Mark Struberg edited comment on CDI-702 at 5/4/18 6:41 AM: ----------------------------------------------------------- {quote}From the comments I gather that people agree on current spec interpretation (that extensions are now allowed to observe everything) and the discussion is about changing that in spec.{quote} No, The spec defines that Beans must adhere to isolation rules. But 1.) The spec says nothing about ProcessAnnotatedType and scanning in general. So this is undefined (ternary logic applies). 2.) According to the rules you pointed to (5.1.4) ProcessBean must also not get fired for a Bean of a foreign WAR. So at least this one is rather likely an impl bug, isn't? {quote}I am pretty sure other users would come back saying they have real world problem because they now cannot observe events "globally" where they previously could (say hello to backwards compat. problems).{quote} That's not portable right now anyway. There are 2 possible ways a container could treat this: a.) send the container events to extensions which are shared (an Extension in the ear lib/*.jar or an/ejb.jar would get all classes) b.) do a proper hierarchic BeanManager setup. To make it more clear: my main worry is about having an Extension in WAR1 which also gets all events for a class in WAR2. This should clearly not happen. Extensions in a shared classpath might also be a problem, but we might probably be able to split those 2 cases. was (Author: struberg): {quote}From the comments I gather that people agree on current spec interpretation (that extensions are now allowed to observe everything) and the discussion is about changing that in spec.{quote} No, The spec defines that Beans must adhere to isolation rules. But 1.) The spec says nothing about ProcessAnnotatedType and scanning in general. So this is undefined (ternary logic applies). 2.) According to the rules you pointed to (5.1.4) ProcessBean must also not get fired for a Bean of a foreign WAR. So at least this one is rather likely an impl bug, isn't? {quote}I am pretty sure other users would come back saying they have real world problem because they now cannot observe events "globally" where they previously could (say hello to backwards compat. problems).{quote} That's not portable right now anyway. There are 2 possible ways a container could treat this: a.) send the container events to extensions which are shared (an Extension in the ear lib/*.jar or an/ejb.jar would get all classes) b.) do a proper hierarchic BeanManager setup. > 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.5.0#75005) From issues at jboss.org Fri May 4 07:05:01 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 4 May 2018 07:05:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571388#comment-13571388 ] Martin Kouba commented on CDI-702: ---------------------------------- bq. 2.) According to the rules you pointed to (5.1.4) ProcessBean must also not get fired for a Bean of a foreign WAR. No. 5.1.4 only applies to injection. I'll say it once again and for the last time: the spec does not define any visibility boundaries for events and extensions are defined as application wide components. > 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.5.0#75005) From issues at jboss.org Sat May 5 06:01:01 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Sat, 5 May 2018 06:01:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571800#comment-13571800 ] Mark Struberg commented on CDI-702: ----------------------------------- But that also would mean that em.fire in WAR1 would also be observed in WAR2? That's maybe in sync with the spec but it doesn't seem correct from a user pov. And then again IF em.fire is isolated, then this would contradict the spec according to your interpretation. Maybe my words have not been chosen carefully enough. So I try to describe my pov again: Our main concern should not be whether something is guaranteed by the spec but rather whether it makes sense from a real world user scenario. And only then we should check whether we could implement this in a useful way and whether this might contradict older versions of the spec. I know we kind of left this out until very late in CDI 1.0 where we mainly focused in webapps only. But even in CDI 1.0 we have the following sentence in our spec which allowed for adopting to modularity: {quote}Support for Java EE modularity and the Java EE component architecture?the modular structure of a Java EE application is taken into account when resolving dependencies between Java EE components{quote} > 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.5.0#75005) From issues at jboss.org Mon May 21 15:27:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 21 May 2018 15:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-725) SeInitializer should have an addPackage(boolean, String) In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-725: -------------------------------------- Summary: SeInitializer should have an addPackage(boolean, String) Key: CDI-725 URL: https://issues.jboss.org/browse/CDI-725 Project: CDI Specification Issues Issue Type: Feature Request Components: Java SE Integration Affects Versions: 2.0 .Final Reporter: Romain Manni-Bucau For now addPackage uses Package or Class parameter. Class parameter is not great because there are packages without anything except other packages and Package is pretty strict for several use cases because it can't be created programmatically and requires a class to get an instance. Since all implementations convert the Package instance to a String to load it, it would be very helpful to add it directly in the API IMHO. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue May 29 11:04:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 29 May 2018 11:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-726: -------------------------------------- Summary: Deprecate before dropping CDI.setCDIProvider Key: CDI-726 URL: https://issues.jboss.org/browse/CDI-726 Project: CDI Specification Issues Issue Type: Feature Request Components: Java SE Integration Affects Versions: 2.0 .Final Reporter: Romain Manni-Bucau Priority: Blocker CDI.setCDIProvider allows to switch the cdi provider at *any* time by *anyone*. This lead to issues integrating multiple libraries doing it + is not a real user facing API, it is actually a server internal. Proposal is to deprecate the method, remove its implementation (always throw an IllegalStateException or just do a noop) and finally drop the method after one or two releases since it can't really be used except for very simple apps. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue May 29 11:24:02 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 29 May 2018 11:24:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583731#comment-13583731 ] Martin Kouba commented on CDI-726: ---------------------------------- Hm, in CDI 1.2 it was only possible to set the provider once and I remember there was some legal use case for this method (OSGi or something like that). You're right that in CDI 2.0 anyone can set it anytime. The logic seems to be modified in this commit: https://github.com/cdi-spec/cdi/commit/14cd36abb4d039212cf21521a46755b15f4e0a1c#diff-03e83766e93415c9ba16a9dfb42a5ac5. [~antoinesabot-durand] Do you remember the details? > Deprecate before dropping CDI.setCDIProvider > -------------------------------------------- > > Key: CDI-726 > URL: https://issues.jboss.org/browse/CDI-726 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Romain Manni-Bucau > Priority: Blocker > > CDI.setCDIProvider allows to switch the cdi provider at *any* time by *anyone*. This lead to issues integrating multiple libraries doing it + is not a real user facing API, it is actually a server internal. > Proposal is to deprecate the method, remove its implementation (always throw an IllegalStateException or just do a noop) and finally drop the method after one or two releases since it can't really be used except for very simple apps. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue May 29 11:31:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 29 May 2018 11:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583734#comment-13583734 ] Martin Kouba commented on CDI-726: ---------------------------------- And yes, this method should not be used by a user/library/framework. Normally, a CDI impl should use a service provider and in rare cases an integrator may set an impl-specific provider manually. > Deprecate before dropping CDI.setCDIProvider > -------------------------------------------- > > Key: CDI-726 > URL: https://issues.jboss.org/browse/CDI-726 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Romain Manni-Bucau > Priority: Blocker > > CDI.setCDIProvider allows to switch the cdi provider at *any* time by *anyone*. This lead to issues integrating multiple libraries doing it + is not a real user facing API, it is actually a server internal. > Proposal is to deprecate the method, remove its implementation (always throw an IllegalStateException or just do a noop) and finally drop the method after one or two releases since it can't really be used except for very simple apps. -- This message was sent by Atlassian JIRA (v7.5.0#75005)