[jsr342-experts] Re: Application ready event
- From: Pete Muir <pmuir@...>
- To: jsr342-experts@...
- Subject: [jsr342-experts] Re: Application ready event
- Date: Thu, 29 Nov 2012 14:05:46 +0000
On 29 Nov 2012, at 07:36, Markus Eisele wrote:
> Hi Pete,
>> Nice blog ;-)
> Thanks :)
>> If I'm wrong about any of these, I'd love you to tell me, as then I'll
>> push for this less, as we can always do it in an extension, but today I
>> believe there is actually no portable way to get such a notification.
> Your obviously correct with your analysis. Anyway, I'm wondering if
> this is something that really hurts anybody.I haven't seen any
> production environments that rely heavily on application configuration
> on start-up things. Especially not if this involves "data" (e.g.
> pre-populating anything to the database). What effectively would make
> sense is to run some kind of sanity checks (e.g. are all needed
> Resources in place < probably also a "cloud" EE8 topic.). But this
> would need a deeper container integration as I understand this.
Interesting, this was a much loved feature in Seam. Perhaps it's a feature
more aimed at development time, than production time?
> Further on I'm wondering if this isn't simply a more special
> "configuration" case for which we generally don't have a solution at
> all as of today.
I'm not sure how it relates to configuration?
>> As you can see, IMO each approach has flaws. Rather than try to convince
>> everyone to align how their server does these things, I think it's easier
>> to introduce a new approach. Further, as CDI is now being seen as the core
>> wiring model for Java EE, to me it makes sense to make something available
>> easily to an app wired using CDI.
> Bottom line: I'm not excited but also not against it. To me it would
> add another way of doing things at start-up. For sure it would be the
> recommended way to do if you have to rely on other services.
> If I would have time to spend I would think about a better application
> configuration approach in general. Given that, the CDI parts might be
> a foundation brick in our EE house :)
Work is being done on this in DeltaSpike project. If it proves popular and
successful, we will propose it for CDI.next.
> - M
>> On 28 Nov 2012, at 18:51, Markus Eisele wrote:
>>> Hi Pete,
>>> i'm undecided. We already have a couple (i beliebe it's probably more
>>> than 7) of ways to "get things started"
>>> What exactly should be the added value here?
>>> - M
>>> On 28 November 2012 19:39, Pete Muir <pmuir@...> wrote:
>>>> A long requested feature from the community has been for some sort of
>>>> "application ready" event, which is fired just before the application is
>>>> put into service, and starts handling external requests.
>>>> Some use cases:
>>>> * Loading/processing some data, for example data that's been collected
>>>> whilst the application was down
>>>> * Starting timers or async events
>>>> * Other application initialization tasks
>>>> This event should happen once all services (e.g. CDI, BV, JPA, EJB, JTA)
>>>> required by the application are ready.
>>>> There may be some optional services, e.g. those that are started on
>>>> demand, that are not required, and do not need to be ready for this
>>>> event to be sent. This event should happen before the application starts
>>>> handling external requests (e.g. web service requests, web requests, ejb
>>>> remote invocations). In general, it seems sane that an application
>>>> cannot handle requests successfully until all required services are
>>>> For the purposes of this proposal, we define external request as one
>>>> originating from outside the application deployment, and internal as one
>>>> originating from inside the application deployment.
>>>> In order to tackle this problem one step at a time, we propose we start
>>>> by just considering external requests as those coming in via the Servlet
>>>> container. This should make the problem more manageable!
>>>> Should the application wish to perform some sync task, and allow the
>>>> application to handle requests, whilst performing it, this also needs to
>>>> be possible.
>>>> Finally, the application needs to be able to say to the server that it
>>>> is ready to start servicing requests.
>>>> We would propose that we need to make these changes to the spec.
>>>> 1) We send a CDI event when the required services are ready
>>>> 2) By default this event *does not* block the server immediately moving
>>>> to servicing external requests
>>>> 3) The observer of this event is able to act as though it were executing
>>>> during application runtime, and can make any internal call. If it makes
>>>> an external call to itself, that call will not succeed
>>>> 4) We introduce the ability to suspend external requests, until the
>>>> event observers complete, or until the external requests are told to
>>>> proceed. We propose for now we focus on web requests and add a servlet
>>>> context parameter that enable the ability to suspend external requests,
>>>> and add a ServletContext.ready() method, that tells the request
>>>> completes. In future iterations we need to address other remote
>>>> protocols. The observers can make this call at any point, at which point
>>>> the app starts processing external requests, the observer may continue
>>>> to execute beyond here.