11:06 a.m.
Le 17 nov. 2014 à 21:53, Antonio Goncalves
<antonio.goncalves(a)gmail.com> a écrit :
Would you like to see @Inject in JSR 250 ?
No, but in the end it’s a good thing that it is not in CDI (in a far lighter spec), so it
can be used by other DI solution for the sake of end users.
I don't think it's a good idea to put everything in Commons
Annotations. It makes sense to have @Startup, @Pooling, @Scedule, @Asynchronous where it
fits better.
Again, it’s a only Java EE pov, having such dependencies in Java SE can be a real
handicap. Take @Startup for instance. Its purpose is to make sure that a bean is
instantiated at startup. Why in the hell would I want to drag all the concurrency spec to
only have this annotation ?
I don’t say that it’s the case for all annotations, but we should really consider having
this multiple purpose annotation in light spec. For instance I’m not against having our
@Produces moved to AtInject (and perhaps renamed to @Provides to end the mix with JAX-RX
Produces) to share this concept with all other implementations.
Antonio
On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>> wrote:
Guys, don’t forget the commons annotation specification since we’re going to ask for a MR
for it. It could be a convenient solution to share annotation without having a huge
dependency to have it (think of SE).
Antoine
> Le 17 nov. 2014 à 16:53, Antonio Goncalves <antonio.goncalves(a)gmail.com
<mailto:antonio.goncalves@gmail.com>> a écrit :
>
> @Startup could also make sense in Concurrency in Java EE, like @Pooling (there's
thread pools behind). BTW I was talking to the Oracle guys and it looks like the
Concurrency spec will be updated in EE 8... I don't know how far the update will go.
>
> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB replacement
going to where it belongs : the JMS spec
>
> Antonio
>
> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms(a)gmail.com
<mailto:arjan.tijms@gmail.com>> wrote:
> Hi,
>
> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote:
> > Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0
(for the rest, what happens in Devoxx stays in Devoxx ;) )
> >
> > 1) Great expectations:
> > [...] (the question of total EJB replacement came more than once)
>
> I heard this a number of times as well, both before and during Devoxx.
>
> A great number of issues for decoupling EJB features (meaning,
> providing CDI based replacements) have already been created as spec
> issues:
>
> * Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1)
> * Decoupling the TimerService API from the EJB component model (EJB_SPEC-2)
> * Decoupling the @Asynchronous annotation from the EJB component model
> (EJB_SPEC-3)
> * Decoupling the @Lock/@AccessTimeout annotations from the EJB
> component model (EJB_SPEC-4)
> * Decoupling the @Startup/@DependsOn annotations from the EJB
> component model (EJB_SPEC-19)
> * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
> * Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154)
> * Allow Java EE components other than MDBs to consume messages
> asynchronously (JMS_SPEC-100)
> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
> * Support for "self" injection (CDI-414)
> * Allow access-control related JSR-250 security annotations on managed
> beans (JAVASERVERFACES_SPEC_PUBLIC-495)
> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
>
>
> There are some additional features that may not yet have been covered
> (but maybe I missed them), such as:
>
> * Control over passivation
> * Support for the extended persistence context
> * Destroying a bean whenever an exception occurs (I was just working
> on this the other week)
> * Logging the exception thrown by a bean (yes, trivial, but part of EJB)
> * The concept where every method call on a proxy is routed to another
> bean instance, which is then automatically unavailable for other calls
> as long as it doesn't return (related to the "Standardize Pooling"
> issue)
> * Binary remoting without all the explicit mapping that's needed for
> say JAX-RS (yes, thorny issue which we may not wish to support
> anymore?)
> * General support for @RolesAllowed/@RunAs etc (often mentioned, and
> two issues for JSF managed beans resp Servlets were created, but no
> general issue)
>
> The question is perhaps where all this functionality should live.
>
> TimerService and @Asynchronous in the concurrency spec?
> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
> @RolesAllowed etc in the security spec (if that spec will actually happen)
> @Startup in the CDI spec itself?
> Destroying bean on exception in CDI spec?
>
> But where should e.g. pooling belong?
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
<https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html
<http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas provided on
this list, the provider waives all patent and other intellectual property rights inherent
in such information.
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org/> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>