Release NotesAugust 7, 2006
About ULC 6.1.1
Release 6.1.1 is a maintenance release for ULC release 6.1. It includes the following changes:
To migrate from ULC 6.1 to ULC 6.1.1, please see the migration notes.
ULC 6.1.1 requires the Java Runtime Environment (JRE) 1.3.1 or later on the server, and Java Runtime Environment (JRE) 1.4.2 or later on the client.
The ULC client has been tested on Windows 2000/XP with the following deployment options:
- Applet: Running the ULC client as an applet has been tested with the following browsers:
- Firefox 1.0.3
- Microsoft Internet Explorer 5
- Microsoft Internet Explorer 6
- Java Web Start: Running the ULC client using Java Web Start has been tested with Java Web Start 1.4.2_05 and Java Web Start 1.5.0_04.
The ULC server has been tested on Windows 2000/XP, Red Hat Linux 9.0, and Sun Solaris 8 with the following deployment options:
- Servlet container: The Servlet integration has been tested on
- EJB container: The EJB integration has been tested on
This build is based on ULC 6.1 Please see the ULC 6.1 release notes for additional information.
Modules, Parts and Release Structure
The ULC release includes all components required to successfully develop and deploy ULC applications. The ULC modules, parts, packages, and the structure of the current release are described in the following sections.
The ULC release is split into modules. Each module belongs to exactly one of five categories:
The ULC core.
Always needed, for development and deployment.
Server-side integrations into containers, e.g. Servlet, EJB.
Only needed for server deployment.
Client-side integrations into environments, e.g. Applet, JNLP.
Only needed for client deployment.
Samples demonstrating the usage of ULC, e.g. Hello, ULCSet, OnlineShop.
Not needed during development or deployment.
The category and module names are reflected in the directory structure of the release, e.g. environment/applet for the applet module that belongs to the environement category.
A module directory contains subdirectories with the following contents:
Jar files that contain the module classes.
For sample module the required libraries.
Only for sample modules: the required resources, e.g. images, property files
Either complete source code or source stubs.
The source stubs are used to enable code completions in IDEs.
Only for sample modules: ready to deploy web application, i.e. war files
Each of these modules can contain up to four parts:
Contains classes to be deployed on the client side.
Runs inside the sandbox.
Contains classes to be deployed on the client side.
Does not run inside the sandbox. The additional permissions required depend on the module.
Contains classes to be deployed on the server side.
Contains all classes needed during development, i.e. the client, trusted, and server parts plus some additional development classes.
The part names are reflected in the filename of the jar files in the lib and src directory of the corresponding module, e.g. ulc-applet-client.jar and ulc-applet-client-src.jar for the classes and source stubs of the applet module that have to be deployed on the client side.
|ulc-6.1.1||ULC 6.1.1 home directory|
|base||ULC base framework|
|J2EE server integration including EJB container integration and Servlet container integration.|
|Client environment integration for applet deployment, JNLP deployment, and standalone deployment.|
|license||the jar file with the deployment license key|
|previous_releasenotes||Previous release notes|
|Sample applications with ready to run Tomcat Servlet container|
|build.txt||Contains the build number|
|LicenseAgreement.pdf||The license Agreement|
|UBA-807||Ability to invalidate an HTTP server session from a ULC application||ServletContainerContext.getHttpSession().invalidate() does invalidate the HttpSession. However, it is not a clean way to shut down a ULC application on the server side.|
|UBA-964||Input is not blocked anymore when reloading an applet|
|UBA-6803||Calling the method waitForIdle() in UISession from different threads may lead to lock-up|
|UBA-6893||ULCSplitPane does not provide a method setDividerLocation(int newLocation)||ULCSplitPane.setDividerLocation(...) has been aligned with Swing.
|UBA-6911||Configuration of a ULC application overrides part of configuration of other ULC applications in same web application||Log configurations (and in particular the log levels) are now per Servlet (or EJB) instance. A related configuration's scope is the code of all the ULCSessions associated with a Servlet or EJB instance. However, (ULC) code executed inside a Servlet/EJB but outside a ULCSession depends on a single, global log configuration. The latter can be set via a (global) properties file (ulclog.properties). See migration notes.|
|UBA-6921||An ArrayStoreException is thrown in ULCProxy.invokeUI() when trying send/upload an array with type ULCProxy|
|UBA-6922||The initial size and position of a ULCWindow is not synchronized back to server|
|UBA-6926||For modal dialogs, WindowClosingEvents and state updates are not propagated to the server|
|UBA-6928||When showing a modal dialog a second time, the default button is lost||ULC's behaviour is now the same as in Swing: A default button gets uninstalled ONLY,
if a ULCWindow (and also a ULCDialog) gets explicitly disposed.
In this context, disposing of a window has been aligned with Swing. New API:
|UBA-6931||Non-opaque components added to a tabbed pane look different in Swing and ULC on Mac OS X|
|UBA-6934||ULCAppletPane does not support resume|
|UBA-6947||Custrom renderer for ULCComboBox do not work properly|
|UBA-993||ULCBoxPane's add() method takes ULCBoxPane alignment constants, setConstraints GridBagConstraints||New API:
|UBA-5738||Support shared library deployment||ULC now uses a context class loader when dynamically loading classes given that a context class loader is set|
|UBA-6836||Add the "open" command as default "fBrowserPath" element for the Mac platform in AllPermissionsBrowserService|
|UBA-6872||Provide a hook in UIAlert.show() before a corresponding alert dialog is shown||The corresponding hook is UIAlert.prepareAlertDialog(JDialog). (Its default implementation does nothing.)|
|UBA-6876||Two consecutive error dialogs are shown when the connection to the server is lost|
|UBA-6877||Provide a log statement with the command line string in the com.ulcjava.base.client.IBrowserService implementations|
|UBA-6887||Clarify the Javadoc for IWindowListener.windowClosing(WindowEvent event) and ULCDialog.setDefaultCloseOperation(int)|
|UBA-6912||Provide a getInvoker() method on ULCPopupMenu just as for JPopupMenu|
|UBA-6914||Client side enabling state should be synchronized when using enablers|
|UBA-6916||Provide a ULCComponent.requestFocusInWindow() API just like on JComponent|
|UBA-6927||JSSE integration add-on does not make sense in ULC 6.1 as JRE 1.4 already includes JSSE||The related files have been removed from the release.|
|UBA-6930||Provide a callback before removing UIProxies from the client-side registry||The coresponding callback is UIProxy.dispose().|
|UBA-6962||ULCBoxPane.add(ULCComponent, Object) should accept alignment strings as a second argument|
|UBA-6963||ULCTabbedPane.setTabPlacement() should check for a valid tab placement argument|
|UBA-6964||ULCSplitPane should support add() without explicit constraints|
- ULCSplitPane: Due to the fix for UBA-6893 the API for ULCSplitPane.setDividerLocation() has changed. The method setDividerLocation() is now overloaded such with setDividerLocation(int) and setDividerLocation(double). To ensure that the correct setDividerLocation() method is used, customers migrating to 6.1.1 should change code statements like setDividerLocation(1) to setDividerLocation(1.0). The method getDividerLocation() now returns an int value. The former method "double getDividerLocation()" has been renamed to getDividerLocationRelative(). Customers migrating to 6.1.1 should therefore change code statements like getDividerLocation() to getDividerLocationRelative().
- ULCWindow.dispose() now allows for explicit control over the deallocation of native window resources on the client side. Invoking ULCWindow.dispose() triggers JWindow.dispose() on the corresponding client-side Swing/AWT window. Prior to ULC 6.1.1 JWindow.dispose() was implicitly called whenever the corresponding window was made invisible (via ULCWindow.setVisible(false)). With ULC 6.1.1, the method ULCWindow.dispose() now also triggers the method ULCWindow.removeNotify(). (This behaviour is now similar to Swing's behaviour concerning JWindow.removeNotifiy().) Note that ULC does not do any implicit calls of JWindow.dispose() anymore (e.g. as part of other server-side API methods). The only exception to this rule is when the client-side UI proxy (the UIWindow instance) get deregistered from ULC, e.g. because the proxy becomes garbage collectable or because the application stops.
Logging ConfigurationPrior to ULC 6.1.1, the logging configuration of a ULC application overrid the logging configuration of other ULC applications in same web application. In particular, the log level could only be set globally for a JVM instance. With ULC 6.1 the log level can be set per Servlet/EJB instance. Thus different log levels of different ULC servlet do not override each other. However, the so-configured log level only affects logging for method calls, which are under the control of a ULCSession instance (i.e., they have a ULCSession method invocation in their stack trace). Logging outside the ULCSession instance may only be set globally via the properties file
ulclog.properties. If the file
ulclog.propertiescannot be loaded as a resource, then the default log-level WARNING is used for the global log-level context. (The global log-level context affects the logging of methods defined on com.ulcjava.container.servlet.server.ServletContainerAdapterHelper and com.ulcjava.container.ejb.serverEjbContainerAdapterBean.) For details on the new logging approach see Section 6.3 of the ULC Essentials Guide.
- In a signed applet default cut/copy/paste using [ctrl]+x / [ctrl]+c / [ctrl]+v is broken. This is a Java Plugin bug not a ULC problem (see Java Bug Database). This problem only affects Java Plugin 1.4.2.
- After completion of a drag-and-drop operation, the mouse cursor is not set back to the default cursor. This problem only occurs on Linux. (UBA-686)
- Inappropriate mouse cursor feedback during drag-and-drop is observed if the drop target component rejects the drag operation. This occurs only in pre JRE 1.4.2. (UBA-756)
- Applet deployment does not work for Opera. (UBA-767)