users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: CDI in Application Client Container

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Tue, 13 Nov 2012 12:29:41 -0800

Antonio Goncalves wrote on 11/13/12 00:05:
> Well, it's not a first class citizen because 1) nobody uses it 2) even the TCK
> doesn't test it properly (in the EE spec CDI is mandatory in ACC).
I thought you were saying no one uses it because it's not a first class citizen.

Yes, there's an issues with CDI.

Why no one uses ACC is a different problem...

> It will become a first class citizen if we show it to the world (it's an
> hidden part of EE really) and enphasis its usage. We have a "Web Profile", why
> not having a "Client Profile". We might see other implementations coming (like
> what happened with the Web Profile). And we will be able to use the ACC in
> batches (there is a batch JSR that might be interested), CDI (CDI 1.1 will not
> define a bootstrap API, let's standardise it in the ACC then, and
> bootstrapping CDI in Java SE will come for free), JMS, JAX-WS.... anything
> that need a small set of services really (injection, life cycle management...).
>
> But Bill, why do you say "fighting a losing battle with ACC" ? Do you feel no
> much effort is put in the ACC ?
Despite our attempts to make it easy to use, and to explain when and why it
should be used, people still don't want to use it. All they want is a jar file
they can add to their classpath so they can invoke the "java" command directly.

Some people also want a completely standard and portable ACC that will work with
any vendor's server. That's a tremendous amount of work.

We can argue which is "cause" and which is "effect", but based on low usage of
ACC we have prioritized other work instead of ACC.