[seam-dev] [weld-dev] startup beans

[Nicklas Karlsson]

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 <pmuir at redhat.com> 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
> > weld-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>



-- 
---
Nik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20101020/930fb049/attachment-0001.html