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

[arjan tijms]

Hi,

On Thu, Nov 20, 2014 at 2:47 PM, Mark Struberg <struberg at yahoo.de> wrote:
> I'm not quite sure that it's worth it. The @RequestScoped and @SessionScoped are already in the CDI spec package. And as you know we must not split packages between different specs.
>
> It would feel quite unnatural to have annotations in the CDI APIs but the description in the servlet spec.

I don't think it's about moving those scope annotations, but just
about the injection of HttpServletRequest, HttpSession and
ServletContext. There's no particular annotation used to inject these,
just @Inject.

If I'm not mistaken, nothing will change in the API, as the producers
for those types are implementation artifacts (build-in Bean
instances).


>Also note that some of those scopes (mostly @RequestScoped) also get used for non-servlet tasks. E.g. java-concurrency-utils threads, @Asynchronous EJBs, JMS invocations, @PostConstruct of @Stateless @Startup beans, etc.

Indeed, @RequestScoped has a very broad definition that covers much
more than just an HTTP request.

@SessionScoped however has a definition that currently IS strongly
tied to the Servlet spec:

"The session scope is active:

during the service() method of any servlet in the web application,
during the doFilter() method of any servlet filter and when the
container calls any HttpSessionListener, AsyncListener or
ServletRequestListener.

The session context is shared between all servlet requests that occur
in the same HTTP session. The session context is destroyed when the
HTTPSession times out, after all HttpSessionListeners have been
called, and at the very end of any request in whichinvalidate() was
called, after all filters and ServletRequestListeners have been
called."

See: https://docs.oracle.com/javaee/7/api/javax/enterprise/context/SessionScoped.html

In an ideal world this one would *maybe* have been provided by the
Servlet spec as well, but as you mention it's already in the CDI
package, so I don't think this one can be easily moved.

Kind regards,
Arjan



>
> What we probably could add (regardless whether on CDI or Servlet side) is kind of a @WebAppScoped. This is really missing atm. But again this must also be active in e.g. JMS invocations which form kind a 'logical app'.
>
>
> LieGrue,
> strub
>
>
>
>
>> On Wednesday, 19 November 2014, 19:40, Edward Burns <edward.burns at oracle.com> wrote:
>> > Hello Volunteers,
>>
>> The Servlet spec PDF currently only mentions CDI on two pages (and one
>> of them is a reference to the other).  It appears the normative
>> declaration of the requirements in Servlet regarding CDI is in our
>> section 15.5.15 "Contexts and Dependency Injection for Java EE
>> requirements".
>>
>> The CDI spec is trying to trim itself down and part of that effort
>> requires fobbing off some requirements previously declared in the CDI
>> spec itself to other related specs.  In this case, we have the
>> following:
>>
>> CDI Spec section 3.8 [1] places some requirements on CDI implementations
>> when running with Servlet. To better suit user desires for modularity
>> these requirements are better met by moving them to the Servlet
>> spec. Specifically,
>>
>> CDI3.8>    A servlet container must provide the following built-in
>> CDI3.8>    beans, all of which have qualifier @Default:
>>
>> CDI3.8>    a bean with bean type javax.servlet.http.HttpServletRequest,
>> CDI3.8>    allowing injection of a reference to the HttpServletRequest
>>
>> CDI3.8>    a bean with bean type javax.servlet.http.HttpSession,
>> CDI3.8>    allowing injection of a reference to the HttpSession,
>>
>> CDI3.8>    a bean with bean type javax.servlet.ServletContext, allowing
>> CDI3.8>    injection of a reference to the ServletContext,
>>
>> CDI3.8>    These beans are passivation capable dependencies, as defined
>> CDI3.8>    in Passivation capable dependencies.
>>
>> To put these items in the Servlet spec, we may have to couch them in
>> terms similar to, "when running in an environment that also supports
>> CDI...".
>>
>> PROPOSAL:
>>
>> Include language in our spec section 15.5.15 which allows the CDI spec
>> to remove their language while preserving desired existing user
>> functionality.
>>
>> What do you all think?  I know several of our constituents do not count
>> CDI support among their user requirements.  Is this going to be a
>> problem?
>>
>> Ed
>>
>> [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans
>>
>> --
>> | 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.