Name: poR10007 Date: 12/17/2003



The MLet service provides the ability to load MBean classes and native libraries
from a remote server. On win32 systems the algorithm of downloading and storing
native libraries in the TEMP directory does not allow to load native libraries
with the same name from different applications (and possibly from different
MLets). Let's one application creates a new MBeanServer, initializes m-let
service and calls getMBeansFromURL() to load an MBean stored in some jar-file.
The MBean uses a native library stored in the same jar file. When another
application running on the same system attempts to initialize an MBean
which uses the same native library, it fails. Looking at the API sources
I'd say any application trying to load a native library with the same name
through m-let service will fail.

The cause of the failure is that the temporary native library file on win32
system is write-locked while application using it is running. On Solaris
system this file can be re-written that's why the tests pass on Solaris.
But could be here a race condition when two application try to rewrite
this file simultaneously? It seems that the algorithm of dynamic loading of
native libraries should be improved.

The test reproducing the failure will be attached. Running on jdk1.5.0-b31
it fails on WinNT, Win2000 and WinXP platforms and passes on Solaris.

======================================================================