Tuesday Jun 09, 2009

Update Center: Updates Made Easier

The Update Center toolkit has already made applying updates to projects like GlassFish, MQ and Web Space Server easy.  With the release of Update Center 2.2 that process just got easier.

In prior releases the Update Tool GUI or the pkg(5) CLI were the primary mechanisms available to apply updates.  This had its limitations.  For example if a developer wished to update multiple applications, each need to be selected, "Available Updates" checked and then applied before repeating for the next application in the list. Easy enough if only one or two applications are being maintained.  More than that and the process becomes fairly heavyweight.

Enter Update Center 2.2.  In this release we have introduced a new streamlined update mechanism.   The new Software Update GUI can detect and apply updates simultaneously across multiple application images maintained on a system.  Applying updates is as easy as two mouse clicks (1. accept the license 2. click Install) to update the applications.

Here's a look at the new Software Update GUI:

Software Update GUI Image

How does it work?

The new Software Update GUI is typically started by clicking on the notification balloon generated by the Update Center desktop notifier. The tool checks for updates in the application images registered with the Update Tool.  Only those applications with pending updates are displayed. These applications will be preselected in the tool.  To apply the updates just accept the license and click Install.

The tool will then apply the updates in a serial fashion to each of the selected applications.  An install dialog tracks the progress:

Applying an update

Details of each update are available for review after the update completes.

There are a couple of other features of the tool worth mentioning.  If an application update contains security related fixes or enhancements they will be identified with the security emblem:

You can also select an application to view more details about the update:

The Software Update GUI is also connected to an atom feed that allows it to recommend featured add-on software that is applicable to the applications which are already installed.  Select the add-ons you wish to install and they will be included in the update process when you click Install.  If the add-on can be applied to more than one image you will be prompted to indicate which images to apply the add-on to.  Overall a fairly streamlined process.

The Update Tool is still available to provide finer grain control over which components in an application are updated.  To access the Update Tool simply click on the "Manage Details" button at the bottom of the tool.

Tuesday Apr 28, 2009

Java Enterprise System 6

The Java Enterprise System 6 (Java ES) product released yesterday.  The Java ES product is comprised of a suite of more than eight products which have been designed and tested to interoperate.  One of the primary goals of Java ES is to design products such that they share common system level characteristics.  These characteristics include such items as platform, browser and web container support to name just a few.

The common system level characteristics which Java ES products are expected to adopt are defined in a specification called the Software Infrastructure System Requirements Document (SRD).  The SRD is updated twice a year with input from engineering, marketing and the field.  It covers a range of topics which are applicable to most products.

The items in the SRD are presented as a set of requirements and informational items.  Products under development are expected to adopt a specific SRD version and implement the requirements of the SRD as part of their product release.  General areas the SRD covers include:

  • Platform support
  • Virtualization
  • Interoperability
  • Compilers
  • Java SE and EE
  • Browser support
  • Database requirements 
  • Installation and update requirements
  • Security
  • Branding and naming
  • Product life cycle

Many of the requirements establish a floor or minimum.  This allows product teams to do more than required in order to support their customer needs.

Prior to the existence of the SRD each product team would make their own decision about which browsers, databases and platforms they chose to support.   This lead to inconsistencies across products and made it difficult for customers to integrate products into a common solution.  The existence and adoption of the SRD aligns products on common requirements and thus eliminates integration issues that can hinder product adoption.

Friday Nov 21, 2008

Update Center: Desktop Notifier Start Up

In my  entry last month I discussed some ways to manage the Update Center's desktop notifier.   In the upcoming release  of version 2.1 of the Update Center project  the team added some additional mechanism to launch the notifier.  The most noticeable change is the update preferences accessed via the updateool GUI:

Preferences Dialog

The "Automatically check for updates" check box is used to indicate whether the notifier should be started automatically when  you log in to your desktop.    If this check box is selected when this dialog is applied the notifier will be registered  as a log in start up task.   The notifier will also be started immediately at that point.   If the notifier is already running the newly started notifier will silently exit.

If the "Automatically check for updates" check box is not selected when the dialog is applied the notifier will be unregistered as a log in start up task.   Any currently running notifier instances will be shutdown when the dialog is  dismissed.    By selecting or deselecting (and applying) the check box the current notifier operation can be controlled.

