[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg updated CDI-129: ------------------------------ Description: 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. was: 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- yes, might well do that. This also plays together with the BDA part in CDI-18. Basically all the EAR and EE deployment stuff will need a few rounds of thinking + reviews to refine it I fear. This also is tightly coupled with any EE7 work which goes into this area. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- It might well be that the spec is contradicting. But however we turn this, the fact remains that there are 2 different scopes needed. 1 Webapplication scope and 1 ear scope. I doubt that the original intention of @ApplicationScoped was for EAR usage! It got added way later, but the historic evolution of the spec, and the fact that it heavily and easily integrates with EJBs allows that we just use EJBs for those cases you mentioned. We can still use EJBs for those things. If we would interpret @ApplicationScoped your way, then it would behave *heavily* different depending if the war gets used/tested standalone or as part of an EAR. That sounds just plain wrong imo. Btw, it IS possible to fulfil the the spec. In OWB we handle JMS, and quartzed jobs, etc as own 'applications' inside the EAR. So they get an own BeanManager and can even have their own Extensions. See what I mean? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- I can say with 99.9% certainty that Gavin (at least) intended the @ApplicationScoped to be "ear scoped" when deploying inside an EAR. Unfortunately we can't easily go back and check. Mark, can you explain what you mean by it behaving differently in this situation. As I see it, it actually is more consistent to make it work like this. Regarding {quote} Btw, it IS possible to fulfil the the spec. In OWB we handle JMS, and quartzed jobs, etc as own 'applications' inside the EAR. So they get an own BeanManager and can even have their own Extensions. See what I mean? {quote} this does seem somewhat orthogonal to the question. In Weld an EJB jar would also get it's own BeanManager (and it should get it's own extensions, this is a bug in Weld right now) but it shares the Application context with all other modules in the application. So unless you can clarify what you mean here, I think we can ignore this. Marius, thanks for digging up those references, I think with those we can be quite confident that that the spec intends @ApplicationScoped to be "ear scoped" and that the reference to the Servlet spec was a mistake. In particular the comment "in an application deployed as an ear" indicates that the CDI spec regards an EAR as an application, and that coupled with the comment "the application context is shared ... within the same application" does indicate that the context spans the entire ear. To me, this is a stronger statement than "represent the standard scopes defined by the Java Servlets specification" which seems somewhat more descriptive. Mark, happy to consider adding an @WebApplicationScoped, and we should definitely clarify what @ApplicationScoped means. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- Regarding the @ApplicationScoped would behave different if standalone or in an EAR: Imagine 2 WebApps, both using an @ApplicationScoped ConfigurationBean. If the 2 webapps would get the same instance, then they would each other override their settings. This is really highly dangerous! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Mark, it's *not* "absolutely clear" from the CDI specification that this was the intent, if it were we wouldn't even be having this discussion ;-) We also can't base decisions on you saying "it's absolutely clear to me", we need to base them on facts ;-). So we have to leave aside such subjective statements. I understand the concerns about the behaviour changing between war and ears for some who have interpreted the spec one way, however this runs both ways. So this argument is essentially nullified in this discussion (an app which assumed one will stop working when we require the other). So far, I believe the case for it being interpreted as war scoped are a) 2.4.1 "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7, “Context management for built-in scopes” represent the standard scopes defined by the Java Servlets specification." b) That other specs in Java EE (namely JSF, JAX-RS, JAX-WS) refer to the "application scope" as scoped to the war (could you provide references to their specs for this) and as ear scoped a) that the spec describes an ear as an application, and says that the application context is shared across an application So to summarize: * the spec is clear that the application context should be shared across the "application" * the confusion is around what "application" means in the context of an ear * in one place the CDI spec mentions that the scopes "represent" those from the servlet spec, implying that the application means war scoped * in another place the CDI spec mentions that the ear represents the application. I think we need to gather two more opinions: * what was the original intent (I'll ping Gavin) * how does Java EE define "application" in an ear (I'll ping Linda and Bill) Mark, is this a fair summary from your side of the argument? I want us to agree on a summary so that we can move forward with a discussion about which course to take, rather than get stuck in debating the spec ;-) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Gerhard Petracek commented on CDI-129: -------------------------------------- actually @Singleton isn't really defined from a cdi perspective (compared to @ApplicationScoped) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Gerhard, no @Singleton is defined by the @Inject spec, not CDI at all. Redefining what it means would be confusing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Hmm. Yes, this is a pain ;-) Not sure what to do about it that actually is legal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Gerhard Petracek commented on CDI-129: -------------------------------------- agreed. however, since cdi is based on jsr330 we should at least define the difference between @Singleton and @ApplicationScoped -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- Pete, that sounds to me like what @Singleton was originally intended. Because in this case, the scope annotation alone doesn't solely define the lifecycle and visability of the bean, isn't? That might come down to what Gerhard meant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Marius Bogoevici commented on CDI-129: -------------------------------------- Pete said: {quote} In fact, this makes me wonder if there isn't an "obvious" solution staring us in the face? If we clarify that @ApplicationScoped means "shared across the ear" and also that the same bean class packaged in two locations which are not visible to one another (e.g. warA and war B) and cannot share state. Now we provide both options of ear scoped state and war scoped state, and the state is only shared if the bean class is packaged in a shared library or shared module (e.g. ejb module). {quote} This is correct and will reflect the preservation of behaviour when WARs are packaged inside EARs. At the same time please note that the deployment of the same class in multiple archives within the same deployment is deemed non-portable. So perhaps we can add a clause indicating that non-portability is an issue here *if the beans from different archives are visible at the same time*. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- Probably because of the heavily underspecified classloader behaviour in EE in this area? I was really confused about this too also. Because the Servlet spec (which the EE umbrella spec references prominently) imo _exactly_ defines that WebApplications must not interfere with other WebApplications but must be isolated well from each other. But most old EE servers (JBoss4 and 5 are perfect examples for this, as are the old WebLogics) ship with almost no isolation at all it seems! I actually never understood why they behave this way as _default_! @Marius: A Bean can only be used in a shared library if it's type is available on the shared classpath too. E.g. in a ejb-jars lib. And even if one webapp uses an @Alternative which is only available in this very one webapp, then there is no problem. Because injecting an @ApplicationScoped bean will still give you the contextual reference (the proxy). They simply refer to different contextual instances. There is really not much difference to a @SessionScoped bean of which it's class is in a shared ejb-jars lib. Or am I overlooking something? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- You are right, if the EE container does not implement the suggestions of the first paragraph of JSR-316 EE.8.3.1 but decides to use reduced or no classloader isolation at all then 'non-portable behaviour occurs'. I personally consider this an insane scenario, and the EE-7 spec should find very clear words that this is crap and should only be used in exceptional cases, e.g. for backward compatibility with old projects ;) For the (web) @ApplicationScoped only applying to one webapp - this is also possible if there is no classloader isolation at all. For handlig this case in OpenWebBeans, we are just setting the 'one' @ApplicationScoped for a certain request to a ThreadLocal (See OWBs WebContextsService - we are doing this via a RequestListener subsequently via initRequestContext() ). Remember that we have plugable lifecycle handlers in OWB. This would not be necessary if there is a well defined ClassLoader isolation in place (as suggested - we could then just use the ContextClassLoader in this case) but this works really well with very old WebLogic servers in a big swiss bank already ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir edited comment on CDI-129 at 5/18/11 5:41 AM: -------------------------------------------------------- {quote} But most old EE servers (JBoss4 and 5 are perfect examples for this, as are the old WebLogics) ship with almost no isolation at all it seems! I actually never understood why they behave this way as default! {quote} Believe it or not, older versions of JBoss AS (than 4) did provide more isolation by default, but by user request the isolation was downgraded. Also worth pointing out that JBoss AS 4 and 5 did support much stronger isolation if you enabled it (we always recommended you did with Seam, and enabled it automatically with Weld so I always forget this was the default!). {quote} @Marius: A Bean can only be used in a shared library if it's type is available on the shared classpath too. E.g. in a ejb-jars lib. And even if one webapp uses an @Alternative which is only available in this very one webapp, then there is no problem. Because injecting an @ApplicationScoped bean will still give you the contextual reference (the proxy). They simply refer to different contextual instances. There is really not much difference to a @SessionScoped bean of which it's class is in a shared ejb-jars lib. {quote} I'm a little lost in this sentence... What are you trying to say? Jens/Marius, I think your point is a very reasonable one for the spec. Of course, we would need an FAQ explaining the details of this ;-) Mark, please take this comment to the EE expert group, as you know we can only decide on CDI here ;-) This proposal is certainly implementable, no concerns there. Gerhard, we all agree with this rhetoric here (no real need to repeat it), we just need to find a solution that (a) makes sense technically and (b) works in the environment we are in. What is proposed does make sense (to me) and does work technically except in the case that people use non-isolated classloading, which EE keeps as an option for backwards compatibility. IOW what we have is a solution that makes sense with the recommended deployment model (isolated classloading), but we need to include, in the spec, a note about non-portability for the backwards compatible non-isolated classloading case. was (Author: petemuir): {quote} But most old EE servers (JBoss4 and 5 are perfect examples for this, as are the old WebLogics) ship with almost no isolation at all it seems! I actually never understood why they behave this way as default! {quote} Believe it or not, older versions of JBoss AS (than 4) did provide more isolation by default, but by user request the isolation was downgraded. Also worth pointing out that JBoss AS 4 and 5 did support much stronger isolation if you enabled it (we always recommended you did with Seam, and enabled it automatically with Weld so I always forget this was the default!). {quote} @Marius: A Bean can only be used in a shared library if it's type is available on the shared classpath too. E.g. in a ejb-jars lib. And even if one webapp uses an @Alternative which is only available in this very one webapp, then there is no problem. Because injecting an @ApplicationScoped bean will still give you the contextual reference (the proxy). They simply refer to different contextual instances. There is really not much difference to a @SessionScoped bean of which it's class is in a shared ejb-jars lib. {quote} I'm a little lost in this sentence... What are you trying to say? Jens/Marius, I think your point is a very reasonable one for the spec. Of course, we would need an FAQ explaining the details of this ;-) Mark, please take this comment to the EE expert group, as you know we can only decide on CDI here ;-) Gerhard, we all agree with this rhetoric here (no real need to repeat it), we just need to find a solution that (a) makes sense technically and (b) works in the environment we are in. What is proposed does make sense (to me) and does work technically except in the case that people use non-isolated classloading, which EE keeps as an option for backwards compatibility. IOW what we have is a solution that makes sense with the recommended deployment model (isolated classloading), but we need to include, in the spec, a note about non-portability for the backwards compatible non-isolated classloading case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- As we are all now in consensus, I will draft a proposed change to the CDI spec which clarifies the behaviour of @ApplicationScoped in ears. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-129: -------------------------- Summary: Clarify behaviour of @ApplicationScoped in EARs (was: introduce @EnterpriseScoped (or similar)) Issue Type: Clarification (was: Feature Request) Altering issue title and changing to clarification to reflect outcome of design discussion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Gerhard Petracek commented on CDI-129: -------------------------------------- pete - no there was a different statement: just specifying a recommendation (as suggested afterwards) isn't enough (imo) ... that was the reason for my answer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-129: ------------------------------------ The Final Release of JSR-299 does not define anything to do with @ApplicationScoped in 6.5.2. @ApplicationScoped is defined in 6.7.3 and states: "The application context is shared between all servlet requests, web service invocations, EJB remote method invocations, EJB asynchronous method invocations, EJB timeouts and message deliveries to message-driven beans that execute within the same application. The application context is destroyed when the application is shut down." This means that @ApplicationScoped is shared over a whole ear, and is not per war (there may not even be a war in the ear). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- Yes stu, I confused the paragraphs. What I meant was which clearly says 1 contextual instance for each webapp. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- coming back to Stuarts comment: Ok, if you take it so word for word: in this case, since it doesn't say 'per EAR', we obviously must share the ApplicationContext even across different EARs on the same Server? See, it doesn't specify the EAR in this paragraph, so the only specific definition is in 2.4.1. @Jozef: I think we already clarified somewhere that events must only be sent to active Contexts. This e.g. happens if you try to send an event in a ServletFilter to a JSF related Context. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-129: -------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- You are mixing way too many things here. Firstly, here is how the modularity work in CDI: Let's have two bean archives: A and B. Module A is accessible from B (A it might represent a shared library in an ear). Module B is not accessible from A (B it might represent a web app). Let A define the following classes: {code:JAVA} public interface X {} public class A implements X {} {code} Let B define the following class: {code:JAVA} @Alternative public class B extends A {} {code} Class B is an enabled alternative in module B. Alternatively, B may be a specializing class (not alternative at all). Now suppose there are classes Foo and Bar, each of them injecting X, Foo is located in module A and Bar is located in module B. If Foo invokes a method on the injected instance, it will always be invoked on an instance of A (and not instance of B). if Bar invokes a method on the injected instance, it will always be invoked on an instance of B. This is regardless of scope of bean A and B (no matter whether client proxies are used or not). There is no randomness and there is not ClassNotFoundException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- Let's say this is your view and is one of n possible interpretations of the spec wording. Due to the well defined TCCL behaviour in the EE umbrella spec it is perfectly viable that A might see B IF it is invoked in a request of the webapp containing A. So technically from the EE spec there is NO such restriction you mentioned. It's just easier for a container vendor to implement. And your example is also _perfectly_ broken from a user experience pov! If you inject X in a shared jar you would get another contextual instance than injecting X in a JSF backing bean that way! Hell, this is SICK SICK SICK! No user would be able to use that stuff! I have a @Inject User usr; in my MailFormular backing bean and the same code in my MailService and would get 2 DIFFERENT users? You're kidding me, right? The are only 2 practical ways to do this properly for users: 1.) restrict any @Specializes or @Alternative of an interface to the visibility area it got defined in. In other words if you have a User interface in a shared jar in your EAR we disallow @Specializes or @Alterative in any WAR. But again, this is NOT defined in CDI-1.0 yet! 2.) use a proper proxy which only proxies the injection point type (in our case X) and not only resolve the contextual instance but also the proper Bean<X> dynamically on each invocation IF it got injected into a 'broader scoped bean'. And here we come back to my first argument: by keeping the specified behaviour of CDI-1.0 as 1 per webapp we would not have any 'broader' scope in CDI and thus we dont need to deal! We could introduce all the necessary handling in CDI-1.1 together with the broader @EnterpriseApplicationScoped. Another point: who likes to go to all the other spec leads like JPA and most important JSF and confess that we messed up? Especially who gonna tell Ed that he cannot drop JSF ManageBeans because we have no replacement for his JSF @ApplicationScoped which exists since 10 years and he finally agreed to get rid of? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- Then it's the only correct interpretation. Read section 5.1. It specifies what I described above. At the same time it *does not* say anything about TCCL and classloaders in general which you are referring to. I don't think we can proceed further with this issue without clear understanding of how modularity is supposed to work in 1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- Btw, I do agree with you that we need to get a common understanding about how Modularity should work. The BDA approach was way too restrictive but a flat structure doesn't work neither. Also the CDI spec prominently uses the terminus tecnicus 'bean' for 5 different things: * Bean<T> * the class which gets scanned and might lead to 0..n Bean<T> * the Contextual Reference * the Contextual Instance * the Type on the Injection Point Even in the aforementioned paragraph 5.1 many those 5 meanings are perfectly mixed up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger edited comment on CDI-129 at 10/17/12 7:36 AM: --------------------------------------------------------------- What you quoted is completely unrelated to modularity in CDI 1.0 :-( was (Author: jharting): What you quoted is completely unrelated to the modularity in CDI 1.0 :-( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- In this comment I'll try to go through the points from Mark and Jozef, and add some more facts that I have. I'll then do a separate comment with my opinion :-) {quote} Too bad it's neither in the CDI nor the EE spec defined what they mean with application. Both sometimes refer to web-applications and sometimes to enterprise-applications. It's just not clear. {quote} I previously asked Bill Shannon and Linda DeMichiel for a clarification on this. Bill said: {quote} There may be places where we don't use the terminology as precisely as we should, but I think Chapter EE.8 of the platform spec makes it clear that an ear file is a single Java EE application. {quote} So, whilst it may not be clear, the official line is that an "application" is an ear, if ear is used. {quote} Afair it was 2 options: Option a.) just disallow @Specializes and @Alternatives for all beans defined in a shared jar. Regardless of it's scope. Option b.) inject only beans defined in the shared jar into another bean of a shared jar. E.g. MailService would always get an instance of A injected. Imo this is pretty crucial as @Inject X x; in a JSF backing bean would give you a different contextual instance (even of a totally different type) than the same code @Inject X x; in the MailService. {quote} We discussed this at the CDI EG meeting and the consensus was that option B is correct, as the injected instance depends on how the beans resolve, and thus getting a different contextual when a different bean resolves is expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- Pete, afair we just agreed that most containers implement it that way currently and that this is basically broken. Please think about the consequences! That would render CDI almost useless! Also please comment on my BeanManager clarification questions. What will a BeanManager#getBeans() return you? On that very meeting I told you that I will write up concrete examples and here we go. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Mark says: {quote} Due to the well defined TCCL behaviour in the EE umbrella spec it is perfectly viable that A might see B IF it is invoked in a request of the webapp containing A. So technically from the EE spec there is NO such restriction you mentioned. It's just easier for a container vendor to implement. {quote} I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow. {quote} Another point: who likes to go to all the other spec leads like JPA and most important JSF and confess that we messed up? Especially who gonna tell Ed that he cannot drop JSF ManageBeans because we have no replacement for his JSF @ApplicationScoped which exists since 10 years and he finally agreed to get rid of? {quote} I'm quite happy to take on any tasks that involve discussions with other spec leads. As JSF is prepared to deprecate scopes, and move people over to standard CDI scopes, there is a code change required anyway. Therefore, if we were to introduce a @ModuleScoped or similar, I think JSF apps could move from JSF application scope to this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- {quote} a.) I've now talked with lots of different folks, including JSR spec leads, and NO ONE did expect that behaviour. {quote} Mark, it would be very helpful if you could have these people engage in this discussion directly with the CDI EG, as I *do not* see a similar pattern. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Mark's "MailService" example is very helpful, but I'm struggling to fully comprehend it because of the formatting. I'm going to try to create a gist, which will give us compiling code. This should make it easier to understand I think! Mark, I'm going to need you to double check that I've accurately reproduced your example! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Here is the gisted version of Mark's example. The key point here is *what* get's injected into MailService, which is an EAR bean, is different depending on which WAR you are in, which is a little odd. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Proposed question for the poll is {quote} Should @ApplicationScoped bean instances be shared between all modules (web apps, ejb modules etc), or be per web application? {quote} Mark, wdyt? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- {quote} Should @ApplicationScoped bean instances be shared between all modules (web apps, ejb modules etc), or be per web application? {quote} again the term 'bean' which is so highly ambiguous I guess you fear that the public audience is not yet fully aware of 'Contextual Instance'? :) I'd rather try it a bit more sluggish: {quote}What would you expect to get from an @ApplicationScoped CDI bean in an EAR? 1 instance per each Web-Application or 1 instance for the full EAR?{quote} Regarding the Bill quote: I've now read through the EE6 spec and it appears to me that they mostly refer to EARs as "Java EE Application" (in older spec versions it was "J2EE Application"), see e.g. EE.2.11.3, EE.2.4, EE.2.12.2, EE.5.5.2 and 185 more references. There is other prominent mentioning of "JSF Application", "Web Application", even "Desktop Application" and "Java Application" amongst a dozen others. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger edited comment on CDI-129 at 10/18/12 2:46 AM: --------------------------------------------------------------- {quote} The key point here is what get's injected into MailService, which is an EAR bean, is different depending on which WAR you are in, which is a little odd. {quote} Unfortunatelly I cannot see the code anywhere so this might not be entirely accurate but I'd like to point out that this problem is orthogonal to scoping of the application scope. The same thing would happen for a @Dependent scoped bean or a @Request scoped bean. Although Mark thinks that restricting @ApplicationScoped per war fixes this it actually does not. {quote} Jozefs way is technically valid, but a no-go from a user perspective imo as it would lead to having different contextual instances for the same injection points across your application.{quote} I disagree. If you want to override a certain bean globally, put the alternative into a shared jar or into another jar that is visible to all the web applications. If you only want to change the behavior in one of the web applications, put the alternative bean into the web application. I find this way consistent (because it does not create exceptions to rules), straightforward and powerful (because you can choose out of multiple options without introducing new scopes). was (Author: jharting): Unfortunatelly I cannot see the code anywhere so this might not be accurate but I'd like to point out that this problem is orthogonal to scoping of the application scope. The same thing would happen for a @Dependent scoped bean or a @Request scoped bean. Although Mark thinks that restricting @ApplicationScoped per war fixes this it actually does not. I disagree. If you want to override a certain bean globally, put the alternative into a shared jar or into another jar that is visible to all the web applications. If you only want to change the behavior in one of the web applications, put the alternative bean into the web application. I find this way consistent (because it does not create exceptions to rules), straightforward and powerful (because you can choose out of multiple options without introducing new scopes). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-129 at 10/18/12 2:57 AM: ------------------------------------------------------------- Again Jozef, this is JUST NOT TRUE for CDI! The problem is not the scope of the bean which gets injected, but the scope of the bean you inject into. Are we d' accord on this part? It just doesn't friggin depend whether the injected bean is @Dependent, @SessionScoped or @DumbassScoped! By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI. We could go on and define the behaviour for scopes larger than 1 per WAR in CDI 1.1. The EJB EG would probably need to clarify the restrictions for injecting into shared stateful EJBs, but indeed that is not so much a problem of CDI. on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'? was (Author: struberg): Again Jozef, this is JUST NOT TRUE for CDI! The problem is not the scope of the bean which gets injected, but the scope of the bean you inject into. Are we d' accord on this part? It just doesn't friggin depend whether the injected bean is @Dependent, @SessionScoped or @DumbassScoped! By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI. We could go on and define the behaviour for scopes larger than 1 per WAR in CDI 1.1. We EJB EG would probably need to clarify the restrictions for injecting into shared stateful EJBs, but indeed that is not so much a problem of CDI. on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- {quote} By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI. {quote} OK, assume there is a shared @RequestScoped bean R in the shared library injected both into a Servlet in your web app and into the MailService. No alternatives nor specialization this time. What you say is that the Servlet would operate on a different instance of the same R bean than the MailService? In the same call stack during processing of the single same request? How is that consistent? Maybe we could do a poll if this is what people want ;-) {quote} on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'? {quote} I disagree that it is unusable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger edited comment on CDI-129 at 10/18/12 3:09 AM: --------------------------------------------------------------- {quote} By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI. {quote} OK, assume there is a shared @RequestScoped bean R in the shared library injected both into a Servlet in your web app and into the MailService in the shared lib. No alternatives nor specialization this time. What you say is that the Servlet would operate on a different instance of the same R bean than the MailService? In the same call stack during processing of the single same request? How is that consistent? Maybe we could do a poll if this is what people want ;-) This is not CDI. {quote} on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'? {quote} I disagree that it is unusable. was (Author: jharting): {quote} By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI. {quote} OK, assume there is a shared @RequestScoped bean R in the shared library injected both into a Servlet in your web app and into the MailService in the shared lib. No alternatives nor specialization this time. What you say is that the Servlet would operate on a different instance of the same R bean than the MailService? In the same call stack during processing of the single same request? How is that consistent? Maybe we could do a poll if this is what people want ;-) {quote} on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'? {quote} I disagree that it is unusable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger edited comment on CDI-129 at 10/18/12 3:14 AM: --------------------------------------------------------------- {quote} By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI. {quote} OK, assume there is a shared @RequestScoped bean R in the shared library injected both into a Servlet in your web app and into the MailService in the shared lib. No alternatives nor specialization this time. What you say is that assuming the Servlet invokes MailService, the Servlet would operate on a different instance of the same R bean than the MailService? In the same call stack during processing of the single same request? How is that consistent? Maybe we could do a poll if this is what people want ;-) This is not CDI. {quote} on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'? {quote} I disagree that it is unusable. was (Author: jharting): {quote} By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI. {quote} OK, assume there is a shared @RequestScoped bean R in the shared library injected both into a Servlet in your web app and into the MailService in the shared lib. No alternatives nor specialization this time. What you say is that the Servlet would operate on a different instance of the same R bean than the MailService? (assuming the Servlet invokes MailService) In the same call stack during processing of the single same request? How is that consistent? Maybe we could do a poll if this is what people want ;-) This is not CDI. {quote} on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'? {quote} I disagree that it is unusable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- {quote} No of course not! At least not in my model {quote} OK, let's assume then that we took the approach 3) you proposed above (@ApplicationScoped per war) which claims to fix the issue. If the web app in my example above introduces a class {code:JAVA} @RequestScoped @Specializes public class S extends R { } {code} The Servlet would arguably operate on an instance of S. Assuming the servlet invokes the shared mail service, instance of which class would MailService operate on? a) R, which means that the problem is not fixed and you are wrong (@ApplicationScoped per war does not change anything) b) S, however S is not accessible from the MailService so this is wrong -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-129 at 10/18/12 3:40 AM: ------------------------------------------------------------- what is 'shared mail service' ? If we assume {code} @ApplicationScoped public class MailService { @Inject R r; ... } {code} then each webapp would get it's own contextual instance. Thus the MailService instance of your very webapp inoking r.someMethod() would work on an instance of S. For another webapp you might end up with an instance of R if this webapp doesn't specialize and not provide an alternative for S. Dude, who is creating the instance of MailService? It is the BeanManager which uses the TCCL of your webapp. Also: this BeanManager of your webapp knows all enabled Bean<?> of your webapp, so it will perfectly be able to resolve Bean<S>. was (Author: struberg): what is 'shared mail service' ? If we assume {code} @ApplicationScoped public class MailService { @Inject R r; ... } {code} then each webapp would get it's own contextual instance. Thus the MailService instance of your very webapp inoking r.someMethod() would work on an instance of S. For another webapp you might end up with an instance of R because this webapp doesn't specialize S. Dude, who is creating the instance of MailService? It is the BeanManager which uses the TCCL of your webapp. Also: this BeanManager of your webapp knows all enabled Bean<?> of your webapp, so it will perfectly be able to resolve Bean<S>. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- {quote}Mark: Thus the MailService instance of your very webapp inoking r.someMethod() would work on an instance of S. {quote} If we combine your statement with a quote from Section 5.1 of the CDI 1.0 spec: {quote}A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture. {quote} We can clearly see that you are wrong. The web app is not required to be accessible from the shared library. Therefore, *S is not available for injection in the shared library and thus cannot be injected into MailService*. What you are talking about is not CDI. {quote}Mark: Dude, who is creating the instance of MailService? It is the BeanManager which uses the TCCL of your webapp{quote} As Pete already explained, your TCCL argument is irrelevant to modularity in CDI. {quote}Pete: I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.{quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-129 at 10/18/12 4:03 AM: ------------------------------------------------------------- here is the original quote from pete {quote}I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.{quote} That doesn't sound like 'it is definitely that way'. Indeed you almost NEVER do do 'new SomeClass()' in dependency injection frameworks at all! That's the whole idea of DI containers to always do this dynamically. Imagine we do all this by hand: step 1: create a MailService mailService = new MailService() step 2: create a S s = new S; // S extends R step 3: mailService.setR(s); What is the problem with that? I cannot see any classloading issue! Of course, the MailService cannot have a @Inject S s; but only a @Inject R r; But that doesn't restrict us to only inject instances of type R into it! was (Author: struberg): here is the original quote from pete {qoute}I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.{quote} That doesn't sound like 'it is definitely that way'. Indeed you almost NEVER do do 'new SomeClass()' in dependency injection frameworks at all! That's the whole idea of DI containers to always do this dynamically. Imagine we do all this by hand: step 1: create a MailService mailService = new MailService() step 2: create a S s = new S; // S extends R step 3: mailService.setR(s); What is the problem with that? I cannot see any classloading issue! Of course, the MailService cannot have a @Inject S s; but only a @Inject R r; But that doesn't restrict us to only inject instances of type R into it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-129 at 10/18/12 4:11 AM: ------------------------------------------------------------- here is the original quote from pete {quote}I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.{quote} That doesn't sound like 'it is definitely that way'. Indeed you almost NEVER do do 'new SomeClass()' in dependency injection frameworks at all! That's the whole idea of DI containers to always do this dynamically. Imagine we do all this by hand: step 1: create a MailService mailService = new MailService() step 2: create a S s = new S; // S extends R step 3: mailService.setR(s); What is the problem with that? I cannot see any classloading issue! Btw: Weld 1.x and 2.x implement it EXACTLY THAT WAY ALREADY! Of course, the MailService cannot have a @Inject S s; but only a @Inject R r; But that doesn't restrict us to only inject instances of type R into it if we ONLY go on using those beans in our very own webapp! was (Author: struberg): here is the original quote from pete {quote}I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.{quote} That doesn't sound like 'it is definitely that way'. Indeed you almost NEVER do do 'new SomeClass()' in dependency injection frameworks at all! That's the whole idea of DI containers to always do this dynamically. Imagine we do all this by hand: step 1: create a MailService mailService = new MailService() step 2: create a S s = new S; // S extends R step 3: mailService.setR(s); What is the problem with that? I cannot see any classloading issue! Btw: Weld 1.x and 2.x implement it EXACTLY THAT WAY ALREADY! Of course, the MailService cannot have a @Inject S s; but only a @Inject R r; But that doesn't restrict us to only inject instances of type R into it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- {quote}I cannot see any classloading issue!{quote} The fact that you could implement it does not mean that it is the right thing to do nor does it mean that it is the correct interpretation of the spec. {quote}Btw: Weld 1.x and 2.x implement it EXACTLY THAT WAY ALREADY!{quote} This is not true. Even if it was it would only mean that there are bugs in Weld. That happens. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- I already explained the argumentation chain which allows to interpret 5.1 to perfectly fit this picture in some posts above. BDA is btw is currently broken and the EG is working on a solution right now. See CDI-18. To interpret 5.1 in the way you propose would contradict the definitions of * BeanManager#getBeans(String) * BeanManager#getBeans(Class) * BeanManager#resolve() * BeanManager#getReference(Bean<?>, Type, CreationalContext<?>) In other words: that would be broken for EARs as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- {quote}I already explained the argumentation chain which allows to interpret 5.1 to perfectly fit this picture in some posts above.{quote} Yes. Afterwards, your TCCL interpretation of modularity was considered incorrect by Pete. {quote}To interpret 5.1 in the way you propose would contradict the definitions of ...{quote} Since you provided no evidence nor argumentation I assume your statement not to be true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-129: ------------------------------------ There is a lot of stuff here, but firstly: a) Bean is quite well defined in CDI. If it get's a ProcessBean event thrown then it is a bean. b) You are correct and TTCL is irrelevant here. Class loading is actually pretty irrelevant here, the EE platform spec defines class loading in terms of classes that must and must not be visible, and allows vendors to implement that with whatever class loading arrangement works So from what I see the problem is that there is a conflict in the spec to do with how injection point resolution works with scoping. 5.2.1 makes it pretty clean that every injection point must resolve to one and only 1 bean. In Mark's example, it actually resolves to different beans, due to scoping issues, and this is a problem that we need to sort out in the spec. Making ApplicationScoped be a per web application thing however is not a solution to this problem. This would mean that different beans resolve to the same injection point depending on the current context, which completely destroys static wiring, and we get back to a Seam 2 style resolution at injection time. It also makes the CDI deployment dependent on the current web app. What happens when there is no web app in an ear? What happens with a standalone jar? what happens with a SE app? Mark, from what I am reading it sounds like you are trying to bring back the worst of Seam 2 (I know you probably did not use Seam 2, but the approach was pretty much exactly what you are describing, and it had a lot of problems). IMHO we should just add @WebApplicationScoped and tighten up the spec to remove the scope problems, so if a bean ends up resolving injection points differently depending on the current archive it is a deployment error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Ok, the survey is created - http://www.surveymonkey.com/s/9VNXZDB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger edited comment on CDI-129 at 10/18/12 8:49 AM: --------------------------------------------------------------- {quote}Jozef, thanks for your input so far. There are some valid points in your argumentation and we need to clarify those. I guess we now have a pretty clear picture that EAR scenario is broken in CDI 1.0 if we use scopes broader than 1 contextual instance per war. We also outlined 3 different approaches to treat such scopes. We will schedule an EG meeting to discuss this in the EG.{quote} That is a pretty biased summary that ignores quite a few parts of the discussion above. I'll try to come up with a more objective one: After discussion with Mark and Stuart we all can see that there are two orthogonal issues involved: * wiring ** CDI is based on static wiring where the Bean for an injection point is resolved based on the module the class that declares the injection point is packaged in. (as explained in Section 5.1 of the CDI 1.0 spec) ** Mark thinks that a semi-static approach, where the Bean for an injection point is resolved based on the context of the thread in which the execution occurs is more appropriate. That means that if MailService is invoked from a web application that packages class B (which specializes A), MailService will also operate on the specialized version (B). * the actual span of the @ApplicationScoped (either per-war or per entire ear) was (Author: jharting): {quote}Jozef, thanks for your input so far. There are some valid points in your argumentation and we need to clarify those. I guess we now have a pretty clear picture that EAR scenario is broken in CDI 1.0 if we use scopes broader than 1 contextual instance per war. We also outlined 3 different approaches to treat such scopes. We will schedule an EG meeting to discuss this in the EG.{quote} That is a pretty biased conclusion that ignores quite a few parts of the discussion above. I'll try to come up with a more objective one: After discussion with Mark and Stuart we all can see that there are two orthogonal issues involved: * wiring ** CDI is based on static wiring where the Bean for an injection point is resolved based on the module the class that declares the injection point is packaged in. (as explained in Section 5.1 of the CDI 1.0 spec) ** Mark thinks that a semi-static approach, where the Bean for an injection point is resolved based on the context of the thread in which the execution occurs is more appropriate. That means that if MailService is invoked from a web application that packages class B (which specializes A), MailService will also operate on the specialized version (B). * the actual span of the @ApplicationScoped (either per-war or per entire ear) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-129: ------------------------------------ A few other lines from the spec that are relevant: 11.5 - "For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier @Default, sup- porting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces." If the application scope is scoped to the WAR then this means you need to create an instance of the PE per war. 3.2 - "A singleton bean must belong to either the @ApplicationScoped scope or to the @Dependent pseudo-scope" Singleton beans are definitely one per EAR, so if application scope is per war then they should not be allowed to be application scoped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-129: ---------------------------------------- Mark for EJB that's not so stupid because you get proxy not real instance so you really don't need to manage any scope for stateless or singelton (ejb one) BTW i saw some extensions managing classloaders but was not as easy as it should be IMO -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-129: ---------------------------------------- i udnerstood it (and in implementation that's consistent) as "let the ejb container manage it" and don't add a proxy in front on another proxy. The best choice in CDI 1.0 IMO -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-129: ------------------------------------ I was actually thinking about this same issue today. IMHO we need a special scope for Stateless and Singleton beans, as they are certainly not @Dependent scoped, and a lot of the rules and restrictions for @Dependent scoped beans simply don't make sense for them. I have created https://issues.jboss.org/browse/CDI-278 for this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Gerhard Petracek commented on CDI-129: -------------------------------------- @stuart: it would be a huge (!) issue for us, if we don't get one application scoped PE per web-app. that's currently our approach to collect artifacts which need to get processed later on. we can't store them per classloader, because e.g. servers like wls12c use a different classloader during the bootstrapping process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- This approach is btw also used in other CDI Extensions like Seam3. All of them would be broken. Fact is that we need to define exactly how the BeanManager scenario and thus also the Extension scenario looks like. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- For my side I have a pretty clear opinion: We have 3 options as listed above, and the one which makes users get different contextual instances depending on where the injection into gets made is an absolute no-go. So 2 Options remain (and I will not argue about which one is in the spec, because BOTH are covered + contradicted in CDI 1.0) either * restrict @Specializes and @Alternative to all non Object.class CDI-Bean Types to the outermost module * go with semi-static wiring IF needed. Again: this is NOT needed if we do not inject into a bean which is of a broader scope than 1 per webapp! By clarifying that @ApplicationScoped is 1 per WAR we could use fully static wiring for all CDI beans! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-129: ---------------------------------------- naturally (reading the spec the fisrt time) i thought about 2) but if Module == webapp for war (what about bda? if module is taken from JEE definition that sounds fine for me) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- {quote} naturally (reading the spec the fisrt time) i thought about 2) but if Module == webapp for war (what about bda? if module is taken from JEE definition that sounds fine for me) {quote} Right, somewhat confusingly (though understandable perhaps if you think of the age of the Java EE spec), Java EE names EJB JARs, WARS etc as "modules". Modules are *not* the same as a library (e.g. which goes in WEB-INF/lib or is installed in the app server). However I'm not sure about @ModuleScoped, for the obvious reason that the word module has a wider meaning, especially if modularity makes it into the JDK. I suspect we need another term :-( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-129 at 10/20/12 7:04 AM: ------------------------------------------------------------- Yesterday Gerhard, David and I had a really good late night discussion. I think I now understand a bit better where you guys are coming from conceptually. The isolation rules Jozef proposed are the ones from EJB. But CDI beans are not EJBs! CDI introduced the notion of Contexts and proxying. With EJBs you don't have cross-scope injection abilities, etc. A lot concepts are fundamentally more open and different in CDI. Thus I fear we also cannot apply EJB rules 1:1 to CDI beans. Now think about it again: you basically like to define @ApplicationScoped as alias for (EJB) @Singleton, right? That's what it boils down to if I read your proposal. Now the question is: why the hack do we need that? Just use an @Singleton EJB if you like to share state between different WAR files, MDB and stuff! So we do not even need to introduce any new scope because a thinkg like "@EnterpriseApplicationScoped" already exists: @Singleton. Maybe that was the reason why Gavin explicitly specified @ApplicationScoped web-app/servlet centric as 1-per-WAR by writing "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7, “Context management for built-in scopes” represent the standard scopes defined by the Java Servlets specification." The argument with the TCK is also not the strongest one. The JCP defines the following rule when resolving ambiguous definitions: 1.) JavaDoc 2.) Spec Wording 3.) TCK We (OWB) already reported 30++ bugs in the TCK and I guess others did the same. If you consider how many tests there are then this is only a small part, but still. Btw, it *really* rocks that the TCK is open sourced! This allows us to easily fix shortcomings, add more use cases and most importantly: talk about scenarios! With closed TCKs we would not even be allowed to talk about TCK use cases in a public bug tracker! @Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is *not* defined in a static way in CDI 1.0 but fully dynamic! was (Author: struberg): Yesterday Gerhard, David and I had a really good late night discussion. I think I now understand a bit better where you guys are coming from conceptually. The isolation rules Jozef proposed are the ones from EJB. But CDI beans are not EJBs! CDI introduced the notion of Contexts and proxying. With EJBs you don't have cross-scope injection abilities, etc. A lot concepts are fundamentally more open and different. Thus I fear we also cannot apply EJB rules 1:1 to CDI beans. Now think about it again: you basically like to define @ApplicationScoped as alias for (EJB) @Singleton, right? That's what it boils down to if I read your proposal. Now the question is: why the hack do we need that? Just use an @Singleton EJB if you like to share state between different WAR files, MDB and stuff! So we do not even need to introduce any new scope because a thinkg like "@EnterpriseApplicationScoped" already exists: @Singleton. Maybe that was the reason why Gavin specified @ApplicationScoped as 1-per-WAR by writing "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7, “Context man- agement for built-in scopes” represent the standard scopes defined by the Java Servlets specification." The argument with the TCK is also not the strongest one. The JCP defines the following rule when resolving ambiguous definitions: 1.) JavaDoc 2.) Spec Wording 3.) TCK We (OWB) already reported 30++ bugs in the TCK and I guess others did the same. If you consider how many tests there are then this is only a small part, but still. Btw, it *really* rocks that the TCK is open sourced! This allows us to easily fix shortcomings, add more use cases and most importantly: talk about scenarios! With closed TCKs we would not even be allowed to talk about TCK use cases in a public bug tracker! @Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is *not* defined in a static way in CDI 1.0 but fully dynamic! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- EAR is only defined in EE. I see no way to deploy an EAR to a non-EE server ;) All the other mentioned stuff like MDB, @Timeout, etc are ALL EJB parts as well. A legacy application could still use a simple static field if they like to share state. That was the way they did it with Spring and they will do it with CDI as well. Btw, actually most CDI users I know do NOT use an EE6 server but still EE5 + either Weld or OWB in their webapps. Amongst them are huge banks, 2 of the 10 biggest stock exchanges worldwide, the biggest international military pact and, some universities, etc. They all run those 'big irons' and replaced Spring with Weld or OpenWebBeans. I actually know _very_ few projects who already use a big EE6 server in production. To be honest: non of the big companies I know use it yet, they are still just testing. And now please answer me what all those companies do get if they drop Weld or OpenWebBeans into their webapps and add the ServletListener to boot the CDI container? Exactly, they get 1-per-WAR behaviour. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger edited comment on CDI-129 at 10/22/12 5:32 AM: --------------------------------------------------------------- {quote}@Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is not defined in a static way in CDI 1.0 but fully dynamic!{quote} No! The reason for that is because Beans are decoupled. Otherwise an extension would need to provide the entire Bean graph should it want to add a new Bean. What the spec says is that for a given InjectionPoint declared on a Class that is packaged in a given module, there is *always* a single Bean<?> that this InjectionPoint resolves to. Otherwise, it is a deployment error. This is what I refer to when as "static wiring" and this is what CDI specifies (sections 5.1 and 5.2). If the same InjectionPoint can resolve to different beans depending on the current thread state, this is what I refer to as "semi-static approach" (you came up with the term) was (Author: jharting): {quote}@Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is not defined in a static way in CDI 1.0 but fully dynamic!{quote} No! The reason for that is because Beans are decoupled. Otherwise an extension would need to provide the entire Bean graph should it want to add a new Bean. What the spec says is that for a given InjectionPoint declared on a Class that is package in a given module, there is *always* a single Bean<?> that this InjectionPoint resolves to. Otherwise, it is a deployment error. This is what I refer to when as "static wiring" and this is what CDI specifies (sections 5.1 and 5.2). If the same InjectionPoint can resolve to different beans depending on the current thread state, this is what I refer to as "semi-static approach" (you came up with the term) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- oki, for the 1000th time: a.) the term 'bean' in 5.1 might also be interpreted as 'Type at the injection point' b.) 5.1 is already obsolete. We already agreed in CDI-18 that all the modularity and BDA stuff must get reworked anyway as it is currently broken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Coming in on discussions from the weekend. 1) Initial intent. I'm 100% sure that Gavin intended @ApplicationScoped to be shared across the EAR originally, and that the comment about "standard scopes defined by Servlet spec" was the mistake. However, as I've been proved wrong here before, I've double checked it with him. Hopefully I can get an answer soon! 2) Whilst you may see most people using CDI standalone, what we are actually specifying here is how CDI works in Java EE 7 and above, and this what we must focus on. We must take account, of course, these other users, but they are lower than other considerations like how CDI works in Java EE 7 and above, backwards compatibility with Java EE 6 application servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Gavin has provided a very prompt response, and confirms that yes, the CDI 1.0 EG definitely intended @ApplicationScoped to be "per-EAR" and NOT "per-WAR", confirming my assumption that the note about "standard scopes defined by Servlet spec" was just an oversight. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-129: ----------------------------------- that is exactly the problem: BOTH ways are not fully covered in CDI1.0! See CDI-18 where the EG already agreed that BDA and 5.1 is moot and needs to get redefined. Also {quote} 2.4 Scopes: Java EE components such as servlets, EJBs and JavaBeans do not have a well-defined scope. ... singletons, such as EJB singleton beans, whose *state is shared between all clients*, ... Scoped objects, by contrast, exist in a well-defined lifecycle context: their state is automatically shared by clients that *execute in the same context*. {quote} Actually your interpretation of the spec would exactly fit the aforementioned EJB @Singleton. And in the same paragraph this is explicitly ruled out. Also please note that your interpretation would have the result that firing a CDI event from an @ApplicationScoped bean in a shared lib would NOT reach any bean defined in any WAR file! There is no way to do that with your interpretation. Again: all that ONLY happens if you need to deal with scopes > 1 per war. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- Mark, please don't rewrite history. The EG has NOT agreed that BDA and 5.1 are wrong. We simply discussed how to enable and disable alternatives, interceptors and decorators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-129: ------------------------------------ Note that this approach actually solves some other problems as well, such as what happens when an extension in a war modifies a shared bean? At the moment this change will be visible everywhere, which violates the 'wars are isolated' principle. If you set the war to be an isolated deployment then this will not longer be an issue, as the war will only modify its own copy of the bean. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- I would not say "vertical approach is implemented". It is probably a side effect of specialization never being properly implemented in Weld 1.x. This has other unexpected side effects. Can you try your test with alternatives? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-129: ------------------------------------- I am not aware of @Alternative being broken in Weld. If you think it is please file a Weld issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-129: ------------------------------- We discussed this, and we are strongly in favor of: * @ApplicationScoped being shared across the EAR * Visibility rules being applied as described in CDI 1.0 Other approaches are very interesting, and should be prototyped, but we don't believe that changing the way either of these concepts works from certain 1.0 CDI implementations is correct. Note that we don't believe the concerns raised about specialization and alternatives to truly be an issue, as beans which have been specialized, and beans for which there is a selected alternative are not enabled in the application in the 1.0 specification. Working on the assumption that the EG is not agreed on this position, I will start a vote on this topic next week. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira