[cdi-dev] [JBoss JIRA] Issue Comment Edited: (CDI-129) introduce @EnterpriseScoped (or similar)

[ 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