In UC 2.0 the updatetool GUI would automatically (as a background task) register the notifier shortly after it is started if the update check frequency is set to daily, weekly or monthly.   This still occurs in UC 2.1 (if the "Automatically check for updates" check box is selected).  New in version 2.1, the updatetool GUI will also start the notifier automatically shortly after the GUI is launched.  This instance of the notifier will silently exit if another instance of the notifier is already executing.

We also added the ability to stop the notifier from the command line:

% updatetool --notifier --shutdown

This command has no output.   It simply sends a message to the running notifier to shutdown.    This command is useful on Windows in the scenario where a user wishes to move or delete an application folder but is blocked because the running notifier instance was started from within the folder.   Windows will not allow a folder to be deleted if files within the folder are still in use.  

 Current builds of Update Center can be accessed through our download site:


 These changes will appear in build 18.

Wednesday Oct 08, 2008

Update Center: Managing the Desktop Notifier

The Update Center desktop update notifier is a small application that resides in the system tray or task bar. It monitors registered application installations and package repositories periodically to see if any updates are available for the software installed by the user. When updates are available the notifier informs the user and subsequently allows the user to review and apply the updates.  You can see some of the screenshots for the notifier on the Update Center wiki

Generally the notifier is started when a user logs into their desktop. In order for the notifier to be started when a user logs in it must first be registered as a log in start up task.

There are a couple of paths that will result in a registered notifier. For example the GlassFish v3 Prelude installer allows the user to "Enable Update Tool".  By selecting this option the notifier will be registered and started as part of the GlassFish installation.  Here's an example of the GlassFish Update Configuration screen:

Some products may use the Update Center's bootstrap and stub scripts as a way to minimize the download size of the product as well as maintain platform neutral distributions .  When the user launches the updatetool bootstub (to install the actual Update Tool packages) it will register and start the notifier:

% updatetool

The software needed for this command (updatetool) is not installed.

If you choose to install Update Tool, your system will be automatically
configured to periodically check for software updates. If you would like
to configure the tool to not check for updates, you can override the
default behavior via the tool's Preferences facility.

When this tool interacts with package repositories, some system information
such as your system's IP address and operating system type and version
is sent to the repository server. For more information please see:


Once installation is complete you may re-run this command.

Would you like to install Update Tool now (y/n):

(package installation output deleted)

Registering notifier: Successful.
Starting notifier.
Initialization complete.

If the notifier was not registered during installation it can be registered post install.  The Update Tool GUI application will attempt to register and start the notifier (if it is not already registered and running) shortly after it is launched if the update check frequency preference is set to a value other than "Never".  You can check this preference via the Updates tab in the Update Tool Preferences dialog.

Finally the notifier can be started manually from the command line like this:

% updatetool --notifier

but only one instance of the notifier per user can be running simultaneously. So if the notifier was started as a log in start up task a second instance started manually might complain:

% updatetool --notifier
Update Tool Notifier: The tool is already running.

Is the Notifier Registered?

There is an easy way to determine if the notifier is registered as a start up task on your system.  Go to the directory where you installed Update Tool or Glassfish and navigate into the updatetool/bin directory.  The updatetoolconfig tool can be used to manage the notifier's registration.  To see if the notifier is already registered run updatetoolconfig like this:

% updatetoolconfig --list

If this doesn't display any output then the notifier is not registered.  The tool also returns an exit code of 1 if the notifier is not registered.

Registering/Unregistering the Notifier

You can also use the updatetoolconfig tool to manually register and unregister the notifier:

% updatetoolconfig --register


% updatetoolconfig --unregister

A couple of comments about these operations.  If a notifier is already registered then --register will not work.  To override the existing registration you can use the --register --force options.

If there are multiple installed product images that the notifier is monitoring on the system then a simple --unregister will not unregister the notifier.  The notifier can only be unregistered this way if there is only one monitored image remaining (more about this in a future blog entry).

To force the notifier to be unregistered when there are more than one installed product images on the system use the --force option along with --unregister.

You can alway verify the registration or unregistration was successful by using the --list option.

Registering the notifier with the updatetoolconfig tool will not cause the notifier to be started immediately.  You must log out and then log back in to trigger the start of the notifier.

Notifier Firewall Interaction

When the notifier is started it opens a port and listens for connections from the Update Tool.  If this is the first time the notifier is run it may trigger your firewall to display a security alert indicating that Python (the notifier is based on Python) is attempting to connect to the network.  You should allow this operation.


Chris Kasso-Oracle


« July 2016