If we move @Initialized to WeldX and add some qualifiers like @Application, someone can then do
@Observes @Application @Initialized Object o to be notified of app startup. On 20 Oct 2010, at 10:56, Nicklas Karlsson wrote: > The servlet event bridge has an @Initialized ServletContextEvent. > For JSF 2 there is also the possibility of the startup system event. > The ordering is currently hardcoded into weld-int by placing the WeldListener > before application servlet listeners. But I recall seeing a ContextNotActive > in a custom ServletListener so I'm not sure that is foolproof either, someone > with better as-weld integration knowledge should perhaps look it over. > > On Wed, Oct 20, 2010 at 12:49 PM, Pete Muir <[email protected]> wrote: > Doing it in the CDI container startup callbacks is not correct as the > container is not fully initialised. For Seam 3.0 you will need to use an EJB > 3.1 singleton (which provides an application startup callback), or listen to > servlet callbacks (we may need to fix the ordering of the Seam servlet > listeners outside of JBoss AS/GF). Doing this through events also addresses > your "transient startup scope" as you can simply declare your bean dependent, > meaning it will be destroyed after the observer invocation is complete. > > We should standardise the events sent so that they can be called outside of > Servlet too. What are they currently? > > On 20 Oct 2010, at 05:05, Dan Allen wrote: > > > One of the popular features in the Seam 2 "container" is startup components > > (which would be startup beans in CDI terminology). I'm trying to determine > > the best way to approach this feature and where it should live (i.e., Weld > > X and/or Seam 3, hence the x-post). > > > > While it's true that EJB 3.1 supports startup beans, it unnecessarily links > > them to: > > > > - enterprise beans (my, where have we heard this before? cough transactions > > cough) > > - singletons > > > > Seam 2 supports startup components that are instantiated (as in > > @PostConstruct gets invoked) when the scope to which the component is bound > > is activated. Supported scopes include application and session. I don't see > > any reason why we can't support all (or most) scopes in Weld X/Seam 3. > > > > At first glance, you might think about initializing @ApplicationScoped > > @Startup beans in an AfterDeploymentValidation observer (the > > application-scope is active at that point) [1] (also see note). That's > > certainly one way to go, though perhaps jumping the gun as some other > > extensions may still report a deployment error. It also doesn't address the > > remaining scopes. > > > > The better place to do eager initialization is perhaps the Seam 3 Servlet > > module. This module bridges the Servlet context events to the CDI event > > bus, providing the opportunity to initialize components bound to the > > relevant scopes. However, my concern is that if those events fire before > > the CDI implementation has started the scope, it's going to result in a > > ContextNotActiveException (Nik, would you be able to provide insight into > > whether this ordering issue has been address?). > > > > I'd also like to entertain the idea of having a transient startup scope > > (@ApplicationStartupScoped?). Most of the time developers employ a > > application-scoped startup bean, it's doing something like seeding a > > database, creating directories or some other routine that's a one time > > deal. It seems like a waste to have these beans hang around long after > > their job is done. In fact, I anticipate it becoming the most commonly-used > > scope for startup beans. > > > > After considering the options, it seems to me that long-term, this feature > > would be more robust if it were part of the CDI specification. (Even the > > JSF managed bean container supports eager bean initialization for > > application-scoped beans). Or perhaps I'm missing a very straightforward > > way to address it. > > > > I'm interested in hearing your suggestions. After I get feedback about > > which project/module should tackle this problem, I'll create a JIRA for it. > > > > -Dan > > > > [1] http://gist.github.com/635719 > > > > Note: There's another issue. BeanManager#getReference() may only return a > > proxy and not instantiate the bean, meaning @PostConstruct is not yet > > called. In the linked gist, I worked around this problem by invoking > > toString() on the reference. > > > > I'll mention that Resin has addressed @Startup support for managed beans: > > http://caucho.com/resin-4.0/examples/ioc-binding/viewfile?file=WEB-INF/classes/example/MyStartupBean.java > > > > -- > > Dan Allen > > Principal Software Engineer, Red Hat | Author of Seam in Action > > Registered Linux User #231597 > > > > http://mojavelinux.com > > http://mojavelinux.com/seaminaction > > http://www.google.com/profiles/dan.j.allen > > _______________________________________________ > > weld-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > _______________________________________________ > weld-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > -- > --- > Nik > _______________________________________________ > weld-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
