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.

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

Call setLibraryDirectory on different MLets that may want to load libraries of the same name.
  xxxxx@xxxxx   2003-12-17

---
In order to avoid this problem the MLet service can rename the native library
supplied in the jar file when copying it in the MLet library directory on disk.
This will allow two separate applications using an MLet service configured with
the same library directory to load the same native library as the name of the
library on disk will be different (and unique). As a consequence of this fix,
two MLets running on the same JVM will be able to load the same library too.
luis-  xxxxx@xxxxx   2003-12-18
---

Fix done. Same native library can be loaded now from two different MLets
without file name clashes.
luis-  xxxxx@xxxxx   2004-01-02
---