From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: nhosoi wrote: I'm looking into the dsmlgw acceptance test failure. It looks dsmlgw setup itself is failing although the acceptance test does not report it. This is the Admin Server error log (admin-serv/logs/error) On the client side: The dsmlgw acceptance startup script stops the Admin Server, calls dsml-activate.pl, then restart the server. When restarting, java exception is issued: [28/Mar/2005:20:11:07] info ( 5400): A new configuration was successfully installed [28/Mar/2005:20:11:08] info ( 5400): Using the Classic VM v1.4.2 from IBM Corporation [28/Mar/2005:20:11:08] info ( 5400): Java VM classpath: /export/servers/ds7/bin/https/jar/NSServletLayer.jar:/export/servers/ds7/bin/https/jar/NSJavaUtil.jar:/export/servers/ds7/bin/https/jar/NSJavaMiscUtil.jar:/export/servers/ds7/bin/https/jar/servlet.jar:/export/servers/ds7/bin/https/jar/servlet-2.3-filters-api.jar:/export/servers/ds7/bin/https/jar/jaxp.jar:/export/servers/ds7/bin/https/jar/crimson.jar:/export/servers/ds7/bin/https/jar/xalan.jar:/export/servers/ds7/bin/https/jar/jspengine.jar:/export/servers/ds7/bin/https/jar/jakarta-naming.jar:/export/servers/ds7/java/ldapjdk.jar:/export/servers/ds7/java/jss3.jar: [28/Mar/2005:20:11:08] info ( 5400): Loading IWSSessionManager by default. [28/Mar/2005:20:11:08] info ( 5400): IWSSessionManager: Maximum number of sessions is 1000 [28/Mar/2005:20:11:08] failure ( 5400): Internal error: Unexpected Java exception thrown (javax.xml.parsers.FactoryConfigurationError: Provider org.apache.crimson.jaxp.SAXParserFactoryImpl not found,Provider org.apache.crimson.jaxp.SAXParserFactoryImpl not found), stack: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.crimson.jaxp.SAXParserFactoryImpl not found at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at com.netscape.server.http.util.XmlConfig.parseConfig(XmlConfig.java:79) at com.netscape.server.http.servlet.VirtualServer.<init>(VirtualServer.java:81) at com.netscape.server.http.servlet.VirtualServer.createVirtualServer(VirtualServer.java:166) at com.netscape.server.http.servlet.NSServletRunner.VSInit(NSServletRunner.java:678) [28/Mar/2005:20:11:08] failure ( 5400): Internal Error: Failed to initialize web application environment (web-apps.xml) for virtual server (dsml-serv) [28/Mar/2005:20:11:08] info ( 5400): Successfully initialized web application environment (web-apps.xml) for virtual server (dsml-serv) After this, any SOAP request fails due to this error: [28/Mar/2005:20:11:30] warning ( 5400): for host kiki.sfbay.redhat.com trying to POST /axis/services/dsmlgw, send-file reports: can't find /axis/services/dsmlgw (File not found) But interestingly, org.apache.crimson.jaxp.SAXParserFactoryImpl is in crimson.jar, and crimson.jar is in the classpath. $ jar tvf /export/servers/ds7/bin/https/jar/crimson.jar | egrep SAXParserFactoryImpl 2102 Tue Feb 06 05:42:42 PST 2001 org/apache/crimson/jaxp/SAXParserFactoryImpl.class This is the corresponding request logged in the access log: cat logs/access format=%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] "%Req->reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length% kiki.sfbay.redhat.com - - [28/Mar/2005:20:11:45 -0800] "POST /axis/services/dsmlgw HTTP/1.0" 404 292 I'm quite puzzled at this exception. I have almost no idea other than trying Sun JRE (if it's easy to switch -- just copying the jre dir does not help...) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: run tet dsmlgw acceptance test Additional info:
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> 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