[cdi-dev] [JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs

Mark Struberg (JIRA) jira-events at lists.jboss.org
Thu Oct 18 04:06:01 EDT 2012


    [ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727550#comment-12727550 ] 

Mark Struberg edited comment on CDI-129 at 10/18/12 4:04 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!
                
      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!

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!
                  
> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
>                 Key: CDI-129
>                 URL: https://issues.jboss.org/browse/CDI-129
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.0
>            Reporter: Mark Struberg
>            Assignee: Pete Muir
>             Fix For: 1.1 (Proposed)
>
>
> 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. 

--
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


More information about the cdi-dev mailing list