RAFW update ear without WAS deploy options
Hello,
following RAFW instructions for the deployment of an ear file, you are supposed to find out the wsadmin deployment options and place it in the OPTIONS argument of the associated properties file. However, as the "was_common_deploy_install_app" action is able to both install the application for the first time and update it, I have checked that running for an existing application with no parameters in its OPTIONS statement will update the ear file preserving all the "already in place" deployment options in WAS.
Is this a good approach when I want just a process for updating my WAS apps without having to emulate a deployment from scratch?
Are there any side effects to take in count if using approach?
Thanks in advance for your help.
Regards,
Jorge.
following RAFW instructions for the deployment of an ear file, you are supposed to find out the wsadmin deployment options and place it in the OPTIONS argument of the associated properties file. However, as the "was_common_deploy_install_app" action is able to both install the application for the first time and update it, I have checked that running for an existing application with no parameters in its OPTIONS statement will update the ear file preserving all the "already in place" deployment options in WAS.
Is this a good approach when I want just a process for updating my WAS apps without having to emulate a deployment from scratch?
Are there any side effects to take in count if using approach?
Thanks in advance for your help.
Regards,
Jorge.
6 answers
Hello,
following RAFW instructions for the deployment of an ear file, you are supposed to find out the wsadmin deployment options and place it in the OPTIONS argument of the associated properties file. However, as the "was_common_deploy_install_app" action is able to both install the application for the first time and update it, I have checked that running for an existing application with no parameters in its OPTIONS statement will update the ear file preserving all the "already in place" deployment options in WAS.
Is this a good approach when I want just a process for updating my WAS apps without having to emulate a deployment from scratch?
Are there any side effects to take in count if using approach?
Thanks in advance for your help.
Regards,
Jorge.
Hi Jorge,
Your observations are correct: the action does install or upgrade, depending on the current installation status of the application. If the app is already installed, you do not need to apply an OPTIONS string and the current settings will reign.
There is nothing wrong with this approach; except that when you are ready to promote the application and its configuration to a new cell, the app installation will fail since the OPTIONS string won't be in the promoted appName.properties file.
Cheers,
Alden
This didn't happen to me.
When I update an application, the JDBC binding was overwritten by the application's deployment descriptor. I had to put this in the APPNAME.properties to keep the existing setting.
options.update.ignore.new=true
John,
any concrete place in the properties file where to put this option?
Thanks!
Regards,
Jorge.
There is no specific place to put this line. Any where within the APPNAME.properties file will do fine.
John,
any concrete place in the properties file where to put this option?
Thanks!
Regards,
Jorge.
This didn't happen to me.
When I update an application, the JDBC binding was overwritten by the application's deployment descriptor. I had to put this in the APPNAME.properties to keep the existing setting.
options.update.ignore.new=true
John,
any concrete place in the properties file where to put this option?
Thanks!
Regards,
Jorge.