Hi Markus,
Nice blog ;-)
Going through what you describe there are three things my proposal offers (IMO!) that what we have today doesn't (and your blog neatly allows me to discuss this).
(a) nothing is requiring the startup order to be such that all other services that you depend on are started when this event occurs. For example, say you want to write to the database via JPA, and set up a timer, you also want to use CDI to wire the classes you are using to do this together. If it so happens it works this way, it's not because a spec says so, it's because a container does it that way
(b) there is no way to instruct the container to not start processing requests until this event is complete. Particularly relevant when you need to do some additional logic to set your app up.
So, onto the methods you describe:
1) @Singleton @Startup EJBs with @PostConstruct - suffers from (a), (b)
2) Startup servlet - suffers from (a)
3) Servlet listener - suffers from (a)
4) resource adaptor - suffers from (a), also not a Java EE component, so can't be injected, perhaps (b), IDK.
I'm not going to consider these, as they are vendor extensions
5) JMX/WLS
6) WLS ApplicationLifecycleListener
7) GlassFish LifecycleListener
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.
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.
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_at_bleepbleep.org.uk> 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?