1.0 Introduction
2.0 Directory
Structure
3.0 Pre-Requisites
3.1 Container
3.2 Database
3.3 Registry
4.0 Invoking the
service
4.1 Retailer
4.2 Configurator
4.3 Catalog
5.0 Building from
the source
6.0 Configuring Logging
7.0
Troubleshooting
8.0 References
The Web Services Interoperability Organization (WS-I) [1] is committed to promoting interoperability among Web Services based on common, industry-accepted definitions and related XML standards. Towards this end, WS-I produces deliverables intended to assist developers in creating and deploying interoperable Web Services. WS-I Sample Application, one of the deliverables from WS-I, demonstrates the practical application of Web Services technologies to solve real business needs.
WS-I Sample Application is a sample Supply Chain Management application. Its use case design is defined in Supply Chain Management Use Case Model [2] and Use Cases for Attachments Sample Applications 1.0 [3] . Technical design and implementation details of this sample application are documented in Supply Chain Management Architecture document [4] and Technical Architecture for Attachments Sample Applications 1.0 [5]. The following illustration shows the various components of the Sample Application.
The application being modeled is that of a Retailer offering consumer electronic goods to Consumers; a typical B2C model. To fulfill orders, the Retailer has to manage stock levels in Warehouses (WarehouseA, WarehouseB, and WarehouseC). When an item in stock falls below a certain threshold, the Retailer must restock the item from the relevant Manufacturer's (ManufacturerA, ManufacturerB, and ManufacturerC) inventory; a typical B2B model. In order to fulfill a Retailer's request, a Manufacturer may have to execute a production run to build the finished goods. Each use case includes a logging call to a logging facility in order to monitor the activities of the services.
Retailer can also out-source the cataloging capabilities to a Catalog service that provides operations to access the catalog of products. The Catalog enables a consumer to browse it's contents and retrieve additional information about individual items. The consumer can then order the products from the Catalog which can then be packaged into an order and sent to a Retailer.
Retailer, Logging, WarehouseA, WarehouseB, WarehouseC, ManufacturerA, ManufacturerB, and ManufacturerC are published as Web Services by WS-I member companies participating in WS-I Sample Applications Working Group. Optionally, there is a Configurator Web Service that lists all of the implementations registered in the UDDI registry for each of the Web Services in the sample application.
The 1 Retailer, 1 Logging Facility, 3 Warehouses, 3 Manufacturers, and 1 Configurator Web Service are designed and implemented as part of WS-I Supply Chain Management Sample Applications 1.0 FCS. 1 Catalog Web Service is designed and implemented as part of WS-I Attachments Sample Applications 1.0. It demonstrates application of Basic Profile 1.1 [6], Simple SOAP Binding Profile 1.0 [7], and Attachments Profile 1.0 [8] to a real-life scenario.
This document explains the Sun's implementation of WS-I Sample Supply Chain Management Application 1.0 FCS and WS-I Attachments Sample Applications 1.0 EA3.
This section explains the directory structure of the wsi-sampleapp directory bundled with Java Web Services Developer Pack 1.5 (Java WSDP):
bin |
Scripts to invoke the retailer, configurator and catalog clients |
docs |
index.html, this file |
etc/config |
Configuration files required by the JAX-RPC tools |
etc/wsdl |
WSDL descriptions for the Web Services |
lib |
Client jar file |
src |
Source code |
wsi-server.war |
WAR file with all the Web Service endpoints |
logs |
Generated results and SOAP request and response message files |
Before any of the sample app Web Services can be invoked, you need to download the Java WSDP from java.sun.com/webservices/downloads/webservicespack.html and configure the web container and database of your choice as described below. Java WSDP supports three containers, which you can download from java.sun.com/webservices/containers.html.
This section explains how to set up your chosen web container.
Start the Application Server. If HTTP proxy host and port are
not configured during Sun Java System Application Server or Java WSDP
installation, configure the http.proxyHost
and http.proxyPort
properties for the container by
giving the following command:
asadmin create-jvm-options
--user <admin user> --password <admin password>
-Dhttp.proxyHost=<your-proxy-host>:-Dhttp.proxyPort=<your-proxy-port>
If the Application Server is not running on the standard host and
port (typically “localhost:8080”), then you need to
specify --host
and --port
options.
Alternatively, you can use the Admin Console and select JVM Settings, JVM Options to view and change these properties.
If HTTP proxy host and port are
not configured during Sun Java System Web Server or Java WSDP installation, configure the
http.proxyHost
and http.proxyPort
properties for the container. Using the Admin server GUI (usually
port 8888):
-Dhttp.proxyHost=<your-proxy-host>
in the first
empty text box next to "Add" and click on OK twice.
-Dhttp.proxyPort=<your-proxy-port>
in the first
empty text box next to "Add" and click on OK twice.
-Djava.awt.headless=true
in the first empty box next to "Add" and click on OK
twice. This will enable the headless operation for AWT images
involved in the Catalog Web Service.
http.proxyHost
and http.proxyPort
properties for the container
http.proxyHost=<your-proxy-host>
on a new line
to TOMCAT_HOME/conf/jwsdp.properties
.
http.proxyPort=<your-proxy-port>
on a
new line to TOMCAT_HOME/conf/jwsdp.properties
.
conf/server.xml
,
set the unpackWARs
attribute to true
in
the Engine
element within the Host
element
whose host attribute is localhost
.
TOMCAT_HOME/webapps
directory by the war
file name. To redeploy an app, the exploded directory needs to be
removed from TOMCAT_HOME/webapps
directory before
starting the Tomcat container.This section explains how to set up your chosen
database. The Pointbase database that comes bundled with Sun Java
System Application Server 8.1 2005 Q1 UR1 or later is recommended.
However, you may want to use the MySQL or Derby database for Sun Java System
Web Server 6.1 or Tomcat. The JWSDP_HOME/wsi-sampleapp/wsi-server.war
is configured to be used with the Pointbase database server. The
steps to reconfigure the WAR file for MySQL and Derby database are given in
section 3.2.2 and section 3.2.3 below.
AS_HOME/pointbase
directory, where
AS_HOME
is the installation directory of Sun Java
System Application Server 8.1 2005 Q1 UR1 (SJSAS 8.1 UR1) or later. This
version of pointbase can be used under the licensing terms of SJSAS 8.1 UR1.
To set up this version of Pointbase for
use with the WS-I sample application:
AS_HOME/pointbase/tools/serveroption
directory
and invoke the startserver.
[sh
| bat
]
script.
/port:9092
after
com.pointbase.net.netServer
.
AS_HOME/pointbase/tools/serveroption
directory
and invoke the startconsole.
[sh
| bat
]
script.
DBA
menu item from the main menu, select Create
and then select New Database
.
jdbc:pointbase:server://localhost/wsi
pbclient.jar
).
AS_HOME/pointbase/lib
to AS_HOME/domains/domain1/lib/ext
directory, if
domain1
is the chosen domain.
server.xml
for the instance chosen during Java WSDP installation. https-<your-server-name>/config
directory, where <your-server-name>
is the
name of your server on which Sun Java System Web Server 6.1 is
installed (or “localhost”).
classpathsuffix
attribute.
classpathsuffix
attribute.
TOMCAT_HOME/common/lib
.
JWSDP_HOME/wsi-sampleapp/src
directory and
invoke the change-database
target as followsant change-database
wsi-server.war
cd WS_HOME/bin/https/bin
wdeploy
delete -u /wsi-server -i localhost -v https-localhost hard
deploy.wsi-sampleapp.webapps
target on the integration
script for your
container.
JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.
[sh
| bat
] for Sun Java System Application ServerJWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.
[sh
| bat
] for Sun Java System Web ServerJWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.
[sh
| bat
] for TomcatFor instance, for Sun Java
System Application Server installed in /opt/SUNWappserver
directory, from the JWSDP_HOME/jwsdp-shared/bin/
directory this script is invoked as:
jwsdponsjsas.sh /opt/SUNWappserver deploy.wsi-sampleapp.webapps
If your container is the Web Server, then reconfigure the server to
load the deployed sample application
cd WS_HOME/https-localhost
reconfig
MySQL database may be used when Sun Java System Web Server 6.1 or Tomcat is the chosen container. MySQL can be downloaded from www.mysql.com/downloads. A standard MySQL installation using the binary distribution is recommended. To set up MySQL for use with the WS-I sample application:
MYSQL_HOME
directory and invoke the /bin/mysqld_safe
script,
where MYSQL_HOME
is the installation directory of
MySQL database. As per MySQL documentation, mysqld_safe
is the recommended way to start a mysqld
server on
Unix and NetWare. Refer to The
mysqld_safe Server Startup Script for more details. MYSQL_HOME
and
specifying the path as ./bin/mysqld_safe.
./bin/mysqladmin variables
command from
MYSQL_HOME
directory and looking for the value of
port
variable. Otherwise you can change the port
number by invoking the script as ./bin/mysqld_safe
--port=3306
MYSQL_HOME/bin
directory and invoke the command mysqld
--console
.
Refer to Installing
MYSQL on Windows for more details.
mysqladmin variables
command from
MYSQL_HOME/bin
directory and looking for the value of
port
variable. Otherwise you can change the port
number by specifying port=3306
on a new line in
%WINDIR%/my.ini
.
MYSQL_HOME
directory and invoke the ./bin/mysql
script.
MYSQL_HOME
and specifying a user name with
database creation privilege as ./bin/mysql --user=root
.
root is a default user with database creation privilege, you may choose an alternate user
with similar privilege. If you happen to choose an alternate user, you need to
modify JWSDP_HOME/wsi-sampleapp/etc/mysql.db.props
file with the correct values for user
and password
fields. This gives a mysql
prompt.
mysql
prompt, enter create database wsi;
command and hit Enter
quit;
on the mysql
prompt to quit the script
MYSQL_HOME/bin
directory and invoke mysql
script specifying a user name with
database creation privilege as ./bin/mysql --user=root
.
root is a default user with database creation privilege, you may choose an alternate user
with similar privilege. If you happen to choose an alternate user, you need to
modify JWSDP_HOME/wsi-sampleapp/etc/mysql.db.props
file with the correct values for user
and password
fields. This gives a mysql
prompt.
mysql
prompt, enter create database wsi;
command and hit Enter
quit;
on the mysql
prompt to quit the
script
AS_HOME/domains/domain1/lib/ext
directory, if
domain1
is the chosen domain.
server.xml
for the instance chosen during Java WSDP installation. Typically
this file will be in https-<your-server-name>/config
directory where <your-server-name>
is the name
of your server on which Sun Java System Web Server 6.1 is
installed (or “localhost”).
classpathsuffix
attribute.
classpathsuffix
attribute.
TOMCAT_HOME/common/lib
.
JWSDP_HOME/wsi-sampleapp/src
directory and invoke the change-database
target as followsant change-database -Ddatabase=mysql
wsi-server.war
.
For example:cd WS_HOME/bin/https/bin
wdeploy
delete -u /wsi-server -i localhost -v https-localhost hard
deploy.wsi-sampleapp.webapps
target on the integration
script for your
container.
JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.
[sh
| bat
] for Sun Java System Application ServerJWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.
[sh
| bat
] for Sun Java System Web ServerJWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.
[sh
| bat
] for TomcatFor instance, for Sun Java
System Web Server installed in /opt/SUNWwebserver
directory, from the JWSDP_HOME/jwsdp-shared/bin/
directory this script is invoked as:
jwsdponsjsws.sh /opt/SUNWwebserver deploy.wsi-sampleapp.webapps
If your container is the Web Server, then reconfigure the server to
load the deployed sample application
cd WS_HOME/https-localhost
reconfig
Derby database may be used when Sun Java System Web Server 6.1 or Tomcat is the chosen container. Derby can be downloaded from incubator.apache.org/derby/derby_downloads.html. A Derby installation using the binary distribution is recommended (this is typically the first link on the download page and named as incubating-derby-version#-bin.tar.gz). To set up Derby for use with the WS-I sample application:
DERBY_HOME
directory and invoke the command:java -classpath "lib/derbynet.jar:lib/derby.jar"
org.apache.derby.drda.NetworkServerControl start
java -classpath "lib/derbynet.jar;lib/derby.jar"
org.apache.derby.drda.NetworkServerControl start
on Windows platform where DERBY_HOME
is
the installation directory of Derby database.
-port
1527
after start
.
DERBY_HOME/lib
directory.
AS_HOME/domains/domain1/lib/ext
directory, if domain1
is the chosen domain.
server.xml
for the instance chosen during
Java WSDP installation. Typically this file will be in https-<your-server-name>/config
directory where <your-server-name>
is the name of
your server on which Sun Java System Web Server 6.1 is installed (or
“localhost”).
classpathsuffix
attribute.
classpathsuffix
attribute.
TOMCAT_HOME/common/lib
.
DERBY_HOME
directory and invoke the command:
java -classpath "lib/derbynet.jar:lib/derby.jar:lib/db2jcc.jar:lib/db2jcc_license_c.jar"
-Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.protocol=jdbc:db2://localhost:1527/
-Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij
java -classpath "lib/derbynet.jar;lib/derby.jar;lib/db2jcc.jar;lib/db2jcc_license_c.jar"
-Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.protocol=jdbc:db2://localhost:1527/
-Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij
DERBY_HOME
and
specifying a user name with database creation privilege. APP is a
default user with database creation privilege, you may choose an
alternate user with similar privilege. If you happen to choose an
alternate user, you need to modify JWSDP_HOME/wsi-sampleapp/etc/derby.db.props
file with the correct values for user
and password
fields. This gives a ij
prompt.
ij
prompt, enter connect 'wsi;create=true';
command and hit Enter
quit;
on the ij
prompt to quit the
script
JWSDP_HOME/wsi-sampleapp/src
directory and
invoke the change-database
target as followsant change-database -Ddatabase=derby
wsi-server.war
.
For example:cd WS_HOME/bin/https/bin
wdeploy delete -u /wsi-server -i localhost -v https-localhost hard
deploy.wsi-sampleapp.webapps
target on the
integration script for your container.
JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.
[sh
| bat
] for Sun Java System Application ServerJWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.
[sh
| bat
] for Sun Java System Web ServerJWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.
[sh
| bat
] for TomcatFor instance, for Sun Java System Web Server installed in /opt/SUNWwebserver
directory, from the JWSDP_HOME/jwsdp-shared/bin/
directory
this script is invoked as:
jwsdponsjsws.sh /opt/SUNWwebserver deploy.wsi-sampleapp.webapps
If your container is the Web Server, then reconfigure the server to load
the deployed sample application
cd WS_HOME/https-localhost
reconfig
JWSDP_HOME/wsi-sampleapp/src
directory and
invoke the change-registry
target as followsant change-registry -Dregistry.server=microsoft
If the WS-I sample application has
been configured for the Microsoft registry earlier and now needs to be
configured with the IBM registry, you need to invoke the change-registry
target as followsant change-registry -Dregistry.server=ibm
wsi-server.war
.
For example:cd WS_HOME/bin/https/bin
wdeploy
delete -u /wsi-server -i localhost -v https-localhost hard
deploy.wsi-sampleapp.webapps
target on the integration
script for your
container.
JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.
[sh
| bat
] for Sun Java System Application ServerJWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.
[sh
| bat
] for Sun Java System Web ServerJWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.
[sh
| bat
] for TomcatFor instance, for Sun Java
System Web Server installed in /opt/SUNWwebserver
directory, from the JWSDP_HOME/jwsdp-shared/bin/
directory this script is invoked as:
jwsdponsjsws.sh /opt/SUNWwebserver deploy.wsi-sampleapp.webapps
If your container is the Web Server, then reconfigure the server to
load the deployed sample application
cd WS_HOME/https-localhost
reconfig
Make sure that the container and the database server configured above are running before invoking any of the services. The chosen database server will be running if you have performed Step 1 in section 3.2.1 or 3.2.2.
The Retailer client acts as a consumer of the electronics good and
places pre-defined orders (defined in etc/retailer-config.xml
)
to the Retailer Web Service. The Retailer Web Service then invokes
the warehouse and manufacturer Web Services to fulfill the supply
chain model defined in section 1.0 above. The orders are defined such
that the various combinations of retailer, warehouse and manufacturer
are invoked. The set of endpoints is defined in etc/endpoints.props
and the combination of endpoints is defined in etc/vendor-config.xml
.
To invoke the Retailer client:
JWSDP_HOME
/wsi-sampleapp
directory.
etc/endpoints.props
has the correct host and port information (by default
localhost:8080).
JWSDP_HOME/wsi-sampleapp/bin/run-retailer.
[sh
| bat
] to invoke the client. This invokes the
getCatalog
function from the RetailerService and places
the various pre-defined orders to the Retailer Web Service.
You can view the log entries documenting this activity in
JWSDP_HOME/wsi-sampleapp/logs/retailer-results.html
. You'll
notice some orders are not satisfied due to insufficient stock; this
is intentional.
The Configurator client queries a public UDDI Business Registry for the WS-I sample application endpoints implemented by all the vendors which have a peer-to-peer relationship with WS-I business entity and displays them. The WS-I sample application has been configured to use the IBM's public UDDI Business Registry for querying this list of endpoints. Refer to section 3.3 if you want to use Microsoft's public UDDI Business Registry instead.
To invoke the Configurator (query) client:
http.proxyHost
and http.proxyPort
properties for your container so it can talk to a UDDI Business
Registry outside the firewall. Refer to section 3.1
for container specific configuration.
JWSDP_HOME/wsi-sampleapp/bin/run-query.
[sh
| bat
].
JWSDP_HOME/wsi-sampleapp/logs/query-results.html
. You should see
entries for vendors such as BEA, Corillian, IBM, Microsoft, Novell,
Oracle, Quovadx, SAP, and Sun.
The default behavior
of run-query.
[sh
| bat
] is to
contact the IBM's public UDDI business registry
and generate the endpoints information dynamically. However the
Configurator Web Service also maintains all endpoints information in
a local cache accessible by specifying the following argument when
invoking the script
-Dconfigurator.refresh=false
Specifying this option will not invoke the public UDDI business registry and instead provides you with endpoints information from the local cache. This cache is also updated every time the UDDI registry is contacted for the list of endpoints.
The run-query.
[sh
|
bat
] script uses the default Configurator Web Service
bundled with Java WSDP. If you need to use another Configurator Web
Service, configure server-side logging to at least the
CONFIG logging level and run the query script with
configurator.refresh=true
, which
is the default when you invoke
the run-query.
[sh
| bat
]
script without any arguments. Search server-side logs (server.log
on
Sun Java System Application Server, errors
log on Sun Java System
Web Server, launcher.server.log
on Tomcat) for CONFIG
entries containing the text " Configurator" and you should
see the endpoint address displayed between curly braces. For example:
Oracle
WS-I Configurator {http://ws-i.oracle.com/ws-i/supplychain/services/Configurator}
Add the text between curly
braces in etc/endpoints.props
in the following format.
vendor
.configurator=http://ws-i.oracle.com/ws-i/supplychain/services/Configurator
where vendor
is
the name of the vendor and the text between curly braces is copied after the =
symbol. To use this Configurator Web Service, invoke the run-query.
[sh
| bat
]
with the following argument
-Dconfigurator.endpoint=<vendor>
where <vendor>
is replaced by the value of vendor
specified in the etc/endpoints.props
.
Refer to section
6.0 for details on how to configure logging.
If both
-Dconfigurator.endpoint
and -Dconfigurator.refresh
options are specified, then endpoints information is retrieved in the
following manner:
configurator.refresh |
configurator.endpoint |
How endpoints are generated |
true |
Not specified |
Configurator Web Service talks to the UDDI registry |
false |
Not specified |
Local cache from the Configurator Web Service |
true |
Specified |
Remote endpoint talks to the UDDI registry |
false |
Specified |
Local cache from the remote endpoint |
The Catalog client queries the Catalog Web Service which simulates
an out-sourced cataloging capability that is used by the Retailer Web
Service. It provides operations to access the catalog of products.
The Catalog enables a consumer to browse its contents and retrieve
additional information about individual items. In a larger context,
the products that the consumer orders from the Catalog can be
packaged into an order and sent to a Retailer. The set of Catalog
endpoints are defined in etc/endpoints.props
.
To invoke the Catalog client:
etc/endpoints.props
has the correct host and port information (typically
localhost:8080).
JWSDP_HOME/wsi-sampleapp/bin/run-catalog.
[sh
| bat
]. getCatalogWithImages
and getProductDetails
function from the Catalog Web
Service. getCatalogWithImages
return attachment
references of thumbnail images for each product in the catalog.
getProductDetails
provides additional details about
each product, a larger product image, and a product spec sheet. The
spec sheet and picture are conveyed as SOAP attachments.
The default behavior
of run-catalog.
[sh
| bat
] is
to invoke getCatalogWithImages
and getProductDetails
for each product in the Catalog. If you need to invoke only
getCatalogWithImages
, specify the following argument
when invoking the script
-Dcatalog.level=thumbnail
If you need to
invoke only getProductDetails
, specify the following
argument when invoking the script
-Dcatalog.level=details
run-catalog.
[sh
| bat
] uses
the default Catalog Web Service bundled with Java WSDP. To use another
Catalog Web Service, add the endpoint in etc/endpoints.props
in the form
vendor.catalog=ENDPOINT_ADDRESS
where ENDPOINT_ADDRESS specifies the location of the new Catalog Web Service and "vendor" can be replaced by the name of the Web Service provider. Then the new Catalog Web Service can be used by specifying the following argument when invoking the script
-Dcatalog.endpoint=vendor
where vendor
needs to match the "vendor"
string specified in JWSDP_HOME/wsi-sampleapp/etc/endpoints.props
.
If HTTP proxy host and port are not configured during Java WSDP installation, configure the http.proxyHost
and
http.proxyPort
properties in
JWSDP_HOME/conf/jwsdp.properties
before building from
the source. You should use the ant bundled with Java WSDP because it has the
required libraries in the classpath.
src
directory
and invoke ant client
command. This will overwrite
the existing wsi-client.jar
in
JWSDP_HOME/wsi-sampleapp/lib
directory.
src
directory
and invoke ant server
command. wsi-server.war
in
JWSDP_HOME/wsi-sampleapp
directory. -Ddatabase=mysql
property when
invoking the ant target.
wsi-server.war
.
For example:
cd WS_HOME/bin/https/bin
wdeploy
delete -u /wsi-server -i localhost -v https-localhost hard
deploy.wsi-sampleapp.webapps
target on the integration
script for your container.
JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.
[sh
| bat
] for Sun Java System Application ServerJWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.
[sh
| bat
] for Sun Java System Web ServerJWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.
[sh
| bat
] for TomcatFor instance, for Tomcat for Java WSDP installed in /opt/tomcat-jwsdp
directory, from the JWSDP_HOME/jwsdp-shared/bin/
directory, this
script is invoked as:
jwsdpontomcat.sh /opt/tomcat-jwsdp
deploy.wsi-sampleapp.webapps
If your container is the Web Server, then reconfigure the server to
load the deployed sample application
cd WS_HOME/https-localhost
reconfig
The Java WSDP supports the Java Logging API [9]. By default, the WS-I sample application in the Java WSDP has its logging level set to "INFO". The following levels are available, in ascending order of granularity and are used in the application as shown below.
Logging Level |
Usage |
SEVERE |
Server-side or client-side exception |
WARNING |
Non-blocking error conditions |
INFO (default) |
Basic flow of application |
CONFIG |
Logging entries from the LoggingFacility |
FINE |
SOAP request and response messages |
FINER |
Entry and exit points of primary methods |
FINEST |
Display intermediate steps from the primary methods, if any |
To change the default logging level (INFO) on server-side and client-side to a different level:
JAVA_HOME/jre/lib/logging.properties
file.
com.sun.wsi.scm.level=LEVEL
LEVEL
is one of the seven logging levels mentioned
above.
ConsoleHandler
to the new level
as.level=LEVEL
java.util.logging.ConsoleHandler.level=LEVEL
logging.properties
file.
https-localhost/config/server.xml
. level
attribute of LOG
element to FINE
, FINER
or FINEST
to see more detailed log entries on the server side.etc/endpoints.props
file. The default
endpoints are configured for host "localhost" and port
"8080". If your application is deployed at a different
host and/or port, then ensure that these are reflected correctly in
the etc/endpoints.props
file.
run-retailer
script is invoked. If the
database is started or created after the script is invoked, you need to restart
the container.
JWSDP_HOME/wsi-sampleapp/etc/
[mysql
| pointbase
].props
. If you need to modify
any of the database configuration properties, edit the .props file
specific to your database and invoke ant change-database -Ddatabase=
[pointbase
| mysql
]
target from the JWSDP_HOME/wsi-sampleapp/src
directory. And then invoke the deploy.wsi-sampleapp.webapps
target on the integration script for your container. wsi-server.war
first using the
command:
wdeploy delete -u /wsi-server -i localhost -v https-localhost
cd WS_HOME/https-localhost
reconfig
http.proxyHost
and http.proxyPort
properties in
JWSDP_HOME/conf/jwsdp.properties
to specify the
system on your network through which you access the Internet.
etc/endpoints.props
file and create different configurations, comprising of endpoints
from different vendors, in etc/vendor-config.xml
. Each
of these configurations will be used to place the orders specified
in etc/retailer-config.xml
. However if your endpoints
are deployed inside a firewall, then only Retailer Web Service
hosted within the firewall can be mixed with the other endpoints
installed outside the firewall.
logs/retailer-soap-messages.txt.
logs/logging-soap-messages.txt
. This log is created
when you run the run-retailer.
[sh
| bat
] script.
logs/configurator-soap-messages.txt
.
logs/catalog-soap-messages.txt
.
These messages can be viewed in a text
editor such as vi
on Unix or Wordpad on Windows. They
contain base-64 encoding which cannot be handled by some text
processing tools. Server-side log messages are available
in the corresponding logs directory of your container.
If your container is Tomcat, you invoked run-query
script
and a java.lang.NullPointerException
with the stack trace as
given below is received on the client side:
java.util.logging.ErrorManager: 5
java.lang.NullPointerException
at java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:103)
Then it's likely that unpackWARs
attribute is not set
correctly in the Tomcat configuration files. Refer to section
3.1.3 to set the attribute correctly.