Sometimes customizations or settings need to be applied directly inside the application EAR files of IBM WebSphere Application Server.
For example, the request to create zip files larger than 2 GB requires adjustments to the EAR file. We need to update the file on each WebSphere node, or build an update file to apply the setting.
In the case of the zip file size, we change Files.ear/config/com.ibm.lconn.share.platform.bootstrap.properties. To automate the update, we copy the file and create a JAR file to apply in the WebSphere ISC.
cd /tmp
mkdir config
cp /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/ConnectionsCell/Files.ear/config/com.ibm.lconn.share.platform.bootstrap.properties config
vim config/com.ibm.lconn.share.platform.bootstrap.propertiesIn the copied file, change download.zip[@maximumSizeInMb]=4096 to download.zip[@maximumSizeInMb]=8192 and save.
It is important that the filename and path under /tmp match the original location inside the EAR. In this case, the folder is config and the filename is com.ibm.lconn.share.platform.bootstrap.properties.
Create the update.jar File
#
The name update.jar is just an example — you can choose any filename.
Using the jar command (requires Java)
#
cd /tmp
jar cvf update.jar configUsing zip
#
cd /tmp
zip -r update.jar configExample output #
/opt/IBM/WebSphere/AppServer/java/bin/jar cvf update.jar config
added manifest
adding: config/(in = 0) (out= 0)(stored 0%)
adding: config/com.ibm.lconn.share.platform.bootstrap.properties(in = 14150) (out= 6082)(deflated 57%)Move the created JAR to /opt/IBM/WebSphere/AppServer/temp for easy access.
Applying the Update #
Before applying update.jar, the config directory looks like this (on a system running 8.0 CR12):
ls -al /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/ConnectionsCell/Files.ear/config/
total 28
drwxr-xr-x 2 root root 63 Jan 13 16:22 .
drwxr-xr-x 6 root root 8192 Jan 13 16:22 ..
-rw-r--r-- 1 root root 14150 Oct 27 21:26 com.ibm.lconn.share.platform.bootstrap.propertiesOpen the WebSphere ISC and navigate to Applications > Application Types > WebSphere enterprise applications, select Files, and click Update:
Click Next > OK > Save, then synchronize the nodes under System Administration > Nodes > Full Resynchronize.
Now verify the config folder in Files.ear:
ls -al /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/ConnectionsCell/Files.ear/config/
total 28
drwxr-xr-x 2 root root 63 Feb 27 10:00 .
drwxr-xr-x 6 root root 8192 Jan 13 16:22 ..
-rw-r--r-- 1 root root 14150 Feb 27 09:42 com.ibm.lconn.share.platform.bootstrap.properties
grep 8192 /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/ConnectionsCell/Files.ear/config/com.ibm.lconn.share.platform.bootstrap.properties
download.zip[@maximumSizeInMb]=8192The updated timestamp confirms the file was replaced, and the grep output confirms the new value is in place.
Be aware that changes to EAR files must be reapplied after each product update!
Summary #
This is the simplest way to update files inside WebSphere application EAR files. The process applies updates across all nodes automatically, saving you from having to edit files manually on each node.
I originally looked into this while working on updating APNS certificates in the Mobile app. These certificates expire on March 13th, and the only available update that includes new certificates is 8.0 CR13. Unfortunately, the updated certificates are not mentioned in the CR13 fix list or What’s New page.
Any system on an earlier CR release needs to update the certificate store to keep Apple Push Notifications working after March 13th.
It is not enough to extract the p12 file from Mobile.ear/mobile.web.war/WEB-INF/classes/certificates/Connections_APNSCertificate.p12 in CR13. You also need to read the keystore password from com/ibm/lotus/connections/mobile/push/notification/service/ios/PushNotificationService.class (which requires decompiling the class file, stored inside Mobile.ear/mobile.web.war/WEB-INF/lib/mobile.push.notification.jar).
To update the certificates without an official fix from HCL, you need the PushNotificationService.class from both your running system and from CR13. Decompile both versions, retrieve the password used to open the new keystore, then re-save it using the password from the old keystore. This allows the deployed Mobile app to read the updated certificates.
Decompiling Java class files is outside the scope of this post, but JD-GUI is a good tool to get started.