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.

Modules

The ULC release is split into modules. Each module belongs to exactly one of five categories:

src
Either complete source code or source stubs.
The source stubs are used to enable code completions in IDEs.

webapp
Only for sample modules: ready to deploy web application, i.e. war files

Parts

Each of these modules can contain up to four parts:

Client
Contains classes to be deployed on the client side.
Runs inside the sandbox.

Trusted
Contains classes to be deployed on the client side.
Does not run inside the sandbox. The additional permissions required depend on
the module.

Server
Contains classes to be deployed on the server side.

Development
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.

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).

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:

ULCWindow.dispose() triggers JWindow.dispose() on the corresponding client window.
Otherwise JWindow.dispose() does only happens in ULC, if the UIWindow (the client-side proxy)
proxy gets deregistered.

Migration Notes

New/Changed API

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 Configuration

Prior 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.properties
cannot 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.)

Known Problems and Limitations

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)