Apache | Web Services | Axis |
Axis Developer's Guide
1.2 Version
Table of Contents
IntroductionThis guide is a collection of topics related to developing code for Axis. General Guidelines
Development EnvironmentThe following packages are required for axis development:
The Axis jar files are built in the xml-axis/java/build/lib directory. Here is an example CLASSPATH, which I use when developing code: G:\xerces\xerces-1_4_2\xerces.jar G:\junit3.7\junit.jar G:\xml-axis\java\build\lib\commons-discovery.jar G:\xml-axis\java\build\lib\commons-logging.jar G:\xml-axis\java\build\lib\wsdl4j.jar G:\xml-axis\java\build\lib\axis.jar G:\xml-axis\java\build\lib\log4j-1.2.8.jar G:\xml-axis\java\build\classes If you access the internet via a proxy server, you'll need to set an environment variable so that the Axis tests do the same. Set ANT_OPTS to, for example: -Dhttp.proxyHost=proxy.somewhere.com -Dhttp.proxyPort=80 -Dhttp.nonProxyHosts="localhost" Pluggable-ComponentsThe Axis Architecture Guide explains the requirements for pluggable components. DiscoveryAn Axis-specific component factory should be created of the form: org.apache.axis.components.<componentType>.<factoryClassName> For example, org.apache.axis.components.logger.LogFactory is the factory, or discovery mechanism, for the logger component/service. The org.apache.axis.components.image package demonstrates both a factory, and supporting classes for different image tools used by Axis. This is representative of a pluggable component that uses external tooling, isolating it behind a 'thin' wrapper to Axis that provides only a limited interface to meet Axis minimal requirements. This allows future designers and implementors to gain an explicit understanding of the Axis's specific requirements on these tools. Logging/TracingAxis logging and tracing is based on the Logging component of the Jakarta Commons project, or the Jakarta Commons Logging (JCL) SPI. The JCL provides a Log interface with thin-wrapper implementations for other logging tools, including Log4J, Avalon LogKit, and JDK 1.4. The interface maps closely to Log4J and LogKit. Using the Logger SPITo use the JCL SPI from a Java class, include the following import statements: import org.apache.commons.logging.Log; import org.apache.axis.components.logger.LogFactory; For each class definition, declare and initialize a log attribute as follows: public class CLASS { private static Log log = LogFactory.getLog(CLASS.class); ... Messages are logged to a logger, such as log by invoking a method corresponding to priority: The Log interface defines the following methods for use in writing log/trace messages to the log: log.fatal(Object message); log.fatal(Object message, Throwable t); log.error(Object message); log.error(Object message, Throwable t); log.warn(Object message); log.warn(Object message, Throwable t); log.info(Object message); log.info(Object message, Throwable t); log.debug(Object message); log.debug(Object message, Throwable t); log.trace(Object message); log.trace(Object message, Throwable t); While semantics for these methods are ultimately defined by the implementation of the Log interface, it is expected that the severity of messages is ordered as shown in the above list. In addition to the logging methods, the following are provided: log.isFatalEnabled(); log.isErrorEnabled(); log.isWarnEnabled(); log.isInfoEnabled(); log.isDebugEnabled(); log.isTraceEnabled(); These are typically used to guard code that only needs to execute in support of logging, and that introduces undesirable runtime overhead in the general case (logging disabled). GuidelinesMessage PrioritiesIt is important to ensure that log message are appropriate in content and severity. The following guidelines are suggested:
Configuring the LoggerThe Jakarta Commons Logging (JCL) SPI can be configured to use different logging toolkits. To configure which logger is used by the JCL, see the Axis System Integration Guide. Configuration of the behavior of the JCL ultimately depends upon the logging toolkit being used. The JCL SPI (and hence Axis) uses Log4J by default if it is available (in the CLASSPATH). Log4JAs Log4J is the prefered/default logger for Axis, a few details are presented herein to get the developer going. Configure Log4J using system properties and/or a properties file:
Axis Servlet Query String Plug-insAny servlet that is derived from the org.apache.axis.transport.http.AxisServlet class supports a number of standard query strings (?list, ?method, and ?wsdl) that provide information from or perform operations on a web service (for instance, ?method is used to invoke a method on a web service and ?wsdl is used to retrieve the WSDL document for a web service). Axis servlets are not limited to these three query strings and developers may create their own "plug-ins" by implementing the org.apache.axis.transport.http.QSHandler interface. There is one method in this interface that must be implemented, with the following signature: public void invoke (MessageContext msgContext) throws AxisFault; The org.apache.axis.MessageContext instance provides the developer with a number of useful objects (such as the Axis engine instance, and HTTP servlet objects) that are accessible by its getProperty method. The following constants can be used to retrieve various objects provided by the Axis servlet invoking the query string plug-in:
Query string plug-in development is much like normal servlet development since the same basic information and methods of output are available to the developer. Below is an example query string plug-in which simply displays the value of the system clock (import statements have been omitted for brevity): public class QSClockHandler implements QSHandler { public void invoke (MessageContext msgContext) throws AxisFault { PrintWriter out = (PrintWriter) msgContext.getProperty (HTTPConstants.PLUGIN_WRITER); HttpServletResponse response = (HttpServletResponse) msgContext.getProperty (HTTPConstants.MC_HTTP_SERVLETRESPONSE); response.setContentType ("text/html"); out.println ("<HTML><BODY><H1>" + System.currentTimeMillis() + "</H1></BODY></HTML>"); } } Once a query string plug-in class has been created, the Axis server must be set up to recognize the query string which invokes it. See the section Deployment (WSDD) Reference in the Axis Reference Guide for information on how the HTTP transport section of the Axis server configuration file must be set up. Configuration PropertiesAxis is in the process of moving away from using system properties as the primary point of internal configuration. Avoid calling System.getProperty(), and instead call AxisProperties.getProperty. AxisProperties.getProperty will call System.getProperty, and will (eventually) query other sources of configuration information. Using this central point of access will allow the global configuration system to be redesigned to better support multiple Axis engines in a single JVM. Exception HandlingGuidelines for Axis exception handling are based on best-practices for exception handling. While there are details specific to Axis in these guidelines, they apply in principle to any project; they are included here for two reasons. First, because they are not listed elsewhere in the Apache/Jakarta guidelines (or haven't been found). Second, because adherence to these guidelines is considered crucial to enterprise ready middleware. These guidelines are fundamentally independent of programming language. They are based on experience, but proper credit must be given to More Effective C++, by Scott Meyers, for opening the eyes of the innocent(?) many years ago. Finally, these are guidelines. There will always be exceptions to these guidelines, in which case all that can be asked (as per these guidelines) is that they be logged in the form of comments in the code.
Compile and RunThe xml-axis/java/build.xml file is the primary 'make' file used by ant to build the application and run the tests. The build.xml file defines ant build targets. Read the build.xml file for more information. Here are some of the useful targets:
To compile the source code: cd xml-axis/java ant compile To run the tests: cd xml-axis/java ant functional-tests Note: these tests start a server on port 8080. If this clashes with the port used by your web application server (such as Tomcat), you'll need to change one of the ports or stop your web application server when running the tests. Please run ant functional-tests and ant all-tests before checking in new code. InternationalizationIf you make changes to the source code that results in the generation of text (error messages or debug information), you must follow the following guidelines to ensure that your text is properly translated. Developer Guidelines
ExampleConsider the following statement: if (operationName == null) throw new AxisFault( "No operation name specified" ); We will add an entry into org/apache/axis/i18n/resource.properties: noOperation=No operation name specified. And change the code to read: if (operationName == null) throw new AxisFault(Messages.getMessage("noOperation")); InterfaceAxis uses the standard Java internationalization class java.util.ResourceBundle to access property files and message strings, and uses java.text.MessageFormat to format the strings using variables. Axis provides a single class org.apache.axis.i18n.Messages that manages both ResourceBundle and MessageFormat classes. Messages methods are: public static java.util.ResourceBundle getResourceBundle(); public static String getMessage(String key) throws java.util.MissingResourceException; public static String getMessage(String key, String var) throws java.util.MissingResourceException; public static String getMessage(String key, String var1, String var2) throws java.util.MissingResourceException; public static String getMessage(String key, String[] vars) throws java.util.MissingResourceException; Axis programmers can work with the resource bundle directly via a call to Messages.getResourceBundle(), but the getMessage() methods should be used instead for two reasons:
The getMessage methodsIf you have a message with no variables myMsg00=This is a string. then simply call Messages.getMessage("myMsg00"); If you have a message with variables, use the syntax "{X}" where X is the number of the variable, starting at 0. For example: myMsg00=My {0} is {1}. then call: Messages.getMessage("myMsg00","name", "Russell"); and the resulting string will be: "My name is Russell." You could also call the String array version of getMessage: Messages.getMessage("myMsg00", new String[] {"name", "Russell"}); The String array version of getMessage is all that is necessary, but the vast majority of messages will have 0, 1 or 2 variables, so the other getMessage methods are provided as a convenience to avoid the complexity of the String array version. Note that the getMessage methods throw MissingResourceException if the resource cannot be found. And ParseException if there are more {X} entries than arguments. These exceptions are RuntimeException's, so the caller doesn't have to explicitly catch them. The resource bundle properties file is org/apache/axis/i18n/resource.properties. Extending Message FilesGenerally, within Axis all messages are placed in org.apache.axis.i18n.resource.properties. There are facilities for extending the messages without modifying this file for integration or 3rd party extensions to Axis. See the Integration Guide for details. Adding TestcasesSee Also: Test and Samples Structure Editor's Note: We need more effort to streamline and simplify the addition of tests. We also need to think about categorizing tests as the test bucket grows. If you make changes to Axis, please add a test that uses your change. Why?
Some general principles:
One way to build a test is to "cut and paste" the existing tests, and then modify the test to suit your needs. This approach is becoming more complicated as the different kinds of tests grow. A good "non-wsdl" test for reference is test/saaj. Creating a WSDL TestHere are the steps that I used to create the sequence test, which generates code from a wsdl file and runs a sequence validation test:
Test StructureThe Test and Samples Redesign Document is here As of Axis 1.0, RC1, we have moved to a "componentized" test structure. Instead of having one high-level large recursive function, there are smaller, simple "component" build.xml files in the leaf level of the test/** and samples/** trees. These "component" files have a common layout. Their primary targets are:
A "sample" test xml file can be found in test/templateTest Adding Source Code ChecksThe Axis build performs certain automated checks of the files in the source directory (java/src) to make sure certain conventions are followed such as using internationalised strings when issuing messages. If a convention can be reduced to a regular expression match, it can be enforced at build time by updating java/test/utils/TestSrcContent.java. All that is necessary is to add a pattern to the static FileNameContentPattern array. Each pattern has three parameters:
A reasonable summary of the regular expression notation is provided in the Jakarta ORO javadocs. JUnit and AxisYou try to run some JUnit tests on an Axis client that invokes a web service, and you always get this exception: java.lang.ExceptionInInitializerError at org.apache.axis.client.Service.<init>(Service.java:108) ... Caused by: org.apache.commons.logging.LogConfigurationException: ... org.apache.commons.logging.impl.Jdk14Logger does not implement Log at org.apache.commons.logging.impl.LogFactoryImpl.newInstance (LogFactoryImpl.java:555) ... Actually, the Jdk14Logger does implement Log. What you have is a JUnit classloading issue. JUnit's graphical TestRunner has a feature where it will dynamically reload modified classes every time the user presses the "Run" button. This way, the user doesn't need to relaunch the TestRunner after every edit. For this, JUnit uses its own classloader, junit.runner.TestCaseClassLoader. As of JUnit 3.8.1, confusion can arise between TestCaseClassLoader and the system class loader as to which loader did or should load which classes. There are two ways to avoid this problem.
Copy this file, preserving the directory path, into another location, e.g. deployDir. So the copied properties file's path will be deployDir/junit/runner/excluded.properties. Add an extra entry to the end of this file: excluded.9=org.apache.* Edit your classpath so that deployDir appears before junit.jar. This way, the modified excluded.properties will be used, rather than the default. (Don't add the path to excluded.properties itself to the classpath.) This fix will prevent the commons-logging exception. However, other classloading problems might still arise. For example: Dec 10, 2002 7:16:16 PM org.apache.axis.encoding.ser.BeanPropertyTarget set SEVERE: Could not convert [Lfoo.bar.Child; to bean field 'childrenAsArray', type [Lfoo.bar.Child; Dec 10, 2002 7:16:16 PM org.apache.axis.client.Call invoke SEVERE: Exception: java.lang.IllegalArgumentException: argument type mismatch at org.apache.axis.encoding.ser.BeanPropertyTarget.set (BeanPropertyTarget.java:182) at org.apache.axis.encoding.DeserializerImpl.valueComplete (DeserializerImpl.java:284) ... In this case, you have no choice but to give up on dynamic class reloading and use the -noloading argument. One other heads-up about JUnit testing of an Axis web service. Suppose you have run JUnit tests locally on the component that you want to expose as a web service. You press the "Run" button to initiate a series of tests. Between each test, all your data structures are re-initialized. Your tests produce a long green bar. Good. Suppose you now want to run JUnit tests on an Axis client that is connecting to an application server running the Axis web application and with it your web service. Between each test, JUnit will automatically re-initialize your client. Your server-side data structures are a different matter. If you're checking your server data at the end of each test (as you should be) and you run more than one test at a time, the second and later tests will fail because they are generating cumulative data on the Axis server based on preceding tests rather than fresh data based only on the current one. This means that, for each test, you must manually re-initialize your web service. One way to accomplish this is to add to your web service interface a re-initialize operation. Then have the client call that operation at the start of each test. Using tcpmon to Monitor Functional TestsHere is an easy way to monitor the messages while running functional-tests (or all-tests). Start up tcpmon listening on 8080 and forwarding to a different port: java org.apache.axis.utils.tcpmon 8080 localhost 8011 Run your tests, but use the forwarded port for the SimpleAxisServer, and indicate that functional-tests should continue if a failure occurs. ant functional-tests -Dtest.functional.SimpleAxisPort=8011 -Dtest.functional.fail=no The SOAP messages for all of the tests should appear in the tcpmon window. tcpmon is described in more detail in the Axis User's Guide. Using SOAP Monitor to Monitor Functional TestsIf you are debugging code that is running as a web application using a web application server (such as Tomcat) then you may also use the SOAP Monitor utility to view the SOAP request and response messages. Start up the SOAP monitor utility by loading the SOAP monitor applet in your web browser window: http://localhost:<port>/axis/SOAPMonitor As you run your tests, the SOAP messages should appear in the SOAP monitor window. SOAP Monitor is described in more detail in the Axis User's Guide. Running a Single Functional TestIn one window start the server: java org.apache.axis.transport.http.SimpleAxisServer -p 8080 In another window, first deploy the service you're testing: java org.apache.axis.client.AdminClient deploy.wsdd Then bring up the JUnit user interface with your test. For example, to run the the multithread test case: java junit.swingui.TestRunner -noloading test.wsdl.multithread.MultithreadTestCase DebuggingTurning on Debug OutputThis section is oriented to the Axis default logger: Log4J. For additional information on Log4J, see the section Configuring the Logger.
Writing Temporary OutputRemember that Axis is targeted for use in a number of open-source and other web applications, and so it needs to be a good citizen. Writing output using System.out.println or System.err.println should be avoided. Developers may be tempted to use System.out.println while debugging or analyzing a system. If you choose to do this, you will need to disable the util/TestSrcContent test, which enforces avoidance of System.out.println and System.err.println. It follows that you will need to remove your statements before checking the code back in. As an alternative, we strongly encourage you to take a few moments and introduce debug statements: log.debug("reasonably terse and meaningful message"). If a debug message is useful for understanding a problem now, it may be useful again in the future to you or a peer. Running the JAX-RPC Compatibility TestsAs well as a specification, JAX-RPC has a Technology Compatibility Kit (TCK) which is available to members of the JAX-RPC Expert Group (and others?). The kit comes as a zip file which you should unzip into a directory of your choosing. The installation instructions are in the JAX-RPC Release Notes document which is stored in the docs directory. If you open the index.html file in the docs directory using a web browser, you'll see a list of all the documents supplied with the kit. Note that the kit includes the JavaTest test harness which is used for running the compatibility tests. If any more information is needed about running these tests, please add it here! |