From my experience, JPA mappings (defined in your persistence.xml file) will
not be processed by your designated JPA provider UNTIL it is called (ie via
dependency injection or otherwise). So...if you have a Singleton Session
Bean defined for Startup, and the startup order is before any other
Singleton, you will very likely be able to obtain the database resource via
without kicking off the JPA provider.
Again, this is from my experience on GF v 3.0.1....and I haven't seen
anything in the EJB specification (or otherwise) that states this is the way
it must be. So...it may not be vendor neutral or even work on later
versions of GF....so proceed with caution.
On another note, the ServletContextListener was a fine way to get things
done at application startup in Java EE 5 (and still with Java EE6), IMHO.
It was part of the blueprint patterns for J2EE and beyond =). Java EE6,
with Singleton EJBs and EJB-lite, makes it possible to do this in a much
cleaner way (again, IMO) and allows the EJB container to provide application
startup work without needing a war just to get this accomplished. I
wouldn't be so hard on the ServletContextListener approach =).
Regarding the failure/Exception that may occur during application startup
which causes the deployment to be aborted...I believe this is indicated in
the specification. All things done at application startup is synchronous
(blocking) and is uses to prepare/initialize the application for operations.
If there is a critical failure (a critical resource not available, for
example), I would expect startup of the application to not proceed. If an
exception/error occurred in the startup that is not critical and the
application can progress...it should be handled and allow the startup to
proceed. To me, it sounds more like an implementation issue than a problem
with GF/specification.
Regards,
Steve
On Fri, Feb 25, 2011 at 11:56 AM, Laird Nelson <ljnelson_at_gmail.com> wrote:
> I had a question regarding @Singleton EJBs annotated with @Startup,
> specifically as they relate to persistence units.
>
> Liquibase (http://liquibase.org) has a ServletContextListener facility
> that allows it to perform some sanity checks against the database on
> application startup. However, when a failure occurs here, deployment is
> aborted, and Glassfish is left in an inconsistent state and future
> deployments fail. Leaving aside the obvious heinous Glassfish bug here, I
> don't really want to use a ServletContextListener for startup operations,
> as that's really just a convenient side effect and smells like a hack.
>
> Enter EJB 3.1 and its @Startup beans, which are clearly designed to
> perform startup activities for a Java EE application.
>
> My question is: do these beans get processed before JPA gets involved? I
> would like to be able to perform database sanity checks before any JPA
> mappings are processed.
>
> The EJB 3.1 specification says only this:
>
> the container must initialize the Singleton bean instance during the
> application startup sequence. The container must initialize all such
> startup-time Singletons before any external client requests (that is, client
> requests originating outside of the application) are delivered to any
> enterprise bean components in the application.
>
> Thanks,
> Laird
>