[cdi-dev] Feedback from Devoxx

Mon Nov 17 16:15:29 EST 2014

That's something that has to be discussed in the EE expert group (@arjan
pointed at the JIRAs) because, let's face it, nobody really wants to open
up the EJB spec (let's leave it quiet, so let's not bring this to the
former EJB expert group... which I'm part of ;o)

Antonio

On Mon, Nov 17, 2014 at 10:10 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> Actually it makes sense, we already have @Transactional so only
> security part is really missing from EJB spec - sorry for the noise.
>
> Is there a place with all asked features (JavaSE, @Pooling, easier
> SPI, config, ...)? then people could maybe vote?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-11-17 22:04 GMT+01:00 Antonio Goncalves <antonio.goncalves at gmail.com
> >:
> > Like @dblevins once said "EJB was a super hype spec with all the cool
> > features... and became blotted throughout the years". If we are not
> careful,
> > CDI (the super hype spec at the moment) will become blotted too.
> >
> > Context and Dependency Injection should not deal with pooling,
> scheduling,
> > security.... but yes, allow the other specs to implement such concerns. I
> > can easily see most of these concerns implemented with interceptor
> bindings
> > or extensions.
> >
> > When we talked to Nigel (JMS spec lead) he was really enthousiast to
> learn
> > more about CDI and use it to help develop JMS internals. Manfred (JSF /
> MVC)
> > who has already implemented most of the JSF stuff with CDI (@ViewScoped
> and
> > so on) was really encouraging.
> >
> > I think that part of the job this CDI 2.0 expert group has is to
> evangelize
> > current specs leads to use CDI in their internals.
> >
> > Antonio
> >
> > On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau <
> rmannibucau at gmail.com>
> > wrote:
> >>
> >> 2014-11-17 21:53 GMT+01:00 Antonio Goncalves
> >> <antonio.goncalves at gmail.com>:
> >> > Would you like to see @Inject in JSR 250 ? 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.
> >> >
> >>
> >> Why not keeping in EJBs (even if it needs to be renamed for historical
> >> reasons)? ie a spec on top of CDI, not <= CDI.
> >>
> >> > Antonio
> >> >
> >> > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand
> >> > <antoine at 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 at 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 at gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
> >> >>> <antoine at 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 at lists.jboss.org
> >> >>> 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). 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Antonio Goncalves
> >> > Software architect, Java Champion and Pluralsight author
> >> >
> >> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> >> >
> >> > _______________________________________________
> >> > cdi-dev mailing list
> >> > cdi-dev at lists.jboss.org
> >> > 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). 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/1988e309/attachment-0001.html 