SEARCH ADD SYS:\JAVA\BIN
following the mount all
line.
This line exists to allow the file server to find Java.nlm and other associated tools for the Java Virtual Machine (JVM).
If the SEARCH ADD SYS:\JAVA\BIN
is placed prior to the FILE SERVER NAME <ServerName>
line, then the DirXML drivers should
autostart at server boot time.
In other words, to fix the problem, simply move the SEARCH ADD SYS:\JAVA\BIN
line to the top of the AUTOEXEC.NCF file,
or at least prior to the FILE SERVER NAME <ServerName>
line.
If the SEARCH ADD SYS:\JAVA\BIN
command is not available to the booting file server when it needs to run Java.nlm,
then DirXML.nlm cannot load and DirXML drivers cannot start. DIRXML.NLM will not load into memory, until JAVA.NLM has already been loaded into memory.
When a file server boots, DS.NLM (NDS) is loaded, but before making the directory service available for usage, DS.NLM checks if DirXML should be loaded,
and if so, attempts to load DIRXML.NLM. At this time, as DIRXML.NLM attempts to load, the server attempts to auto-load JAVA.NLM. If JAVA.NLM
cannot be found due to a "missing" search path, then JAVA.NLM fails to load, DirXML fails to load, and DS.NLM continues its initialization process
without DirXML.
SYS:\_NETWARE
folder which is hidden
on a NetWare file server.
SYS:\SYSTEM\JSAS.NLM
with an older version (02/11/2000)
that does not provide some required SSL calls for the eDirectory driver. The oldest JSAS.NLM
that is compatible with DirXML is
dated 05/09/2000. Locate this file on your DirXML CD, and copy it to the SYS:\SYSTEM
folder.
JSAS.NLM
has two associated .jar files that also have the same date. They are: nssl1.1_dom.jar
and nssl1.1_exp.jar
.
DIRXML.NLM
typically references the .jar files from the SYS:\SYSTEM\LIB
folder.
SYS:\SYSTEM\LIB
directory. Thus, necessary files such as collections.jar
,
CommonDriverShim.jar
, etc. that are typically located in the SYS:\SYSTEM\LIB
directory, become invisible to DirXML.
Hence, DIRXML.NLM
will load, but cannot successfully load a driver. All .jar files located in the SYS:\SYSTEM\LIB
directory with
DOS formatted (8.3 format) names are still visible and available to DirXML.
This problem is normally manifest with an error message to the
DSTRACE screen at driver start time.
When attempting to start the NDSToNDS driver, the error message(s) displayed to the trace screen may be similar to the following:
DVRS: Novell JClient 1.0.19-1.0.19. Copyright 1999 Novell Inc. All Rights Reserved.
DVRS: Error: java.lang.NoClassDefFoundError: com/sun/java/util/collections/Comparable
DVRS: Error: at com.novell.nds.dirxml.engine.nwvrdi.main(Compiled Code)
DVRS: VRDI Initialization Error!
SYS:\ETC
directory of the NetWare Server is
an easy way to appropriately update the java classpath. Once the java.cfg file has been modified, unload JAVA.NLM
and
reload JAVA.NLM
so the new classpath will be "in effect." When JAVA.NLM
is loaded, the java classpath can be viewed
from the system console by typing the ENVSET
command.
The java.cfg file could be modified in similar fashion to the following example, where the additions (the workaround) are emphasized.
Remember all "long-named" .jar or .zip files that would normally be located in the SYS:\SYSTEM\LIB
directory need to be appropriately
referenced in the java classpath, or in other words, included in this java.cfg configuration file, for this workaround to be effective.
SYS:\ETC\JAVA.CFG:
JAVA_HOME=SYS:\JAVA
OSA_HOME=SYS:\JAVA
MGMT_HOME=SYS:\PUBLIC\MGMT
CLASSPATH=sys:\java\lib\classes.zip;sys:\java\classes;.
CLASSPATH=$CLASSPATH;SYS:\SYSTEM\LIB\collections.jar
CLASSPATH=$CLASSPATH;SYS:\SYSTEM\LIB\CommonDriverShim.jar
CLASSPATH=$CLASSPATH;SYS:\SYSTEM\LIB\NetscapeShim.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\swing.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\jgl3.1.0.jar
CLASSPATH=$CLASSPATH;$MGMT_HOME\ConsoleOne\1.2\help
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\servertop.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\jndi.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\njcl.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\vbjorb.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\vbjapp.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\vbjtools.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\lib\ucs.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\
CLASSPATH=$CLASSPATH;$OSA_HOME\beans\NWDir.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\beans\NWSess.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\beans\NWPrtQAdm.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\beans\NWSockets.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\beans\NWBind.jar
CLASSPATH=$CLASSPATH;$OSA_HOME\beans\NWVolAdm.jar
DIRXML.NLM
starts a driver it instantiates a JVM by calling the java class com.novell.dirxml.engine.nwvrdi
(the DirXML engine java entry point on NetWare). To do so DIRXML.NLM
builds an execution parameter string to be consumed by the Java NLM.
This execution string has the following form:
java <DIRXML_JVM settings> -classpath <classpath built by DIRXML.NLM> com.novell.nds.dirxml.engine.nwvrdi -driverID <entryID> -fGetSchema <0 | 1>
DIRXML.NLM
checks each of the above DIRXML_JVM_* variables and appropriately builds the DirXML JVM settings to be placed in the execution
parameter string before launching a JVM instance for a driver.
DIRXML_JVM_INITIAL_HEAP |
set to value in bytes of initial java heap size. Works with 1.1.x and 1.2.x.
Example: DIRXML_JVM_INITIAL_HEAP=4M
Example: DIRXML_JVM_INITIAL_HEAP=4096K
|
DIRXML_JVM_MAX_HEAP |
set to value in decimal bytes of maximum java heap size. Works with 1.1.x and 1.2.x.
Example: DIRXML_JVM_MAX_HEAP=36M
Example: DIRXML_JVM_MAX_HEAP=36864K
|
DIRXML_JVM_VIRTUAL_HEAP |
set to value in decimal bytes of virtual java heap size. Works with 1.1.x and 1.2.x. Example: DIRXML_JVM_VIRTUAL_HEAP=36M
Example: DIRXML_JVM_VIRTUAL_HEAP=36864K
|
DIRXML_JVM_OPTIONS |
set to arguments for the 1.2 JVM.
Example: -Xnoagent -Xdebug -Xdebugport8080 -Xmx36M
Each option string is separated by whitespace. If an option string contains whitespace, it must be enclosed in double quotes. DHOST_JVM_OPTIONS only works with 1.2.x. |
DIRXML_JVM_C_STACK_SIZE |
set to value in decimal bytes of the java C process stack size.
Example: DIRXML_JVM_C_STACK_SIZE=128K (default)
Example: DIRXML_JVM_C_STACK_SIZE=256K
|
DIRXML.NLM
. JAVA.NLM
also gets a copy of the CLIB environment variables at load time, and maintains these environment
variables, and even allows them to be managed using the ENVSET
system console command. When JAVA.NLM
is loaded, the initial
java NLM environment variables are also set within (copied to) the separate CLIB environment. So when JAVA.NLM
is loaded, all settings
within the JAVA.CFG
file are set within the java NLM environment as well as the CLIB NLM environment. In addition, any existing CLIB
environment variables (prior to JAVA.NLM
load time) are attached to the end of the java NLM environment variables. Thus,
after JAVA.NLM
is loaded, JAVA.NLM
and CLIB.NLM
have equivalent environment settings.
Any java NLM enabled "envset" commands which are entered at the system console after JAVA.NLM
load time are only placed within the
java NLM environment and not mirrored in the CLIB environment. In a similar fashion any CLIB.NLM
enabled "env" commands which are
entered at the console command after JAVA.NLM
is loaded are not mirrored to the JAVA.NLM
environment.
When considering DIRXML.NLM
, we are concerned about the CLIB NLM environment variables as they exist at jclntR.nlm
load time.
So any "env" commands that are entered at the system console after jclntR.nlm
has loaded will never be picked up by DIRXML.NLM
because jclntR.nlm
already has its copy of the CLIB environment which it obtained at load time. Likewise, any JAVA.NLM
ENVSET
commands entered after jclntR.nlm
has already been loaded, will not be available to DIRXML.NLM
.
Because of the complicated nature of sharing NetWare environment variables, we recommend that all necessary DIRXML_JVM_* parameters be placed in the
SYS:\ETC\JAVA.CFG
file. In this way, they are guaranteed to be effective.
DSTRACE.NLM
. DSTRACE can be used to display trace messages on the system console. Also trace messages can be logged
to a file (DSTRACE.LOG) using DSTRACE. DSTRACE displays messages to a screen labeled DSTrace Console. Any system console screen label can be
seen on the top of the file server screen when holding down the system console's ALT key. After loading DSTRACE.NLM
, type DSTRACE to see
the current settings of the NLM. An easy way to configure DSTRACE to display only DirXML trace messages is: DSTRACE -ALL +DXML +DVRS
. If you would also
like to display message tags and time stamps use the following: DSTRACE -ALL +DXML +DVRS +TAGS +TIME
.
DS.NLM
. This internal trace method can be displayed to the system
console screen by entering the following set command at the system console: set dstrace=on
. Once the internal DSTRACE is turned on, a system
console screen labeled Directory Services is available for view. Any system console screen label can be seen on the top of the screen when holding
down the ALT key. To turn on DirXML trace messages for this trace screen enter: set dstrace=+DXML
. To turn off DirXML trace messages for
this trace screen enter: set dstrace=-DXML
. To turn on DirXML driver trace messages for this trace screen enter: set dstrace=+DVRS
.
To turn off DirXML driver trace messages for this trace screen enter: set dstrace=-DVRS
. To turn off the internal trace screen enter:
set dstrace=off
.
DIRXML.NLM
also builds an error log: SYS:\SYSTEM\DIRXML.LOG
. Only DirXML errors are stored in this file. This file will not grow
larger that 500K.
SYS:\SYSTEM\DRVSET1.LOG
).
SYS:\SYSTEM\LIB
directory. When located in this directory,
this code must be in the form of a .jar or .zip file. Other code may be accessed by the JVM if it is appropriately referenced by the java classpath.
The following steps are performed when DIRXML.NLM
creates a classpath parameter to be passed to the JVM at driver launch time:
DIRXML.NLM
always puts the following files first (even if they don't exist):
DIRXML.NLM
then appends all files in the SYS:\SYSTEM\LIB
directory with a .jar extension.
These typically are SYS:\SYSTEM\LIB\nssl1.1_exp.jar
, SYS:\SYSTEM\LIB\collections.jar
,
SYS:\SYSTEM\LIB\i18n.jar
, SYS:\SYSTEM\LIB\CommonDriverShim.jar
, and the appropriate driver
.jar files and their dependent pieces (if any).
DIRXML.NLM
then appends all files in the SYS:\SYSTEM\LIB
with a .zip extension.
DIRXML.NLM
lastly appends the current java classpath as it exists on the system at that moment.
DIRXML.NLM
will build a string internally that may look like the following.
Java -Xverify:none -classpath SYS:\SYSTEM\LIB\dirxml.jar; SYS:\SYSTEM\LIB\jclient.jar; SYS:\SYSTEM\LIB\nxsl.jar; SYS:\SYSTEM\LIB\xp.jar; SYS:\SYSTEM\LIB\nssl1.1_exp.jar; SYS:\SYSTEM\LIB\collections.jar; SYS:\SYSTEM\LIB\i18n.jar; SYS:\SYSTEM\LIB\CommonDriverShim.jar; SYS:\SYSTEM\LIB\Nds2Nds.jar; $CLASSPATH com.novell.nds.dirxml.engine.nwvrdi -driverID 37240 -fGetSchema 0
DirXML Log Event -------------------
Status = error
Message = java.lang.OutOfMemoryError:
SYS:\ETC\JAVA.CFG
file. Within the java architecture,
each JVM has a limited amount of memory it can allocate from the operating system. This value can by used to prevent java from consuming all
system memory resources. By default, this maximum memory limit for each NetWare 1.1.7b JVM is 16M (16M == 16 Megabytes == 16384K). By default,
this maximum memory limit for each NetWare 1.2.2 JVM is 64M. If running Java 1.1.7b on NetWare, try inserting the following line into
SYS:\ETC\JAVA.CFG
: DIRXML_JVM_MAX_HEAP=32M
. Or, if running Java 1.2.2 on NetWare, try inserting the following line into
SYS:\ETC\JAVA.CFG
: DIRXML_JVM_MAX_HEAP=128M
. This will double the default maximum memory usage for each JVM.
Remember to unload java, and then reload DirXML for the new values to take effect. If the problem still persists, increase the memory value
until the problematic driver can acquire the memory it needs.
Note: each DirXML driver running on a NetWare server runs within a separate JVM.