users@javaee-spec.java.net

[javaee-spec users] Re: [jsr366-experts] Re: Common services back to their specifications ?

From: Abhishek Gupta <abhirockzz_at_gmail.com>
Date: Sat, 17 Jan 2015 15:04:34 +0530

Hi,

I am far from being an expert but I have to say that just reading the
discussions on all the Java EE spec lists are an education in itself. Thank
you for triggering such insightful discussions!

I was thinking about things from a JAX-RS spec perspective.

We all know how JAX-RS leverages AsyncResponse interface to deal with async
client request on a RESTful end point by suspending the client thread. It
leaves it to the method developer to spin off the work in a separate thread
and use the resume method on the AsyncResponse interface to return the
response to the client (the actual return type of the method itself is
void).

*Arjan *- thanks for sharing your approach. After having read the details
in the CDI mailing list, I was wondering about the following

- how would a spec like JAX-RS make use of CDI enabled @Asynchronous ?
- the *AsynchronousInterceptor *would return a Future object. How would
JAX-RS deal with this ? Some kind of OOTB supplied entity provider ?

Sorry if the the question sounds silly. I am just trying to rewire my brain
to think from a Container perspective rather than just an API user point of
view. Feel free to correct me :-)

Thanks!
Abhishek.

On Fri, Jan 16, 2015 at 11:16 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:

> Hi,
>
> On Thu, Jan 15, 2015 at 1:55 AM, Bill Shannon <bill.shannon_at_oracle.com>
> wrote:
>
> > If we could build @Asynchronous support on interceptors, that would be
> > great.
>
> I gave it a quick shot (see
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/006065.html),
> but it doesn't seem to be entirely trivial.
>
> > If we need to enhance interceptors to make that possible, let's
> > consider that.
>
> I've asked this question on the CDI list as well. Maybe it's enough to
> just have the option on the InvocationContext to set it in async mode.
> E.g.
>
> @AroundInvoke
> public Object submitAsync(InvocationContext ctx) {
> ctx.startAsync();
> // schedule some work on pool with ctx as param
> }
>
> This wouldn't need to do much, e.g. just like in Servlet it would not
> need to create threads or submit work to pools. Instead, it would
> simply need to allow that InvocationContext instance to be used in
> other threads.
>
> With such support an other spec can probably do the actual
> implementation of @Asynchronous easily.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
> > 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>
> wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Dec 19, 2014 at 9:15 PM, Bill Shannon <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>
> >> > 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> 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
>