[jsr342-experts] Re: Application ready event
- From: Markus Eisele <myfear@...>
- To: jsr342-experts@...
- Subject: [jsr342-experts] Re: Application ready event
- Date: Thu, 29 Nov 2012 08:36:38 +0100
> Nice blog ;-)
> 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.
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.
> 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 :)
> 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 available.
>>> 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