#3 Integrate UDDI client into Data Portal

[Donald Hobern]

At present the UDDI client classes (accessed through
the org.gbif.registry classes) are only accessed
through the org.gbif.registry.RegistryLoader tool which
is executed from the command line.

An attempt was made at an earlier stage to integrate
these functions into the Data Portal so that they could
be executed on a regular (daily basis) to keep the
Provider, Service and Binding tables fully up-to-date
at all times. This apparently failed because of
dependency conflicts between JARs used by the WASP
UDDI client JARs and Tomcat.

This problem needs to be resolved so that the gbifAdmin
application can indeed execute
RegistryLoader.loadRegistry() on a daily basis. A
RegistryTracker instance should be used (as in "java
org.gbif.registry.RegistryLoader -R") to identify any
Providers, Services or Bindings which have been removed
from the UDDI registry. When these removals occur, an
e-mail should be sent to the Portal e-mail addresses
including links to gbifAdmin JSPs to remove the
database entries corresponding to these UDDI entries.
The purpose of the e-mail is to allow an administrator
to take a decision before actually removing the entries
(since it may be a temporary glitch in managing the
UDDI registry). For this reason the JSPs should
require user confirmation before actually performing
the removal.

[Damian Barnier]

Logged In: YES
user_id=1106482

This has been fixed and all files commited to CVS.

The UDDI client has been upgraded to the latest release from
systinet, and the org.gbif.registry package updated to use
the modified API.

Several JSPs have been added to the admin portal, and a UI
manager class added to the org.gbif.ui package to prepare
the content of these pages.