Completely standard and portable ACC might be a difficult task. I know that
at least a standard way to bootstrap it would be an easy first step (e.g
every implementation has a acclient.sh / .bat shell with standard
parameters suc as --main <class name> if the jar is not bootable). But on
the other hand that sounds strange as we don't define how other containers
are bootstrap
Sent from my AndroPhone
Le 13 nov. 2012 21:29, "Bill Shannon" <bill.shannon_at_oracle.com> a écrit :
> 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.
>
>