On Fri, Nov 30, 2012 at 2:25 PM, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
>
> On 30 Nov 2012, at 07:24, Markus Eisele wrote:
>
> > 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.
>
> Hmm, opposite of what I've seen, but I see what you are saying for sure.
>
> >
> >> 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) ...
>
> Well, some things, sure. However some things (like execute some SQL) - not
> sure how you do that from configuration?
>
>
We do that on a very regular basis from our configuration. Mostly using
Chef-like tools written in Python.
If configuration was to go as far as "execute these SQL statements before
deployment" it could standardize some of the "Cloud" related part, but I
don't know, if a configuration JSR wanted to go as far as that.
JPA partly does, so if there was a use case, we should probably look at its
definitions that exist so far.
They assume, a certain schema already exists. For configuration towards the
cloud, we could talk more about "create user $TENANT_ID" type of statements.
Werner
> > 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_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?
> >>>>
> >>
>
>