I agree with your concern, which is one of the reasons I like interceptors.
It's a fundamental capability on which we can build other interesting things,
and the users of those other interesting things don't even need to know that
those things were built on interceptors!
If we could build @Asynchronous support on interceptors, that would be great.
If we need to enhance interceptors to make that possible, let's consider that.
If we need to enhance CDI to allow @Asynchronous to be built outside of CDI,
that's another possibility.
Antonio Goncalves wrote on 12/20/14 13:14:
> Hi all,
>
> I'm changing the subject of the email so we exchange on the topic of "services
> that are common to several specs".
>
> /> Why wouldn't it be sufficient for CDI to define its own @Asynchronous
> annotation and have everything else that needed asynchronous method invocation
> depend on CDI?/
>
> What I am scared with this approach, is that we will end up with another EJB
> specification. EJB was a very innovative spec, aggregated all the "hype"
> technologies... but ended up being bloated. We can't do the same with CDI.
>
> So then, where do common concerns go ? Do we pack everything inside Commons
> Annotations (which will end up being bloated too) ? What I think is :
>
> * each service should go back to the spec where it belongs
> * each spec should be able to run in Java SE and Java EE
>
> With that in mind, here is an example of what could be done :
>
> * @Transactional : perfect success story, went back to JTA
> * @DeclareRoles, @RolesAllowed, @RunAs : go back to the new Security
> * @Asynchronous, @Startup, @Schedule, TimerService, @Lock, @AccessTimeout,
> @Pooled, @MaxConcurrency : back to Java EE Concurrency Utilities
> * @MessageDriven : back to JMS
> * @DataSourceDefinition : back to JTA
> * @Interceptor : in Interceptor spec (that's fine)
>
>
> With that in mind, all this would have to run in Java SE too. So, taking the
> example of the @Aynchronous annotation, a CDI bean would then depend on the
> Concurrency spec. This CDI bean will work in SE because Concurrency would also
> work on SE, and of course EE. An of course, the Servlet or JAX-RS spec could
> also use the EE side of Concurrenct for @Asynchronous invocations (here I'm
> just giving an example, could have been any other service such as @RolesAllowed).
>
> So, where should we put common concerns ? In CDI ? In JSR 250 ? Or in the spec
> where it makes more sense ?
>
> Antonio
>
>
> On Sat, Dec 20, 2014 at 1:03 AM, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> On Fri, Dec 19, 2014 at 9:15 PM, Bill Shannon <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>> wrote:
> > Why wouldn't it be sufficient for CDI to define its own @Asynchronous
> > annotation and have everything else that needed asynchronous method
> > invocation depend on CDI?
>
> That's certainly a valid question, but the answer I think depends on
> what we want CDI to be.
>
> Is CDI a base bean model with a small set of core supporting services
> for injection and lifecycle management, or should CDI increasingly
> adopt more enterprise features such as concurrency, security,
> transactions, (job) scheduling, etc?
>
> Should most other specs build on CDI, or should CDI build on most other specs?
>
> Currently both views seem to be in place. As Antonio mentioned, JTA
> choose to implement declarative transactions itself, but based on CDI.
> If I remember correctly it was a very explicit decision to not put
> this into CDI. JSF also very explicitly choose to implement its
> @ViewScoped and @FlowScoped itself but based on CDI, instead of asking
> CDI to implement something like that.
>
> But at the same time a couple of producers for artifacts originating
> from Servlet, JTA and the security system were put into CDI.
>
> If @Asynchronous is going to be defined by CDI, then I feel this is
> not just about that annotation and some supporting code being there or
> not, but also about supporting the idea that CDI should build on other
> specs. Is this indeed what we want?
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> >
> > Antonio Goncalves wrote on 12/19/14 01:51:
> >
> > Hi,
> >
> > So let me bring a related issue.
> >
> > The CDI 2.0 EG is considering adding assynchronous method invocation (using
> > a @Asynchronous annotation). CDI is also targetting Java SE integration
> > (like JPA and so on, by using a CDI container factory). This means that
> > @Asynchronous methods need to work in both Java SE and Java EE.
> >
> > Would is make sense to have @Asynchronous in JSR 250 and, this way, rely on
> > a Java SE implementation (in CDI 2.0) and a Java EE implementation (let's
> > say EE Concurreny) ?
> >
> > I suppose the underlying question is "Could we create standard annotations
> > that will have SE and EE behaviour in JSR 250" ? I'm thinking of
> > @RolesAllowed, for example, that could have a SE and EE implementation.
> >
> > Antonio
> >
> >
> > On Mon, Dec 15, 2014 at 11:47 PM, Bill Shannon <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>>
> > wrote:
> >>
> >> We agree on the long term vision. This is almost entirely a resource
> >> issue. In order to do this, we have to stop doing something else, or we
> >> have to delay the release. Based on the feedback we've gotten from the
> >> community, the things we've chosen to work on right now are the most
> >> important. We'd like to do what you suggest below as well, but it's most
> >> likely going to have to be done later.
> >>
> >> Note also that the Concurrency spec wasn't conceived as "anything related
> >> to any kind of concurrency in Java EE". Whether it should become that is a
> >> question we'll have to answer in the future when we deal with these issues.
> >>
> >> Antonio Goncalves wrote on 12/15/14 14:09:
> >>
> >> Hi all,
> >>
> >> Concurrency Utilities for Java EE (JSR 236) : It would be the perfect spec
> >> to have @Startup, @Schedule, @Asynchronous, @Pooled annotations. Any plans
> >> on that ?
> >> > We are still evaluating whether there will be a new JSR/MR.
> >>
> >> I think that is one of my biggest concern. I don't know what is the middle
> >> to long time "vision" of Java EE, but I think that what happened with
> >> @Transactional in JTA should be replicated : @TransactionalAttribute in EJB
> >> was fine, but it makes more sense to have this concern going back to JTA.
> >> @Asynchronous, @Startup, @Schedule should "leave" the EJB spec to go back
> >> where it belongs. @Pooled would also make sense. Plus, if we want to
> embrace
> >> Java SE 8, there are new asynchronous APIs that Java EE should
> leverage, and
> >> again, going to the Concurrency spec would make sense.
> >>
> >> What could we do to work on the process of evaluating if Concurrency
> >> should be updated or not ?
> >>
> >> Antonio
> >>
> >> On Thu, Dec 11, 2014 at 10:46 PM, Linda DeMichiel
> >> <linda.demichiel_at_oracle.com <mailto:linda.demichiel_at_oracle.com>> wrote:
> >>>
> >>> Hi Antonio, all,
> >>>
> >>> Please see inline below....
> >>>
> >>>
> >>> On 12/10/14 8:20 AM, Antonio Goncalves wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I was wondering if Java EE 8 was "spec completed" at the moment or if
> >>> there are other specs coming along. Correct me if I'm wrong, but so far we
> >>> have (I hope I'm not missing any) :
> >>>
> >>> New Specifications
> >>>
> >>> JCache (JSR 107)
> >>> JSON-B 1.0 (JSR 367)
> >>> MVC 1.0 (JSR 371)
> >>> Java EE Security 1.0 (JSR 375)
> >>>
> >>> These new specifications will of course need to be approved by the
> >>> Java EE 8 Expert Group in order to be included in the platform.
> >>>
> >>> Updated Specifications
> >>>
> >>> CDI 2.0 (JSR 365)
> >>> JMS 2.1 (JSR 368)
> >>> Servlet 4.0 (JSR 369)
> >>> JAX-RS 2.1 (JSR 370)
> >>> JSF 2.3 (JSR 372)
> >>> Java EE Management API 2.0 (JSR 373)
> >>> JSON-P 1.1 (JSR 374)
> >>>
> >>> Yes
> >>>
> >>> Any other coming along ?
> >>>
> >>> Our main focus will be on the JSRs listed above. Our JSRs/MRs
> >>> covered below will be done more opportunistically, based on
> >>> available resources.
> >>>
> >>> Bean Validation (JSR 349) : I know Emmanuel Bernard is planning of
> >>> updating it to have the Java SE 8 goodies
> >>> Common Annotations (JSR 250) : The CDI 2.0 EG is thinking of introducing
> >>> a broader usage of the @Priority annotation (not just for interceptor, but
> >>> other things). Is there any plan to update the JSR 250 ?
> >>>
> >>> We will do an MR for Common Annotations if needed for alignment with
> >>> other specifications.
> >>>
> >>> Concurrency Utilities for Java EE (JSR 236) : It would be the perfect
> >>> spec to have @Startup, @Schedule, @Asynchronous, @Pooled annotations. Any
> >>> plans on that ?
> >>>
> >>> We are still evaluating whether there will be a new JSR/MR.
> >>>
> >>> Enterprise JavaBeans (JSR 345) : The CDI 2.0 is thinking of introducing
> >>> the notion of self injection (e.g. @Self<MySelf> me) that would allow
> >>> interception within the same bean. Updating the Interceptor spec could be
> >>> interesting. Any plans ? If Interceptor is updated, would EJB be
> updated too
> >>> ?
> >>>
> >>> We expect that both EJB and Interceptors will need to undergo an MR
> >>> to align with work being done in related JSRs.
> >>>
> >>> Java Persistence 2.1 (JSR 338) : any plan to support Date and Time API
> >>> (JSR 310) mapping ? Is there a MR planned for JPA ?
> >>>
> >>> We expect JPA to undergo an MR. I don't know at this point whether
> >>> Date/Time will be addressed.
> >>>
> >>> Java API for WebSocket (JSR 356) : just wondering
> >>>
> >>> There will be a new JSR or MR for WebSocket. We are currently evaluating
> >>> which.
> >>>
> >>> Batch (JSR 352) : just wondering
> >>>
> >>> I'll let our IBM expert speak to this....
> >>>
> >>>
> >>> Data Grids (JSR 347) : just wondering
> >>>
> >>> I'll let our Red Hat expert speak to this....
> >>>
> >>>
> >>> Expression Language 3.0 (JSR 341) : just wondering
> >>>
> >>> MR
> >>>
> >>> JAX-WS 2.0 (JSR 224) : just wondering
> >>>
> >>> MR (likely only to support repeating annotations).
> >>>
> >>> In addition, we are planning to do MRs for JTA and JavaMail.
> >>>
> >>>
> >>> -Linda
> >>>
> >>>
> >>>
> >>> Thanks for any feedback
> >>>
> >>> --
> >>> 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
> >>
> >>
> >
> >
> > --
> > 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>