startup beans

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

startup beans

mojavelinux
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


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: startup beans

Pete Muir-2
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/weld-dev


_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/weld-dev


_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev



--
---
Nik

_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: startup beans

Pete Muir-2
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 <[hidden email]> 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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
> _______________________________________________
> weld-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
> --
> ---
> Nik
> _______________________________________________
> weld-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/weld-dev


_______________________________________________
weld-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: startup beans

mojavelinux
In reply to this post by Pete Muir-2
On Wed, Oct 20, 2010 at 5:49 AM, Pete Muir <[hidden email]> 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.

Duh Dan ;) I realized after thinking about this a bit more that that's exactly the purpose of a dependent-scoped observer :) My mind wasn't all there on that one.
 
-Dan

--
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] startup beans

mojavelinux
In reply to this post by Pete Muir-2
On Wed, Oct 20, 2010 at 6:03 AM, Pete Muir <[hidden email]> wrote:
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.

Exactly. I was thinking one of the main events that would be nice to have irregardless of being in or outside of a Servlet environment is the definitive application start event.

-Dan

--
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] startup beans

Pete Muir-2
Ondrej raised the question of whether this is a per node event (it is). If we want per cluster, we have to talk to Paul F. Which were you after?

On 20 Oct 2010, at 16:06, Dan Allen wrote:

> On Wed, Oct 20, 2010 at 6:03 AM, Pete Muir <[hidden email]> wrote:
> 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.
>
> Exactly. I was thinking one of the main events that would be nice to have irregardless of being in or outside of a Servlet environment is the definitive application start event.
>
> -Dan
>
> --
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] startup beans

mojavelinux
On Wed, Oct 20, 2010 at 11:07 AM, Pete Muir <[hidden email]> wrote:
Ondrej raised the question of whether this is a per node event (it is). If we want per cluster, we have to talk to Paul F. Which were you after?

I guess it really depends on the function of the startup routine. I would say that both are needed, but it's hard to anticipate. A startup event per node might be doing something like flushing out a temp directory, seeding a in-memory database or starting other services. A cluster-wide startup event might be populating or sorting out records in a shared database or starting up shared services. Obviously the second case you only want performed by one of the nodes (or else they are stepping on each other's toes).

-Dan

--
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/weld-dev