Application Initialisation for a (non web) J2EE application

[Martijn Verburg]

Hi all,

We've got an interesting scenario at my current client where we're deciding on how to run 'stuff' at deploy time (or application container start time) when we deploy an EAR file. OK more detail:

We basically want to load a Spring Application Context when we deploy an EAR file (which contains a JAR with some code and some Spring configuration). This is so several resources are ready to be used when various Message Driven POJOs and Quartz Schedulers start.

* We don't utilise an ejb container (e.g. We don't use EJBs, just Spring/POJO)
* We'd like to avoid using a SAR (Jboss specific)
* We'd like to avoid using a servlet init in a WAR (We have no other web components to this application)
* We'd like to avoid 'manual' intervention (e.g. We don't want to execute a JMX call via a console)

Are we missing something obvious here?

[Jaikiran Pai]

Looks like you want to do something at the startup of the EAR deployment. But EAR deployments do not have a lifecycles. JBoss (as you already noted) does provide some ways to have a startup service - but that's a JBoss specific thing. Other servers too might provide server specific ways to handle this, but i don't see a common portable way of doing this.

[Jaikiran Pai]

Martijn Verburg wrote:
Message Driven POJOs and Quartz Schedulers start.

I haven't used Spring so not sure if this is possible - Could these (Spring) Message Driven POJOs be declared to have dependency on the Spring Application Context? This way, the Message Driven POJOs are not started until the Spring Application Context is available/deployed. Not sure if it's possible.

[Martijn Verburg]

Jaikiran Pai wrote:
I haven't used Spring so not sure if this is possible - Could these (Spring) Message Driven POJOs be declared to have dependency on the Spring Application Context? This way, the Message Driven POJOs are not started until the Spring Application Context is available/deployed. Not sure if it's possible.

That's effectively how it's set up yes, so it's the Application Context that we need to 'start' in what we're hoping is a standard J2EE manner (since we are deploying as an EAR). I think you might be right from what you've posted above, there are application server specific solutions but perhaps not a standard J2EE solution for this.

[Jeanne Boyarsky]

Clearly I'm missing something here, but what makes this a J2EE application. I thought a J2EE application had to have an EJB module, web module, client module or (forgot the fourth one)

[Jimmy Clark]

Yes, it is a bit unclear as to "what" is being deployed. "A JAR with some code." lol

It sounds like they are attempting to deploy a standalone Java application, i.e. POJO, in an application server as an enterprise application. Sounds pretty sloppy to me .... and prone to many maintenance and execution problems in the future.

[Martijn Verburg]

Hi all,

My apologies, I did miss one important bit , packaged within each EAR is also a RAR (JCA connector).

As an aside these particular applications have migrated from:

EAR [WAR, RAR, JAR, JAR (with EJBs) and Jboss's HAR and SAR] to

EAR [WAR (But we're looking at removing that, so there's one 'web management console' across the various applications as opposed to one per application), RAR, JAR (with lots of Spring stuff)]

Phew!

[Rosco Duncan]

Clearly I'm missing something here, but what makes this a J2EE application. I thought a J2EE application had to have an EJB module, web module, client module or (forgot the fourth one)

There could be many reasons to want to deploy to a J(2)EE application server, but I imagine that they all pretty much boil down to wishing to make use of services provided to code running in such an environment. This could be the services of an ejb container, and/or a web container, or simply to make use of some of its service abstractions such as managed datasources or the transaction manager.

I think Rod Johnson and co were have been fairly successful in their attempts to convince the enterprise java community that there is J(2)EE life outside the ejb container

http://www.amazon.com/Expert-One-One-Development-without/dp/0764558315

[Jimmy Clark]

How about, it just sounds better if we say it's running in an application server. This may help foster the perception that a basic standalone application which simply requires a JRE is an "enterprise application." A questionable deception, in my opinion.

Clearly, this is not the case for the application described in this post. However, I have come across too many applications "deployed" in an application server improperly and unnecessarily.

[Jeanne Boyarsky]

Martijn: That'd be the fourth one.

Rosco: I didn't say an EJB had to be present. Applications with just a web module are quite common. My confusion was Martijn said he didn't have/want one of those either. Since he does have one of the four types, I'm "un-confused" now.

[Martijn Verburg]

Jeanne Boyarsky wrote:Martijn: That'd be the fourth one.

Right you are! I'm so embedded in the darn things even I forget to mention them, I mean surely everyone uses RARs right? ;)

[Martijn Verburg]

Thanks everyone for your thoughts etc, we've decided for now that we'll take a 'pragmatic' approach and retain the smallest of WARs containing a single 'kick start' servlet, that way it is at least usable across multiple app servers. I was leaning towards going back to the Jboss SAR mechanism (because it just seems 'right'), but we'd have to find a new mechanism everytime we went to a new app server (which we do need to factor into the design).