Skip to main content

[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

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.

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 :)

- 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"
>http://blog.eisele.net/2010/12/seven-ways-to-get-things-started-java.html
>>
>> 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 
>>> here.
>>>
>>> WDYT?
>


[jsr342-experts] Application ready event

Pete Muir 11/28/2012

[jsr342-experts] Re: Application ready event

Markus Eisele 11/28/2012

[jsr342-experts] Re: Application ready event

Pete Muir 11/28/2012

[jsr342-experts] Re: Application ready event

Markus Eisele 11/29/2012

[jsr342-experts] Re: Application ready event

Pete Muir 11/29/2012

[jsr342-experts] Re: Application ready event

Werner Keil 11/29/2012

Message not available

[jsr342-experts] Re: Application ready event

Markus Eisele 11/30/2012

[jsr342-experts] Re: Application ready event

Werner Keil 11/30/2012

[jsr342-experts] Re: Application ready event

Pete Muir 11/30/2012

[jsr342-experts] Re: Application ready event

Werner Keil 11/30/2012
 
 
Close
loading
Please Confirm
Close