2:38 a.m.
Hi,
I've come across a bit of a problem with the PFD2 from the SE module
perspective. There's no longer any suitable built-in event which can
be used to kick off the SE application, due to there not being any
lifecycle events which fire while the contexts are active. We used to
use @Observes @Deployed Manager, and by doing so the observer method
was executed inside a fully injected bean with all contexts available.
In PFD2 we have the AfterDeploymentValidation event, but it gets fired
'before creating contexts and processing requests'. Then the next
lifecycle event after that is BeforeShutdown.
The simplest alternative I can think of is a custom event introduced
for WebBeans SE specifically, thrown by the SE module itself, which
isn't ideal because we lose that portability.
Any thoughts or advice?
Related question: How is application code written for CDI supposed to
execute code on startup - does it have to register an Extension and
execute without any contexts/injection?
Cheers,
Pete.
2:53 a.m.
On Tue, Sep 22, 2009 at 8:38 PM, Peter Royle
<howardmoon(a)screamingcoder.com> wrote:
Related question: How is application code written for CDI supposed
to
execute code on startup - does it have to register an Extension and
execute without any contexts/injection?
Yes, the solution for startup-time instantiation of objects is to make
them Extensions.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
6:47 a.m.
Hi,
So does anyone think it might be generally useful to add a simple
lifecycle event which fires once the contexts are active and can be
observed by regular CDI beans? This would simplify the use case of
performing application-specific, non-cdi-extending startup events (ie:
_NOT_ things like registering new kinds of beans or injection points),
while allowing the observing method to take full advantage of all the
features of CDI.
Also, obviously, it would give the SE module its portable startup hook
back.
Or is there already a reason why this isn't such a good idea?
Cheers
Pete.
On Tue, 2009-09-22 at 20:53 -0400, Gavin King wrote:
On Tue, Sep 22, 2009 at 8:38 PM, Peter Royle
<howardmoon(a)screamingcoder.com> wrote:
> Related question: How is application code written for CDI supposed to
> execute code on startup - does it have to register an Extension and
> execute without any contexts/injection?
Yes, the solution for startup-time instantiation of objects is to make
them Extensions.
11:57 a.m.
I would do this inside the SE bootstrap code, as this is a requirement
that is only applicable to the SE case (other container provide a
mechanism for this such as the contextInitialized event in Servlet).
Are you concerned about portability between CDI implementations or
between types of app (SE -> Servlet -> EE)?
On 23 Sep 2009, at 05:47, Peter Royle wrote:
Hi,
So does anyone think it might be generally useful to add a simple
lifecycle event which fires once the contexts are active and can be
observed by regular CDI beans? This would simplify the use case of
performing application-specific, non-cdi-extending startup events (ie:
_NOT_ things like registering new kinds of beans or injection points),
while allowing the observing method to take full advantage of all the
features of CDI.
Also, obviously, it would give the SE module its portable startup hook
back.
Or is there already a reason why this isn't such a good idea?
Cheers
Pete.
On Tue, 2009-09-22 at 20:53 -0400, Gavin King wrote:
> On Tue, Sep 22, 2009 at 8:38 PM, Peter Royle
> <howardmoon(a)screamingcoder.com> wrote:
>
>> Related question: How is application code written for CDI supposed
>> to
>> execute code on startup - does it have to register an Extension and
>> execute without any contexts/injection?
>
> Yes, the solution for startup-time instantiation of objects is to
> make
> them Extensions.
>
>
>
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
5329
days inactive
5329
days old
3 comments
3 participants
participants (3)
-
Gavin King -
Pete Muir -
Peter Royle