I just think this can't stay as it is at the moment. We are trying to
emphasis CDI in Java EE and it's not working in ACC. So, either we make CDI
work in ACC or we prune ACC. Either it works well, or we stop supporting it.
On Thu, Dec 13, 2012 at 2:46 PM, Markus Eisele <myfear_at_web.de> wrote:
> +1 for "CDI should work in ACC"
>
> - M
>
> On 7 December 2012 21:32, Antonio Goncalves <antonio.goncalves_at_gmail.com>
> wrote:
> > One thing is "is ACC used in the industry ?" and I think we all agree
> that
> > it's not. The other thing is "the spec says the CDI works in ACC". So
> either
> > the TCK makes sure it does (and everybody implements it), or we prune
> it, or
> > we say "CDI should work in ACC"
> >
> >
> > On Fri, Dec 7, 2012 at 8:31 PM, Jim Knutson <knutson_at_us.ibm.com> wrote:
> >>
> >> eisele.markus_at_gmail.com wrote on 11/20/2012 01:42:10 AM:
> >>
> >>
> >> > short feedback: I haven't seen much ACC out there until today.
> >> > Native clients are still somehow rare and most of the native java
> >> > clients rely on decoupled interfaces (WS/REST).
> >> > No need to put any efforts into the ACC if you ask me.
> >>
> >> +1
> >>
> >> I don't see enough industry usage to warrant a lot of effort here. If
> >> anything, we should be enabling "thin client" models that allows apps to
> >> embed EE container and service functionality as needed.
> >>
> >> Thanks,
> >> Jim Knutson
> >> WebSphere Java EE Architect
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org> |
Devoxx France <http://www.devoxx.fr>