startup beans
by Dan Allen
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/cl...
--
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
13 years, 6 months
Persistence Module Overview
by Stuart Douglas
I just though I would send out a quick overview of exactly what is in
the persistence module at the moment:
Transactions:
It provides a SeamUserTransaction object that extends the JTA
UserTransaction (this means a dependency on the jta API).
Three default implementations will be provided
- The default EE version that either looks up UserTransaction in JNDI
or retrieves it from the EJBContext if a CMT is active
- An implementation that uses EntityTransaction, this is retrieved from the SMPC
- An implementation that uses hibernate's transaction API (to be done)
It does not use the CDI's ability to inject the UserTransaction for a
number of reason:
- It is not available in all environments
- It is not available in EJB's that use CMT
It provides a transaction interceptor, this allows you to use
@TransactionAttribute on managed beans the same way you would on
EJB's.
It provides @Transactional and @SeamApplicationException for
environments where these API's are not available.
Managed Persistence Contexts
- Defined as follows:
@SeamManaged
@Produces
@ConversationScoped
@PersistenceUnit("myPu")
EntityManagerFactory enf;
- This will work even in environments where @PersistenceUnit injection
is not directly supported, as seam-persistence will bootstrap it for
you.
- The SMPC provides the following:
- Automatic transaction enlistment
- Ability to use EL in queries
- Automatic hibernate search integration, if available
- Ability to set manual flush mode if required
- Event is fired when the SMPC is created, to allow for additional
configuration such as adding hibernate filters.
It also provides @TransactionScoped for transaction scoped beans
(forgot to put this in the reference guide, oops)
There are currently tests for jboss-as, jetty, and jetty+openjpa (with
no hibernate classes present on the classpath). I am planning on also
adding glassfish, glassfish+hibernate, and probably a few more as
well.
I have also added seam managed transactions to the faces module, this
is similar to seam 2, however it has two notable improvements:
- It can be controlled on per view basis (including using wildcards)
- it can be enabled only for the RENDER_RESPONSE, so you have manual
transaction control in your business logic, and then seam opens a
transaction for you when rendering to prevent LIE's (this also can be
configured on a per view basis).
I think that just about covers it. If anyone has any questions or
comments fire away.
Stuart
13 years, 6 months
Renaming Exception Handling
by Jason Porter
While trying to come up with a good name for the JIRA project I got a little hung up and asked for ideas on IRC. Dan had mentioned Seam Catch. It kinda stuck and seems like a good name. WDYT?
Sent from my iPhone
13 years, 6 months
IRC meeting tomorrow
by Pete Muir
Hi all
Topics for the agenda:
* Collect status on each module and also future plans (best is to get your module page updated on seamframework.org
* Discuss the timeline for Seam 3.0.0 beta and release candidates
* Run through current dependecy requirements for each module and align
It would be great if as many modules leads as possible could attend, this meeting will result in a plan for getting Seam 3 out.
Thanks!
13 years, 6 months
