Restarting w/o deleting already deployed apps.

[tosehee]

Hi. I am fairly new to Jboss and running through the process.

I am currenting using the latest stable build (2.4.4 with Tomcat), and have one particular question regarding jboss startup and deployment.

I have number of configuration files that can be modified throughout the application life time, and whenever I restart the jboss, all those configurations are reset as it was before. The issue is, Jboss deletes all the tmp directory where the application was first deployed even though I didn't re-deploy, but just restarted. There are tons of binary files that I also uploaded, and they all go to tmp/deploy/Default subdirectories which also gets deleted whenever I restarted.

Is there anyway I can stop this or bypass, so it doesn't redeploy the already deployed apps?

Thanks for your response.

Se Hee

[lasterra]

Why don't you save this files in another folder???

[tosehee]

Well, that's what I did for now. But, I want to be as much free as possible with possible security issues associated with saving the files to different directory and etc.

Se Hee

[adrian.brock]

You can unpack your deployment.
Basically create directories called myapp.war instead of
an archive but with the same structure.
To redeploy, touch the deployment descriptor.
The unpacked deployment is deployed in place rather
than copying to tmp. It is not deleted at undeployment.

Everything has to be unpacked.

It isn't considered good practice to write back
into a deployment.
The unpacked deployment is intended for development.

Regards,
Adrian

[tosehee]

Thanks for tips. I will try that for now.

Se Hee

[blaine]

J2EE is supposed to provide improved responsiblity
delineation. If a runtime administrator wants to change
a run-time parameter like "maxExemption" or "taxRate"
on a production server, why must he rebuild and re-deploy
an ear file? (I know "why" in the sense that the mods
are in the web.xml or ejb-jar.xml file, but why have
run-time variables buried 2-levels deep inside an ear
file?)

This would be a trivial text file edit with a conventional
UNIX daemon program. IMO, production-only setups should
not require build-tools like ant to be present.
Am I missing some reason why embedding JNDI or other
mappings is somehow better than progams like inetd,
sshd (and in some cases httpd), that re-read independent
text config files when you give them a HUP signal?

[wchao]

I think the intent was to make distribution and deployment as easy as possible. It's hard to go wrong with just one file. As for the deployment descriptors, they can either be edited with a GUI tool that automatically unpacks the archive and repacks it with the updated descriptors. Alternatively, you could manually unpack, edit, and repack. Ant is certainly not needed -- just some familiarity with either the GUI deployment tool or the jar command and an editor.