Problems with UDDI
If you have already contacted support, continue to the component's
specific MustGather information. Otherwise, click MustGather:
Read first for all WebSphere Application Server products.
UDDI, UDDI4J, and UDDI-WSDL specific MustGather information
- Description of your problem, including any errors
- Description of the steps taken to reproduce your problem, if it can be
recreated
- Client and server platforms and software, and the levels you are using
(See Section A.)
- Version of the Web services component you are using (See Section
B.)
- List of all fixes you have applied
- The national language of your target system
- Your Xerces level (See Section D.)
- If possible, supply the source code that shows the error.
- If you have UDDI problems, provide the following
additional information
- Which database and version are you using? (for example: DB2®
V7.2)
- Is your component running in a deployment manager cell or a
stand-alone application server? Describe your environment in terms of the
number of application servers and so forth.
- If you are using a user console, what is the version of your internet
browser? (See Section C.)
- Provide any relevant log files and trace files. (See Section
E.)
- If you have UDDI4J problems, provide the following
additional information
- Your Simple Object Access Protocol (SOAP) level (See Section
D.)
- The transport you are using (Apache SOAP or AXIS)
- A TCP trace (See Section G.)
- If you are having UDDI4J-WSDL problems, provide the
following additional information
- Your Simple Object Access Protocol (SOAP) level (See Section
D)
- The transport you are using (Apache SOAP or AXIS)
- A TCP trace (See Section G.)
- The qname.jar file you are using (See Section D.)
- The Web Services Definition Language (WSDL) files that you are
using
- The URLs of the UDDI publish and inquiry APIs (See Section
F.)
Sections
- Give details as appropriate, for the following:
- The client operating system and version
- The server operating system and version
- The WebSphere Application Server version and level
- You can identify the version of the Web services component as follows:
- For UDDI
The version is indicated in a file called version.txt, which
is located in the uddi.ear file (part of the download package).
Your version.txt is a top-level file within the uddi.ear
archive. The format of the information in version.txt is shown in
the following example:
UDDI Version File 2.0.3
Built at : "Sat 02/11/2002 8:55
UDDITP WAS5"
Where:
- 2.0.3 is the build version, release and revision level
- Sat 02/11/2002 8:55 is the date and time when this
particular build was carried out
- UDDITP is the machine on which the build was
carried out
- WAS5 is an indication of the ship vehicle for
which the build was originally created.
- For UDDI4J
- Version information currently available
Initially, uddi4j V1 was shipped with WebSphere Application
Server, and uddi4j V2 was launched publicly. Subsequently,
uddi4j V2 was shipped with WebSphere Application Server V5, along
with a uddi4j V1, which deprecated backwards compatibility.
Uddi4j V1 was shipped as uddi4j.jar and uddi4j
V2 shipped as uddi4jv2.jar. Neither version in WebSphere
Application Server V5 carries internal version information.
- Future releases
Updates have been made to the latest public release of uddi4j V2
(release 2.0.1) to contain an internal BuildDate.txt to identify
the date of the build. This public release, and all future public releases
will carry this file. Version identification is performed by associating
the build dates with releases. The only current public release marked in
this manner is the latest one, V2.0.1, with a date of 30 Jan 2003. Future
uddi4j releases with WebSphere Application Server will carry
similar BuildDate.txt files, identifying the build date, and
carrying an additional line marking them as WebSphere Application Server
releases. If a rebuild of the shipped V1 is required, similar information
will be added there. Currently there is only one .jar file with the name
uddi4jv2.jar, containing uddi4j V2, and that is the one
shipped with WebSphere Application Server.
- Uddi4j public releases
There are many uddi4j public releases, all named
uddi4j.jar, with content of either V1 or V2, carrying no version
information. There is the possibility for builds other than those
available from the uddi4j public Web site to exist, also named
uddi4j.jar with unknown modifications, because of the open source
nature of the project.
To identify the version of UDDI4J where an actual version file is
available, specify the size of the JAR file.
- For UDDI4J-WSDL
The uddi4j-wsdl.jar file contains a file called
UDDI4JWSDL_version.txt, which contains the following:
UDDI4J-WSDL Version File 2.1.0
Built at : "Tue 15/10/2002
12:49 UDDITP"
Where:
- 2.1.0 is the build version, release and revision
level
- Tue 15/10/2002 12:49 is the date and time
when this particular build was carried out
- UDDITP is the machine on which the build was
carried out
- The version of your browser can be obtained from information provided
in About the Browser. For example, select Tools > About
Internet Explorer.
- In the $WAS_HOME/lib directory, find the
following JAR files and specify their size and the modified dates of the
classes within them:
- Soap.jar
- Xerces.jar
- Qname.jar
- Any relevant log files and trace files.
Note: Use of any links specified is dependent on the availability
of the Web site.
- If the problem occurred while setting up and installing
the UDDI Registry application using one of the setup scripts
(setupuddi.jacl or appserversetupuddi.jacl), supply the
log output from running the script.
If you did not choose to redirect the output from the script file to a log
file, rerun the script, this time redirecting the output as described in
the section "Installing
and setting up a UDDI Registry". The log file is in the directory from
which you ran the setup script.
- If the problem occurred while removing the UDDI Registry
application using one of the remove scripts (removeuddi.jacl or
appserverremoveuddi.jacl), please supply the log output from
running the script.
If you did not choose to redirect the output from the script file to a log
file, rerun the script, this time redirecting the output as described in
the section "Removing
the UDDI Registry from a deployment manager cell' or 'Removing
the UDDI Registry application from a single appserver". The log file
is in the directory from which you ran the remove script.
- If the problem occurred while creating the UDDI Registry
database using the UDDI DB2 Setup Wizard, supply the log file
UDDIloadDB.log, which is in the directory from which the wizard
was run.
- If the problem occurred while running the UDDI Registry,
enable UDDI tracing (if not already enabled), and supply the trace log
from the logs directory of the Application Server on which the UDDI
Registry was running. Please refer to the section on "Turning
on UDDI Trace" for details on how to enable UDDI tracing.
- An example of the URL used is:
('http://mycompany.com/uddisoap/inquiryap')
- Provision of a TCP trace. A snapshot of the HTTP and SOAP request and
reply is very valuable. Use any tracer, such as a TCP monitor. One is in
the soap.jar called TcpTunnel; another, packaged with
Axis, is called TCPmon. The SOAP and AXIS User's Guides provide
instructions for using TcpTunnel and TCPmon
respectively.
Follow instructions to send
diagnostic information to IBM support.
For a listing of all technotes, downloads, and educational materials
specific to the Web services component, search the WebSphere
Application Server support site.
|