Native Drivers Cerified

The following table lists native drivers cerified to run on NAS 4.0, SP5.
 

Database Server	Database Client (Solaris 2.6, 2.7, 2.8)
Oracle 8.0.6	Oracle 8.0.6 client in compatibity mode using OCI 7.x  (SQL3 blobs and CLOB calls are not supported)
Sybase 11.9.2	Sybase Open/Client System 11.1.1
Informix 9.2 (+7.3)	Informix Client SDK 2.40
SQL Server 6.5	ODBC 3.51
DB2 6.1 (+5.2)	DB2 Client 6.1, 7.1

Support for Web Servers

Installation

• Windows NT: From the CD-ROM, go to the NT directory and run setup.exe
• Solaris: From the CD-ROM. go to the Solaris directory and run setup

Documentation

To locate these guides, use the following iPlanet web site:

        http://docs.iplanet.com/docs/manuals/nas.html

Adobe Acrobat 4.0 and PostScript printer with PS level 2 fonts are required to print the PDF version.

For pervious product documentation please visit the iPlanet web site above.

Programmer's Guide (Java)

• Bug Number 387995 - in section Understanding NAS Limitations on page 152, there's an omission of "Multiple result sets are not supported"

 
• Bug Number 401451 - not a bug, additional documentation -  do not use "forward" inside a JSP scriptlet because the compiled JSP's obtain the output

stream (a PrintWriter) in their "service" method.  According to the JSP and servlet specs, forwarding a request from a JSP or servlet is not allowed if the
output stream (PrinterWriter) has been obtained in the same request.

For example, the following JSP scriptlet generates an IllegalStateException because the JSP contained the scriptlet :
 <% RequestDispatcher dispatcher = getServletContext().getRequestDispatcher("/ResourceStream/Simple2.jsp");
 dispatcher.forward(request, response);
 %>

The compiled code for the "service" method is:

public void service (HttpServletRequest request,HttpServletResponse response)
  throws ServletException, IOException {
  PrintWriter out = response.getWriter ();
  BufferedReader in = request.getReader();
  Throwable exception = (Throwable)request.getAttribute("exceptionBean");
  out.write(_buf,0,143);
  // file: ResourceStream/Simple1.jsp line: 3
  RequestDispatcher dispatcher =  getServletContext().getRequestDispatcher("Simple2.jsp");
  dispatcher.forward(request, response);
  out.write(_buf,281,20);
  out.flush();
}

Tthe output stream is obtained in the line:
PrintWriter out = response.getWriter ();

This line is required for the current JSP to print its output to the browser and is also required by the JSP .092, 1.0 and 1.1 specs.

Also, the following code in a servlet method generates the same exception:
 PrintWriter out = res.getWriter();
 out.println(" Making a  Call to Second servlet ");
 RequestDispatcher dispatcher = getServletContext().getRequestDispatcher("/ResourceStream/Simple2.jsp");
 dispatcher.forward(req,res);
 out.println(" back in first servlet ");
 

Resolve the problem in one of two ways:

1)  Use "include" instead of "forward". This is actually widely recommended for the problem described above.

2)  Instead of placing the code (scriptlet) in the JSP, place it in a servlet method which does the forwarding.  In this case, avoid using "getOutputStream" or "getWriter" because again it generates the IllegalStateException.

Example:

public void defaultAction(HttpServletRequest req, HttpServletResponse res)
   throws ServletException, IOException
{
  res.setContentType("text/html");

 RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher("/ResourceStream/Simple2.jsp");
 dispatcher.forward(req,res);
}
 

• Bug Number 409623 - not a bug, works as designed -  Workaround, type ps -ef | grep jre on the KJS process to launch the JRE process, if type kill -3 on the JRE process the stack dumps. However, if you type kill -3 on the KJS pid even though the signal is being recieved by the KJS engine (truss -p <kjspid>) the stack does not dump. This is  because the KJS executable (./kjs) calls execvp and that launches JRE, so when SIGQUIT is sent to the KJS process, it does not propogate it to the JRE process.

 
• Bug Number 430909 - not a bug - create the authorization information as specified in section "Using Sample Applications" of the install guide or by using the ldapreg script in the sample directory and not by copying the .ldif files from iPlanet Application Server 6.0.

 
• Bug Number 479502 - not a bug - iPlanet does not set the default transaction isolation level. In fact, TRANSACTION_NONE is not a valid transaction isolation level for any

database. There are four valid transaction isolation levels, as follows:
• READ COMMITTED
• READ UNCOMMITTED
• REPEATABLE READ
• SERIALIZABLE
TRANSACTION_NONE is only defined in JDBC. TRANSACTION_NONE is not even a valid parameter for setTransactionIsolationLevel(). So,  getdefaulttransisolationlevel() returns READ_COMMITTED in case of local connection because this is the value returned by the driver.

Note that with all important global transactions, there can be different vendor databases each with a different default transaction isolation level. Therefore, this call has no meaning to global transactions and iPlanet has no choice but to return TRANSACTION_NONE. JDBC knows nothing about local and global connections. Also note, that whatever your database default txn isolation level is, that is the one the iPlanet Application Server uses for its JDBC connections unless you change it with an explicit call to setTransactionIsolationLevel(). This means the MSDTC-MSSQl server combination cannot handle the crucial execute query statment without an explicit READ_COMMITTED. ORACLE does not need this additional help.
 

• Bug Number 481681 - in section Creating Datasource Property Files on page 208 states "Fieldnames are not case-sensitive", this is not true, fieldnames are case-sensitive.

 
• Bug Number 488661 - Invalid, cannot reproduce - if transaction manager is installed with NAS. NAS  won't be able to throw transaction related exception so unless a transaction manager is installed.

Resolved Issues

Known Problems

Problems Exist Using com.netscape.server.jdbc.Statement.executeBatch() with the DB2 7.1 client

To avoid these problems, use com.netscape.server.jdbc.Statement.execute() with the DB2 7.1 client.

Admin Server Not Coming Up After Registering Servlet

Registration problems occurs when defining servlets in ntv file without some parameters. These optional fields are not really optional, and cause the NAS admin server to hang. To workaround this problem provide a complete definition of ntv file:

Samplentv{
      "Test" NTV {
              "ServletRegistryInfo" NTV {
                      "type" Str "j",
                      "enable" Str "y",
                      "encrypt" Str "n",
                      "lb" Str "y",

                      "descr" Str "Test servlet",

                      "group" StrArr [ "TestServlet" ],

                      "guid" Str "{91dfbcba-8b13-11d3-b9f5-00108334167f}",

                      "acl" StrArr [  ]

               },

              "ServletRunnerInfo" NTV {

                      "ServletClassPath" Str "TestServlet.Test"

               },

              "ServletData" NTV {

                      "defaultTemplate" Str "TestServlet/TestServletJSP.jsp"

               }