Bug 152645 - dsmlgw acceptance test started to fail on 3/15/2005
dsmlgw acceptance test started to fail on 3/15/2005
Product: Red Hat Directory Server
Classification: Red Hat
Component: DSMLGW (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Noriko Hosoi
Orla Hegarty
Depends On:
Blocks: 146020
  Show dependency treegraph
Reported: 2005-03-30 17:28 EST by Noriko Hosoi
Modified: 2008-08-11 19:17 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-16 18:22:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed fix by David Boreham (10.52 KB, patch)
2005-04-01 18:44 EST, Noriko Hosoi
no flags Details | Diff

  None (edit)
Description Noriko Hosoi 2005-03-30 17:28:21 EST
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:

Steps to Reproduce:
run tet dsmlgw acceptance test

Additional info:
Comment 1 Noriko Hosoi 2005-03-30 17:30:25 EST
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.

Comment 2 Noriko Hosoi 2005-03-30 17:32:27 EST
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:
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 =~
+                            }
+                            if (!($line =~ /${ibmpath}/)) {
+                                $line =~
+                            }
+                        }
+                        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";
Comment 3 Noriko Hosoi 2005-03-30 17:35:54 EST
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

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 :)

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
Test framework tag: none
Report location :

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 =
[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 =
[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)
Comment 4 Noriko Hosoi 2005-04-01 18:42:32 EST
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.


Comment 5 Noriko Hosoi 2005-04-01 18:44:28 EST
Created attachment 112606 [details]
Proposed fix by David Boreham
Comment 6 David Boreham 2005-04-18 13:48:47 EDT
DSML gw tests are now passing on all platforms
Comment 7 To Ngan 2005-05-16 18:22:44 EDT
Verified in recent builds (on or before 20050516.1)
Comment 8 Chandrasekar Kannan 2008-08-11 19:17:38 EDT
Bug already CLOSED. setting screened+ flag

Note You need to log in before you can comment on or make changes to this bug.