Marc
Marc

Reputation: 78

Java EE stop application programmatically

I'm part of a project to rewrite a SE application in EE. We're currently using JBoss 7.1.3 as our supported application server, but are obviously trying to minimize AS specific code in the interest of portability.

A little background on our application...It accepts processing requests from systems (MDB/Webservice) and fulfills the request by interfacing with a number of other systems. System processing auditing is database driven.

Current functionality in the existing application is that the application shuts itself down in the event of a database connection loss to prevent unaudited processing. So, I've been looking around to see if there would be any standard way of recreating this functionality in a portable way. I guess I'm wondering if there's any standard way of stopping an application programatically from within the application itself or if you have any thoughts on providing similar functionality.

So far I've seen that there may be ways to hook into JBoss via JMX and undeploy an application or possibly stop MDB delivery...but I'm concerned about portability since it would all be AS specific. I'm not only concerned about portability across ASs but even across different versions of the AS...since the process for these actions seems to have changed over different JBoss releases.

Upvotes: 2

Views: 1290

Answers (2)

tgkprog
tgkprog

Reputation: 4608

when you say stop the app you mean System.exit(0) ? You can do that in Jboss/ EE code too as long as the app being run is only yours (not a shared jboss)

If it is shared (by other apps in your company or a shared provider)

  1. send an error response to the clients you serve
  2. write to a log file and if that succeeds then continue servicing (log can be transferred to database - this wont work if db has to be latest all the time)
  3. use connection pooling to maintain the data base connections -> just a suggestion to keep it better. also can use an alternate data base if main not reachable. again this depends on business / your particular situation
  4. To be portable and responsive - respond with null/ empty set. Also have a status screen -> way of telling clients/ support of the status of the app and or events (like db or other resource was not available from time to date-time). Implementation: each API function could first have a AOP intersect to handle this in a common way.

if you want to un-deploy can have a basic design of one abstract class and then a version for each app server/ app server variant. once your on a app server hardly think you will be changing or adding more, very often. maybe you can suggest this to oracle for a future JSR / feature of a web/ ejb application

Upvotes: 0

Pradeep Pati
Pradeep Pati

Reputation: 5919

I believe if such a feature exists, it would really be a vulnerability, because an AS is designed to run multiple Apps. And if in one such shared server, a single application goes rogue, that would cause outage for rest of the apps.

Still, you can a do it by executing shell scripts, by getting the runtime, only that it won't really be a portable code.

Upvotes: 1

Related Questions