Hi,
On Sat, Nov 22, 2014 at 3:30 AM, Greg Wilkins <gregw_at_intalio.com> wrote:
> So if servlet containers provide a portable API for CDI customisation, and
> CDI provides a portable API for Servlet container customisation, then we
> have a coin toss as to who should take on the responsibility for specifying
> and implementing the CDI+Servlets behaviour.
Well, it's not really about providing portable APIs or customisation,
it's just about using an API.
You could see it a bit as a library using the "new" operator from the
Java language.
Say we have library A that needs to instantiate an object of class X.
Library A just uses the "new" operator from Java:
X x = new X();
Just by calling this operator, library A doesn't provide the portable
new operator nor customizes it, it just makes use of it.
In the proposal, a Servlet container isn't asked to contain much
beyond the following (simplified):
public class HttpServletRequestProducer implements Bean<HttpServletRequest> {
public HttpServletRequest create(CreationalContext<
HttpServletRequest > creationalContext) {
return getRequestFromSomeWhere();
}
}
It doesn't provide the Bean interface itself, it just uses it.
> I can see why both groups would rather the other take on that
> responsibility/burden.
It's actually about all groups in Java EE using CDI.
If all groups in Java EE would require CDI to contain producers for
their artifacts, then CDI would need to have knowledge of all those
types of all specs. E.g. CDI would need to contain producers for say:
FacesContext (JSF)
UIViewRoot (JSF)
ParameterNameProvider (BV)
SessionContext (EJB)
ContextResolver (JAX-RS)
WorkManager (JCA)
Destination (JMS)
ELContext (EL)
TransactionManager (JTA)
ServerAuthConfig (JASPIC)
ServerWebSocketContainer (WebSocket)
ManagedScheduledExecutorService (Concurrency)
JobContext(Batch)
And that's just a small list. Should CDI really need to have knowledge
of all those types and additionally need to know how to provide
instances of each of those types?
Or should every spec in Java EE just know about the Bean type from CDI?
The latter is already what specs wanting to take advantage of CDI are
now doing. JSF 2.3 and MVC 1.0 will provide producers (Beans) for
their types, and not ask CDI to include their producers. If I'm not
mistaken JAX-RS planned to do a similar thing. CDI containing those 3
producers for Servlet artifacts is then the odd one out.
> Note that there may even be scope for both approaches to be used. When
> deploying CDI as part of a webapplication, then it is version independent
> from the servlet container and any CDI classes known to the container should
> be hidden from the CDI within the web application.
Well, maybe there's some confusion here (my honest apologies if I
misinterpret the above), but it's not in the proposal that servlet
containers now mandatorily ship with CDI implementations. A Servlet
container only has to provide an implementation of the Bean interface,
not define the Bean interface or any other CDI classes itself.
> Of course we will then have the problem of webapps with their own CDI being
> deployed on containers that provide CDI - then boom! game over! It is
> almost as if we need a webapp to be able to declare what services it wants
> the container to provide
Well yes, that's absolutely a problem today, but IMHO largely
unrelated to the current proposal, since it just asks to use CDI and
not to provide CDI ;)
That said, the problem you describe is absolutely very real, but holds
for all "Tomcat/Jetty"-wars, e.g. wars containing implementations of
say JSF, JPA, BV and yes CDI. Those wars already don't run without
problems on full or web profile Java EE implementations like say JBoss
or GlassFish. It would be really interesting to have a separate
discussion about this since the ability for webapps to declare what
services they want and/or do not want from the container is a very
frequently occurring issue.
> ie every webapp can declare it's own profile....
> but are we then re-inventing OSGi?
Maybe the upcoming Java SE module system (jigsaw) can be of help here?
But that is still a long wait...
Kind regards,
Arjan
[NB. I blame xerces for this mess....
> it started the trend of webapps depending on implementations rather than
> APIs ]
>
> cheers
>
>
>
>
>
>
>
>
>
>
> On 22 November 2014 02:32, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>> Hi,
>>
>> On Fri, Nov 21, 2014 at 4:09 PM, Edward Burns <edward.burns_at_oracle.com>
>> wrote:
>> >>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas
>> >>>>>> <sdouglas_at_redhat.com> said:
>> > GW> Thus I think these things must
>> > GW> remain a CDI impl responsibility as they are able to write container
>> > GW> portable code that will handle these concerns. The inverse is not
>> > true if
>> > GW> we make them container concerns.
>> >
>> > Excellent points. I will use these to push back on
>> > CDI-492-FobStuffToServlet.
>>
>> IMHO, unless I'm missing something here, but the assertion made above
>> is not correct. It's not only CDI that can write container portable
>> code.
>>
>> As mentioned in the other reply, the extension and producer mechanisms
>> needed are portable, public and non CDI-implementation specific. Every
>> Servlet container can use these mechanisms to produce the required
>> artefacts, without needing any CDI implementation specific code.
>>
>> So pushing back on this on the basis of (or just including the fact
>> that) Servlet containers needing to resort to non-portable code, which
>> I think is Greg's main concern, would not be entirely valid.
>>
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>> I will provisionally close this issue for
>> > now at least.
>> >
>> > Ed
>> >
>> > --
>> > | edward.burns_at_oracle.com | office: +1 407 458 0017
>
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com> @ Webtide - an Intalio subsidiary
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
> http://www.webtide.com advice and support for jetty and cometd.