Hi,
It is so refreshing to read what experts in the Java Technologies plan
especially for a junior level Java developer like me. Nevertheless, I have
a different view for bringing Servlet Types producers inside Servlet spec.
I think it would be more cleaner and modularized if we let CDIs produce
dependencies and inject into other beans of other technologies as and when
required; otherwise, we might have to bring in technology specific producer
types in their respective specs - in other words why treat Servlets
separately and specially.
I am apologize in advance if I wrote ignorantly.
-Nawazish
On Thu, Nov 6, 2014 at 7:30 AM, <users-request_at_servlet-spec.java.net> wrote:
> Table of contents:
>
> 1. [servlet-spec users] Shouldn't CDI's HttpServletRequest, HttpSesison,
> etc producers be in Servlet? - arjan tijms <arjan.tijms_at_gmail.com>
> 2. [servlet-spec users] Re: Shouldn't CDI's HttpServletRequest,
> HttpSesison, etc producers be in Servlet? - Edward Burns <
> edward.burns_at_oracle.com>
> 3. [servlet-spec users] Re: Re: Standardizing authentication modules in
> Servlet (via JASPIC)? - Mark Thomas <markt_at_apache.org>
>
>
>
> ---------- Forwarded message ----------
> From: arjan tijms <arjan.tijms_at_gmail.com>
> To: users <users_at_servlet-spec.java.net>
> Cc:
> Date: Wed, 5 Nov 2014 16:27:00 +0100
> Subject: [servlet-spec users] Shouldn't CDI's HttpServletRequest,
> HttpSesison, etc producers be in Servlet?
> Hi,
>
> The CDI 1.2 spec specifies producers for HttpServletRequest,
> HttpSesison, and the ServletContext.
>
> Considering all artefacts in Java EE that would make sense to be
> injected, it seems a bit arbitrary that CDI itself contains producers
> for these Servlet types.
>
> Wouldn't it be better (cleaner) to have those producers in the Servlet
> spec instead?
>
>
> Kind regards,
> Arjan Tijms
>
>
> ---------- Forwarded message ----------
> From: Edward Burns <edward.burns_at_oracle.com>
> To: users_at_servlet-spec.java.net
> Cc:
> Date: Wed, 5 Nov 2014 07:58:31 -0800
> Subject: [servlet-spec users] Re: Shouldn't CDI's HttpServletRequest,
> HttpSesison, etc producers be in Servlet?
> >>>>> On Wed, 5 Nov 2014 16:27:00 +0100, arjan tijms <
> arjan.tijms_at_gmail.com> said:
>
> AT> The CDI 1.2 spec specifies producers for HttpServletRequest,
> AT> HttpSesison, and the ServletContext.
>
> AT> Considering all artefacts in Java EE that would make sense to be
> AT> injected, it seems a bit arbitrary that CDI itself contains producers
> AT> for these Servlet types.
>
> AT> Wouldn't it be better (cleaner) to have those producers in the Servlet
> AT> spec instead?
>
> I admit we have work to do in ensuring consistency on matters of CDI
> producers and technologies that depend on those producers. This thread
> cites one such case, in the Servlet spec. I suspect there are others,
> such as in JSF.
>
> My general principle in these matters are to keep such things as close
> to the "using spec" as possible. These matters need to be evaluated on
> a case-by-case basis. Arjan, thanks for bringing this up. Can you
> please cite the specific text in the CDI 1.2 spec so we can discuss it?
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 2 work days til Devoxx 2014
>
>
> ---------- Forwarded message ----------
> From: Mark Thomas <markt_at_apache.org>
> To: users_at_servlet-spec.java.net
> Cc:
> Date: Wed, 05 Nov 2014 20:55:49 +0000
> Subject: [servlet-spec users] Re: Re: Standardizing authentication modules
> in Servlet (via JASPIC)?
> On 03/11/2014 19:44, Edward Burns wrote:
> >>>>>> On Sat, 01 Nov 2014 10:14:10 +0000, Mark Thomas <markt_at_apache.org>
> said:
> >
> > EB> Thanks for your definitive answer. Is there any circumstance where
> you
> > EB> can imagine supporting it?
> >
> > MT> Supporting it as in supporting the idea that it should be mandatory?
> No.
> >
> > MT> Supporting it as in Tomcat shipping with JASPIC support? Yes, with
> > MT> caveats. Those caveats are:
> >
> > MT> - There needs to be an implementation on the table. We don't have
> that
> > MT> yet.
> > MT> - The impact any such implementation has on Tomcat internals.
> > MT> - The size of the implementation. (The larger it is, the more likely
> it
> > MT> would ship as an optional extra.)
> > MT> - The demand for it.
> >
> > EB> It it a resource question?
> >
> > MT> Partly. It is on the TODO list but fairly near the bottom due to the
> > MT> lack of demand for it.
> >
> > EB> Is it an architecture question?
> >
> > MT> No. I haven't looked at the architecture.
> >
> > EB> Is it because you feel JASPIC needs some improvements first?
> >
> > MT> No. I haven't looked at JASPIC in any details at all.
> >
> > Ok, these are actionable responses. Arjan, can you please get back to
> > the list with a feel for if it's possible to do as you said with the
> > Geronimo JASPIC impl?
> >
> > MT> There is also the ongoing issue of the ASF having access to the
> JavaEE
> > MT> TCKs under terms that would enable us to continue release software
> > MT> tested with the TCKs under the ALv2. I'd like to be able to test any
> > MT> JASPIC implementation with the TCK before release and that doesn't
> look
> > MT> like it is going to be an option any time soon.
> >
> > I can't comment on this, but I can say please encourage Gier to respond
> > to Cameron's mail. If this has already happened, then my apologies.
>
> No need to apologise. Several folks responded to Cameron's mail back in
> August but he appears not to have seen those replies.
>
> Pretty much the same set of responses was sent to his mail of a few days
> ago. We are assuming he saw them since he is subscribed to the list but
> it might be worth you pinging him to make sure he did.
>
> Cheers,
>
> Mark
>
>
> End of digest for list users_at_servlet-spec.java.net - Thu, 06 Nov 2014
>
>