> 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).
OK fair dos.
> Are you concerned about portability between CDI implementations or
> between types of app (SE -> Servlet -> EE)?
I was thinking not so much of portability of code between the types
of app, more just a single way to do it for all of the types. But I
can also see how the presence of an alternative to those standard
ways of doing things could be considered a bad thing.
Portability between implementations would be ideal, but I'm not too
bothered about it if you guys aren't. Also I think the aim is still
that Web Beans SE itself will be portable in this sense anyway.
> On 23 Sep 2009, at 05:47, Peter Royle wrote:
>> 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
>> _NOT_ things like registering new kinds of beans or injection
>> while allowing the observing method to take full advantage of all
>> features of CDI.
>> Also, obviously, it would give the SE module its portable startup
>> Or is there already a reason why this isn't such a good idea?
>> 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
>>>> execute without any contexts/injection?
>>> Yes, the solution for startup-time instantiation of objects is to
>>> them Extensions.
>> webbeans-dev mailing list