rcritten wrote:
The IBM JRE 1.4.2 includes a copy of the xmlparsers, as has been pointed out. My
guess is that it contains a different version than you are expecting. I ran into
this with NES as well though I got different sorts of errors.

I seem to recall kludging the classpath to load a particular version but it was
very ugly. You may want to play around with that a bit to see if you can get it
working at all, then go from there. I think my trick was to put my own
xerces.jar (for you I guess it's crimson) first in the bootloader class path.

rob 

Based upon Rob's suggestion, added crimson.jar and ibmpkcs.jar (for
BASE64Decoder) to the classpath on Linux where IBM JRE is used.

Index: template-dsml-activate.pl
===================================================================
RCS file:
/hurricane/cvs/spd/ldapserver/ldap/admin/src/scripts/template-dsml-activate.pl,v
retrieving revision 1.4
diff -t -w -U4 -r1.4 template-dsml-activate.pl
--- template-dsml-activate.pl   25 Mar 2005 02:09:14 -0000      1.4
+++ template-dsml-activate.pl   30 Mar 2005 21:30:27 -0000
@@ -192,8 +192,32 @@
 
             }
 
             if ( $file eq "jvm12.conf" ) {
+                if ($^O eq "linux") {
+                    # if setting Xbootclasspath, make sure crimson.jar is in it.
+                    $fulljvm12 = "${SERVERROOT}${PATH}${file}";
+                    $fulljvm12tmp = $fulljvm12 . ".tmp";
+                    $crimsonpath = "${SERVERROOT}/bin/https/jar/crimson.jar";
+                    $ibmpath = "${SERVERROOT}/bin/base/jre/lib/ibmpkcs.jar";
+                    open JVM, "${fulljvm12}";
+                    open JVMTMP, "> ${fulljvm12tmp}";
+                    for ($line=<JVM>; $line; $line=<JVM>) {
+                        if ($line =~ /Xbootclasspath/) {
+                            if (!($line =~ /${crimsonpath}/)) {
+                                $line =~
s/Xbootclasspath/Xbootclasspath:${crimsonpath}/;
+                            }
+                            if (!($line =~ /${ibmpath}/)) {
+                                $line =~
s/Xbootclasspath/Xbootclasspath:${ibmpath}/;
+                            }
+                        }
+                        print JVMTMP $line;
+                    }
+                    close JVMTMP;
+                    close JVM;
+                    unlink("${fulljvm12}");
+                    rename("${fulljvm12tmp}", "${fulljvm12}");
+                }
                 open JVM, ">>  ${SERVERROOT}${PATH}${file}";
                 select JVM;
                 print STDERR "adding necessary entry to $file.\n";
                 print
"jvm.option=-Duser.home=${SERVERROOT}{{SEP}}clients{{SEP}}dsmlgw";

After previous change, the same "Server Error" problem is returned across the
platforms.  It seems it was introduced when axis was upgraded from 1.2beta to
1.2rc3.

nhosoi wrote:
The dsmlgw test fails with the latest axis (1.2rc3).  It works fine with
1.2beta.  I switched the jar files in clients/dsmlgw/WEB-INF/lib to the ones
from 1.2beta, then I got 100% success (at least on the first search :)

Test Name 	PASS 	FAIL 	NORESULT
dsmlgw startup 	100% (1/1) 	  	 
dsmlgw run 	100% (1/1) 	  	 
dsmlgw cleanup 	100% (1/1) 	  	 

Subject: DS7.1 Linux-3 Acceptance test report - 100% passed on kiki.redhat.com
using 
Test framework tag: none
Report location :
/home/nhosoi/work/tet/tetframework/testcases/DS/6.0/results/kiki.redhat.com/Linux/20050330-130903.html

I learned from Rob how to get more detailed logs on the Admin Server.  Only a
visible difference is the red colored line; both lines say the path doesn't
exist.  So, non-existing path should not matter.  But obviously, some internal
settings have been modified in 1.2rc3...
With AXIS 1.2beta
[30/Mar/2005:13:09:24] info ( 7148): Successfully initialized web application
environment (web-apps.xml) for virtual server (dsml-serv)
[30/Mar/2005:13:09:43] info ( 7148): WebApp service: uri = /axis/services/dsmlgw
contextPath = /axis servletPath = /services/ pathInfo = /dsmlgw servletName =
AxisServlet
[30/Mar/2005:13:09:43] info ( 7148): vs(dsml-serv)servlet 'AxisServlet' class =
'org.apache.axis.transport.http.AxisServlet' loaded in context = '/axis'
[30/Mar/2005:13:09:43] info ( 7148): AxisServlet: init
[30/Mar/2005:13:09:45] info ( 7148): getRealPath: the path
/export/servers/ds7/clients/dsmlgw/services/ doesn't exist.

With AXIS 1.2rc3
[30/Mar/2005:12:25:44] info ( 4319): Successfully initialized web application
environment (web-apps.xml) for virtual server (dsml-serv)
[30/Mar/2005:12:26:04] info ( 4319): WebApp service: uri = /axis/services/dsmlgw
contextPath = /axis servletPath = /services/ pathInfo = /dsmlgw servletName =
AxisServlet
[30/Mar/2005:12:26:04] info ( 4319): vs(dsml-serv)servlet 'AxisServlet' class =
'org.apache.axis.transport.http.AxisServlet' loaded in context = '/axis'
[30/Mar/2005:12:26:04] info ( 4319): AxisServlet: init
[30/Mar/2005:12:26:06] info ( 4319): getRealPath: the path
/export/servers/ds7/clients/dsmlgw/services//dsmlgw doesn't exist.

The 1.2rc3 change log reads these have been changed since 1.2beta.
Axis Change Log
Changes from 1.2beta2

    * When generating WSDL, don't change the scoping rules for type mappings. In
other words, use the most specific mappings just like we do for message processing.
    * Fix problem with version string
    * Remove JAXP interfaces (should come from jaxp.jar, not jaxrpc.jar)

David Boreham <dboreham@redhat.com> wrote:
============================================================
So, the problem is that Axis changed the interface
for message handlers (which is what the DSMLGW is).
Previously their implementation was compatible with the
JAX-RPC spec, and now it isn't. This isn't too
surprising because when we wrote the DSMLGW
we got the impression that the JAX-RPC interface definitions
had been written before anyone had actually written
any code that used them.

So, the upshot is that in order to work correctly,
the dsmlgw now has to use the Axis-specific
interfaces (which work and make sense) rather than
the generic JAX-RPC interfaces (which don't work
and don't make much sense). The fix is going into our tree
for testing in the next TET cycle here (a few hours).

The only problem with this fix is that now the DSMLGW
code _depends_ on Axis. Previously (in theory) you could
take the DSMLGW jar file and integrate it with some other
JAX-RPC implementation (e.g. Systinet).

I don't see this as a big problem, especially as it's
a choice between something that works and something
that doesn't.

Let me know any questions/complaints.

Thanks.

Created attachment 112606 [details]
Proposed fix by David Boreham

DSML gw tests are now passing on all platforms

Verified in recent builds (on or before 20050516.1)

Bug already CLOSED. setting screened+ flag