DougBreaux 270007SMYJ Visits (3016)
I got tired of updating a dozen applications at once, across development, test, and production systems, from the WebSphere admin GUI.
So, here's a very simple wsadmin script, updateApp.py, based on Upda
wsadmin -f updateApp.py appName filePath [nosync]
Where the optional "nosync" parameter tells the script not to sync out the changes after update and save. In case you want to do more than one, then sync them all at the end.
WARNING: if you have more than one application installed, be very careful that you match the application name with the correct file.
Here's another script, updateAppList.py, that I admit I haven't tested yet, that should allow you to edit a list of apps/ears to update, then update them all at once.
DougBreaux 270007SMYJ Visits (3212)
This script will iterate through a list of name/URL pairs and create new Cell-level URL Resources for them.
Yes, it might be nice to have it take a command-line pair as well. And/or a command-line file that contains pairs. And support creating the Resources at levels other than the Cell.
But those will be exercises for another day for me :-)
Edit the list of name/url pairs in the file. Uses the default URL Provider, at the Cell level, and sets the JNDI name to "url/name".
While attempting to answer a question on StackOverflow, I experimented a little with some wsadmin commands, so I thought I'd record what I discovered. (I work with the Jython, rather than JACL, versions of the commands mostly because I like the idea of picking up a little of a new programming language which has other uses.)
In this particular case, I wanted to discover runtime System.properties values for a running JVM, of which many are not items you configure explicitly with WebSphere. Thus, after looking at the AdminConfig object and determining that it only had visibility into what you've configured, I determined that the AdminControl object was needed.
Still, here are some AdminConfig commands that I've used and will likely have reason to use again:
You can see where I previously used this approach to create JVM Custom Properties for Application Servers and to determine the (configured) maximum heap for a particular Application Server. (I'll return to that latter case later.)
The AdminControl scripting object is used for operational control. It communicates with MBeans that represent live objects running a WebSphere® server process.
These commands allowed me to locate and query runtime WebSphere objects:
Or skip straight to the JVM:
Or, returning to the maximum heap case from before, now I can see the maximum heap of a JVM even if I haven't explicitly configured one. Either of these variations, invoking a getter method, or getting an attribute, does the same thing:
Finally, here's a way to see which attributes and operations are available for a particular object:
Update: the above only obtains the heap size if a custom value has been explicitly configured. From this other post, here's a mechanism which will obtain the maximum heap size otherwise (note there doesn't appear to be an attribute to obtain the minimum heap size):
I sometimes need to set a custom JVM Property for one or more Application Servers and dislike the tedium of setting them one-at-a-time through the console.
Here's a Jython script for wsadmin to add a JVM Custom Property to a specified Application Server, or to "all" application servers. It will also replace an existing property with a new value and description.
wsadmin -f addJvmProperty.