Skip to main content

[javaee-spec users] [jsr342-experts] Re: Application ready event

  • From: Markus Eisele <myfear@...>
  • To: Java EE Expert-Group <jsr342-experts@...>
  • Subject: [javaee-spec users] [jsr342-experts] Re: Application ready event
  • Date: Fri, 30 Nov 2012 08:24:48 +0100
  • List-id: <jsr342-experts.javaee-spec.java.net>

Hi,

> Interesting, this was a much loved feature in Seam. Perhaps it's a feature 
> more aimed at development time, than production time?

Indeed, it does make sense for development. but anyway, if you have
the requirement to setup stuff "the hard way" in production most of
the projects I have seen tend to introduce that kind of stuff from the
beginning on and don't rely on the development time improvements.
Might be an issue related to the project environment.

> I'm not sure how it relates to configuration?

Most of the things that need to be done on "application ready" have
some kind of configuration aspects. And Werner was also right, that it
might also be part of "Statemanagement" (whatever that truly will be
about in EE8) ...
I'm simply unsure if this kind of "lifecycle events" would better fit
into a configuration or even a statemanagement JSR ... somebody from
Orcl cloud comment on that probably?

> Work is being done on this in DeltaSpike project. If it proves popular and 
> successful, we will propose it for CDI.next.

Pragmatic solution! Thanks!

- M


>>
>> - 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?
>>>
>


[javaee-spec users] [jsr342-experts] Application ready event

Pete Muir 11/28/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

Markus Eisele 11/28/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

Pete Muir 11/28/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

Markus Eisele 11/29/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

Pete Muir 11/29/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

Werner Keil 11/29/2012

Message not available

[javaee-spec users] [jsr342-experts] Re: Application ready event

Markus Eisele 11/30/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

Werner Keil 11/30/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

Pete Muir 11/30/2012

[javaee-spec users] [jsr342-experts] Re: Application ready event

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