Re: Start and Stop JBoss and Websphere servers

[blindluke]

Hello, Karthik.

It looks like you are trying to automate application deployment. Before you start rolling your own solution, look at the already available scripts - this is a fairly common task.

You are writing about copying the .war file - keep in mind that it won't deploy the .war application on a production environment. If you are dealing with a development / test environment, you might have a "monitored directory" - a simplified setup that allows to deploy apps just by copying the file to the monitored directory. This will not work in a live production environment, you will have to update your solution to automate the application deployment.

If, however, you only want to automate your development environment, start by looking at the Starting and stopping quick reference page in the WebSphere documentation. This should be of some use to you.

[karthik.raju]

Thanks Luke for your response,

Luke, cant we do direct deployment of war even in JBoss, like stopping, copying and starting the JBoss Server ?

Thanks, Karthik

[blindluke]

I'm working with WebLogic on a daily basis, and have some experience with WebSphere. Both of those support autodeployment, but only in development mode. In a testing Weblogic environment, you don't even have to shutdown the server - the application placed in the directory will be recognized and deployed automatically. Both Oracle and IBM discourage the use of this features and make them unavailable in production mode.

I had to check how JBoss deals with this concept. It seems that they are calling the feature "hot deployment" and, as far as I have read, they allow it in production environment. Strange practice. But they too have a command line interface that could be helpful to you.

[karthik.raju]

Hi Luke,

i've got the solution.

Thanks a lot for your valuable explanation.

-Karthik

[roboticus]

karthik.raju:

Sure, you could probably do it easily enough. But if you have to support it, you probably won't appreciate having written it. Many times, you'll think the task is pretty simple and straightforward, you'll write it, and implement it.

...and then three weeks later, about 11:30 PM on a Saturday, it'll fail because one of the many special cases possible triggers. And you get a phone call, only to discover "Oh, yeah, the WAR files are on a remote store that was down for maintenance so the deploy didn't occur, so it didn't get deployed properly." So you make the fix, reimplement it and go back to sleep.

When you're managing production processes, there can be more special cases than you care to think about. So if you have to roll your own, think a good bit about handling the problems that will eventually arise, then think some more. But if you can find an off-the-shelf solution that manages the process for you, why not save yourself the trouble?

...roboticus

When your only tool is a hammer, all problems look like your thumb.