[cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL

Fri Nov 21 13:58:22 EST 2014

>"logical app" what's wrong with @ApplicationScoped especially for JMS?

We had this discussion quite some time ago. If you like to have fun then read up CDI-129 ;)
It basically boils down that the majority of CDI EG members wanted to behave @ApplicationScoped as "1 per EAR", so we miss the "1 per Module/WebApp".

But this is needed if you e.g. like to store something which is unique to the webapp. E.g a cache in a JSF app. Would be pretty nasty to share e.g. caches over different WARs...

LieGrue,
strub

On Friday, 21 November 2014, 17:45, Werner Keil <werner.keil at gmail.com> wrote:
>>MS> side) is kind of a @WebAppScoped. This is really missing atm. But
>>MS> again this must also be active in e.g. JMS invocations which form
>>MS> kind a 'logical app'.
>
>
>"logical app" what's wrong with @ApplicationScoped especially for JMS?
>We got e.g. a very distributed Java EE app here at the current client where JMS is a vital part, but it's not just used in the Web tier. 
>
>
>Werner 
>
>
>
>
>
>On Fri, Nov 21, 2014 at 3:14 PM, <cdi-dev-request at lists.jboss.org> wrote:
>
>Send cdi-dev mailing list submissions to
>>        cdi-dev at lists.jboss.org
>>
>>To subscribe or unsubscribe via the World Wide Web, visit
>>        https://lists.jboss.org/mailman/listinfo/cdi-dev
>>or, via email, send a message with subject or body 'help' to
>>        cdi-dev-request at lists.jboss.org
>>
>>You can reach the person managing the list at
>>        cdi-dev-owner at lists.jboss.org
>>
>>When replying, please edit your Subject line so it is more specific
>>than "Re: Contents of cdi-dev digest..."
>>
>>
>>Today's Topics:
>>
>>   1. Re: Getting injection point from Bean#create (Romain Manni-Bucau)
>>   2. Re: Getting injection point from Bean#create (Romain Manni-Bucau)
>>   3. Re: Getting injection point from Bean#create (arjan tijms)
>>   4. Re: Getting injection point from Bean#create (Jozef Hartinger)
>>   5. Re: [servlet-spec users] [jsr369-experts]
>>      [116-CDIRelatedBeansInServletSpec] PROPOSAL (Edward Burns)
>>
>>
>>----------------------------------------------------------------------
>>
>>
>>Message: 5
>>Date: Fri, 21 Nov 2014 06:14:25 -0800
>>From: Edward Burns <edward.burns at oracle.com>
>>Subject: Re: [cdi-dev] [servlet-spec users] [jsr369-experts]
>>        [116-CDIRelatedBeansInServletSpec] PROPOSAL
>>To: Mark Struberg <struberg at yahoo.de>, users at servlet-spec.java.net,
>>        Cdi-dev <cdi-dev at lists.jboss.org>
>>Message-ID: <21615.18625.427842.794819 at gargle.gargle.HOWL>
>>Content-Type: text/plain; charset=us-ascii
>>
>>Mark added cdi-dev to the recipients list, but I am not subscribed to
>>that (please don't add me, I rely on JJ to keep me up to date!), so this
>>may bounce there.
>>
>>Also, Mark, there is no <jsr369-users at servlet-spec.java.net>.  The users
>>lists are re-used from JSR to JSR for each technology.  Thus, I have put
>>users at servlet-spec.java.net in place of the non-existent list.
>>
>>On Wednesday, 19 November 2014, 19:40, Edward Burns <edward.burns at oracle.com> wrote:
>>
>>[...]
>>
>>EB> section 15.5.15 "Contexts and Dependency Injection for Java EE
>>EB> requirements".
>>
>>EB> The CDI spec is trying to trim itself down [...]
>>
>>EB> CDI Spec section 3.8 [1] places some requirements on CDI implementations
>>EB> when running with Servlet. To better suit user desires for modularity
>>EB> these requirements are better met by moving them to the Servlet
>>EB> spec.
>>
>>[...]
>>
>>EB> To put these items in the Servlet spec, we may have to couch them in
>>EB> terms similar to, "when running in an environment that also supports
>>EB> CDI...".
>>
>>EB> PROPOSAL:
>>
>>EB> Include language in our spec section 15.5.15 which allows the CDI spec
>>EB> to remove their language while preserving desired existing user
>>EB> functionality.
>>
>>[...]
>>
>>>>>>> On Thu, 20 Nov 2014 13:47:19 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:
>>
>>MS> I'm not quite sure that it's worth it. The @RequestScoped and
>>MS> @SessionScoped are already in the CDI spec package. And as you know
>>MS> we must not split packages between different specs.
>>
>>>>>>> On Thu, 20 Nov 2014 22:32:39 +0100, arjan tijms <arjan.tijms at gmail.com> said:
>>
>>AT> I don't think it's about moving those scope annotations, but just
>>AT> about the injection of HttpServletRequest, HttpSession and
>>AT> ServletContext.
>>
>>Granted.  The proposal does not touch those.  Mark was just questioning
>>if it was worth it.  I am skeptical myself, but am responsive to
>>community input.
>>
>>MS> It would feel quite unnatural to have annotations in the CDI APIs
>>MS> but the description in the servlet spec. [...]
>>
>>I'll trust that Antoine Sabot-Durand (ASD) will take your reservations
>>into account when deciding to press on with CDI-492-FobStuffToServlet or
>>not.
>>
>>MS> What we probably could add (regardless whether on CDI or Servlet
>>MS> side) is kind of a @WebAppScoped. This is really missing atm. But
>>MS> again this must also be active in e.g. JMS invocations which form
>>MS> kind a 'logical app'.
>>
>>That's a whole new thing, again for ASD to consider.  As you observe, it
>>doesn't belong in Servlet because JMS can also use it.
>>
>>Ed
>>
>>--
>>| edward.burns at oracle.com | office: +1 407 458 0017
>>
>>
>>------------------------------
>>
>>_______________________________________________
>>cdi-dev mailing list
>>cdi-dev at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>End of cdi-dev Digest, Vol 48, Issue 16
>>***************************************
>>
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>