Argh.... it's not planned for 1.1 ? Damned, so boostraping CDI in Java SE
will not be ready for EE 7 ? That changes a lot of things :o(
On Tue, Nov 6, 2012 at 6:18 PM, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
> Hi Antonio
>
> Actually, Java SE support is planned for CDI 2.0. I'll be writing the full
> proposal for this up this month, and will be sure to send a copy to you for
> review!
>
> Pete
>
> On 6 Nov 2012, at 09:53, Antonio Goncalves wrote:
>
> > Hi all,
> >
> > I am the opposite of Markus on this one. I don't what to ask myself too
> many questions : need to inject a persistence context ? @Inject
> PersistenceContext. Need to inject an EJB ? @Inject MyEJB... and so on. I'm
> already disappointed to see @Context in JAX-RS. The programming model
> should be as easy as possible.
> >
> > Then comes the "I don't want to depend on CDI". This to me sounds a bit
> strange. CDI 1.1 is standardizing bootstrapping in Java SE, so what's the
> issue ? If the Batch JSR needs CDI outside EE it just bootstraps CDI in
> Java SE. Then, depending on CDI only really means depending on another
> external jar (piece of cake for Maven)
> >
> > I would like to see less custom technical annotations (let's use @Inject
> when we can) and in favour of more business annotation that developers can
> create (thanks to Stereotypes and Qualifiers)
> >
> > Antonio
> >
> >
> > On Tue, Nov 6, 2012 at 6:48 AM, Markus Eisele <myfear_at_web.de> wrote:
> > Hi Bill/All,
> >
> > Still very much split myself. I'm in favor of CDI. I simply don't like
> to see @Inject all over the place.
> > We already have a ton of custom annotations (e.g. @EJB) and if we treat
> them as a legacy artifact only we will probably end up with a programming
> model that needs good naming conventions (again) to be helpful.
> >
> > @Inject
> > private MyBoundary boundaryEJB;
> >
> > @Inject
> > private JobContext batchContext;
> >
> > This moves the problem to the user but should be solved in the platform.
> Having custom injection annotations makes this more readable and easier to
> follow in the code (at least for me).
> >
> > I would like to see the expansion of use of CDI stereotypes (aka
> meta-annotations / stacked stereotypes) and require every EE spec to
> provide a CDI based injection annotation.
> > They should be free to provide additional ways for supporting standalone
> environments (e.g. via additional @Qualifiers).
> >
> > - M
> >
> >
> > On 6 November 2012 01:10, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> > I'd like to follow up on an issue we raised at the Java EE 7 BOF
> > about the use of custom injection annotations.
> >
> > For example, should the Batch spec define
> >
> > @BatchContext
> > private JobContext ctx;
> >
> > or should it use
> >
> > @Inject
> > private JobContext ctx;
> >
> > The former is effectively a custom injection annotation unrelated to CDI.
> >
> > The latter introduces a dependency on CDI.
> >
> >
> > In your opinion, which is preferred? It seemed that the EE 7 BOF
> audience was
> > pretty evenly split on this one, and I can see arguments for either
> position.
> >
> > If @Inject is preferred, should we allow custom annotations at the
> discretion
> > of the spec author, or should we disallow custom annotations entirely?
> >
> > If custom injection annotations are allowed, should CDI make it easy to
> > define them, e.g., using something like:
> >
> > @Stereotype
> > @Inject
> > public @interface BatchContext { }
> >
> > If CDI supported this easily, applications could even define their own
> > injection annotations.
> >
> > Should custom injection annotations be a legacy artifact that we need
> > to continue to support, or should we recognize it as a part of the
> > Java EE programming model and use it widely?
> >
> >
> >
> >
> > --
> > 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>