Log4J appenders correspond to different output devices: console, files, sockets, and others. If appender's threshold is less than or equal to the message priority then the message is written by that appender.
This allows different levels of detail to be appear at different log destinations. Any servlet that is derived from the org. AxisServlet class supports a number of standard query strings? Axis servlets are not limited to these three query strings and developers may create their own "plug-ins" by implementing the org.
QSHandler interface. There is one method in this interface that must be implemented, with the following signature:. 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:. A String containing the name of the query string plug-in. For instance, if the query string? A Boolean containing true if this version of Axis is considered to be in development mode, false otherwise. A Boolean containing true if listing of the Axis server configuration is allowed, false otherwise. The javax. HttpServletRequest object from the Axis servlet that invoked the query string plug-in.
HttpServletResponse object from the Axis servlet that invoked the query string plug-in. The java. PrintWriter object from the Axis servlet that invoked the query string plug-in. Log object from the Axis servlet that invoked the query string plug-in, which is used to log messages. Log object from the Axis servlet that invoked the query string plug-in, which is used to log exceptions. 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 :. 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.
Axis is in the process of moving away from using system properties as the primary point of internal configuration. Avoid calling System. 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. Guidelines 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.
Second, because adherence to these guidelines is considered crucial to enterprise ready middleware. These guidelines are fundamentally independent of programming language. 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. If code catches an exception, it should know what to do with it at that point in the program.
Any exception to this rule must be documented with a GOOD reason. Code reviewers are invited to put on their vulture beaks and peck away Inner code is code deep within the program.
Such code should catch specific exceptions, or categories of exceptions parents in exception hierarchies , if and only if the exception can be resolved and normal flow restored to the code. Note that behaviour of this sort may be significantly different between non-interactive code versus an interactive tool. Ultimately, all exceptions must be dealt with at one level or another. For command-line tools, this means the main method or program.
For a middleware component, this is the entry point s into the component. For Axis this is AxisServlet or equivalent. After catching specific exceptions which can be resolved internally, the outermost code must ensure that all internally generated exceptions are caught and handled. While there is generally not much that can be done, at a minimum the code should log the exception. In addition to logging, the Axis Server wraps all such exceptions in AxisFaults and returns them to the client code.
This may seem contrary to the primary rule, but in fact we are claiming that Axis does know what to do with this type of exception: exit gracefully. It may then be rethrown, or wrapped, as described below. If an exception is caught and rethrown unresolved , logging of the exception is at the discretion of the coder and reviewers. If any comments are logged, the exception should also be logged.
When in doubt, log the exception and any related local information that can help to identify the complete context of the exception.
Log the exception as an error log. When exception e is caught and wrapped by a new exception w , log exception e before throwing w. When exception e is caught and resolved, logging of the exception is at the discretion of the coder and reviewers. If any comments are logged, the exception should also be logged log. Issues that must be balanced are performance and problem resolvability.
There are multiple aspects of this guideline. On one hand, this means that business logic should be isolated from system logic. This implies a well designed server interface. Exceptions generated by the Axis runtime should be handled, where possible, within the Axis runtime. In the worst case the details of an exception are to be logged by the Axis runtime, and a generally descriptive Exception raised to the Business Logic.
Exceptions raised in the business logic this includes the server and Axis handlers must be delivered to the client code. Protect the Axis runtime from uncontrolled user business logic. For Axis, this means that dynamically configurable handlers , providers and other user controllable hook-points must be guarded by catch Exception Exceptions generated by user code and caught by system code should be:. Specific exceptions should be logged at the server side, and a more general exception thrown to the client.
This prevents clues as to the nature of the server such as handlers, providers, etc from being revealed to client code. The Axis component boundries that should be respected are:. Before throwing an exception in a constructor, ensure that any resources owned by the object are cleaned up. For objects holding resources, this requires catching all exceptions thrown by methods called within the constructor, cleaning up, and rethrowing the exceptions.
The build. Read the build. Here are some of the useful targets:. Note: these tests start a server on port 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.
If 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. Axis uses the standard Java internationalization class java. ResourceBundle to access property files and message strings, and uses java. MessageFormat to format the strings using variables.
Axis provides a single class org. Messages that manages both ResourceBundle and MessageFormat classes. Messages methods are:. Axis programmers can work with the resource bundle directly via a call to Messages. For example:. 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. These exceptions are RuntimeException 's, so the caller doesn't have to explicitly catch them. Generally, within Axis all messages are placed in org. 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. 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. 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. Here are the steps that I used to create the sequence test, which generates code from a wsdl file and runs a sequence validation test:.
As of Axis 1. Instead of having one high-level large recursive function, there are smaller, simple "component" build. 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. You try to run some JUnit tests on an Axis client that invokes a web service, and you always get this exception:. 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.
As of JUnit 3. Copy this file, preserving the directory path, into another location, e. Add an extra entry to the end of this file:. Edit your classpath so that deployDir appears before junit.
This way, the modified excluded. Don't add the path to excluded. This fix will prevent the commons-logging exception. However, other classloading problems might still arise. 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. 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. Here is an easy way to monitor the messages while running functional-tests or all-tests. Run your tests, but use the forwarded port for the SimpleAxisServer, and indicate that functional-tests should continue if a failure occurs.
If 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. Then bring up the JUnit user interface with your test.
For example, to run the the multithread test case:. This section is oriented to the Axis default logger: Log4J. For additional information on Log4J, see the section Configuring the Logger.
The log4j. Subsequent items presume changes to these settings. If you are completely new to Java, we recommend you start off with things like the Java Tutorials on Sun's web site, and perhaps a classic book like Thinking in Java , until you have enough of a foundation to be able to work with Axis. It is also useful to have written a simple web application, as this will give you some knowledge of how HTTP works, and how Java application servers integrate with HTTP.
You may find the course notes from Mastering the World Wide Web useful in this regard, even though Axis is only introduced in lecture Be aware that there is a lot more needed to be learned in order to use Axis and SOAP effectively than the listing above.
The other big area is "how to write internet scale distributed applications". Nobody knows how to do that properly yet, so that you have to learn this by doing. SOAP is a mechanism for inter-application communication between systems written in arbitrary languages, across the Internet. Open Source means that you get the source, but that there is no formal support organisation to help you when things go wrong. These messages exchange structured information between SOAP systems.
Axis handles the magic of converting Java objects to SOAP data when it sends it over the wire or receives results. SOAP is intended to link disparate systems. It is not a mechanism to tightly bind Java programs written by the same team together. If you try sending many Java objects that RMI would happily serialize, you will be disappointed at how badly Axis fails.
This is by design: if Axis copied RMI and serialized Java objects to byte streams, you would be stuck to a particular version of Java everywhere. If you look at the specification and tutorials on Sun's web site, you will understand the API. You can use these to write better programs, but these will only work with the Axis implementation. But since Axis is free and you get the source, that should not matter. Axis is compiled in the JAR file axis. It needs various helper libraries, for logging, WSDL processing and introspection.
All these files can be packaged into a web application, axis. Axis ships with some sample SOAP services. You can add your own by adding new compiled classes to the Axis webapp and registering them. Here we assume that you have a web server up and running on the localhost at port If your server is on a different port, replace references to to your own port number.
In your Application Server installation, you should find a directory into which web applications "webapps" are to be placed. You can actually name this directory anything you want, just be aware that the name you choose will form the basis for the URL by which clients will access your service.
The rest of this document assumes that the default webapp name, "axis" has been used; rename these references if appropriate. This directory contains some basic configuration information, but can also be used to contain the dependencies and web services you wish to deploy. Axis needs to be able to find an XML parser. If your application server or Java runtime does not make one visible to web applications, you need to download and add it.
Java 1. We recommend Xerces jars from the xml-xerces distribution , though others mostly work. The examples in this guide use Xerces. This guide adds xml-apis. Specifically, they only get loaded from endorsed directories. If happyaxis. WebLogic 8. This conflict exists because WebLogic uses an older definition of javax. However, there are two alternative configuration changes that enable Axis based web services to run on Weblogic 8.
This is a recommended approach since it only impacts a single web module. This varies on a product-by-product basis. In many cases it is as simple as double clicking on a startup icon or running a command from the command line. After installing the web application and dependencies, you should make sure that the server is running the web application.
You should now see an Apache-Axis start page. If you do not, then the webapp is not actually installed, or the appserver is not running. Follow the link Validate the local installation's configuration This will bring you to happyaxis. If any of the needed libraries are missing, Axis will not work. You must not proceed until all needed libraries can be found, and this validation page is happy. Optional components are optional; install them as your need arises.
Eliminate the extra parsers, restart the app server and try again. From the start page, select View the list of deployed Web services. This will list all registered Web Services, unless the servlet is configured not to do so. On this page, you should be able to click on wsdl for each deployed Web service to make sure that your web service is up and running.
The install guide covers this topic in detail. Now it's time to test a service. Although SOAP 1. First let's retrieve the version of Axis from the version endpoint, calling the getVersion method:.
Your browser may display the result in a formatted way; be sure to check the source code of your returned page. The Axis version and build date may of course be different.
Now let's test a JWS web service. When someone requests the. The user guide covers JWS pages in detail. Again, the exact return values will be different, and you may need to change URLs to correct any host, port and webapp specifics. The process here boils down to 1 get the classes and libraries of your new service into the Axis WAR directory tree, and 2 tell the AxisEngine about the new file.
It's also a special SOAP service in one regard--it is restricted to local callers only not remote access and is password protected to stop random people from administrating your service. There is a default password that the client knows; if you change it then you need to pass the new password to the client. In this directory, copy the compiled Java classes you wish to install, being careful to preserve the directory structure of the Java packages. Also add any third party libraries you depend on into the same directory.
After adding new classes or libraries to the Axis webapp, you must restart the webapp. This can be done by restarting your application server, or by using a server-specific mechanism to restart a specific webapp. Note: If your web service uses the simple authorization handlers provided with xml-axis this is actually not recommended as these are merely illustrations of how to write a handler than intended for production use , then you will need to copy the corresponding users.
What remains to be done is to tell Axis how to expose this web service. The users guide and reference guide cover these WSDD files; here we are going to use one from the Axis samples: the stock quote service.
In order for these examples to work, java must be able to find axis. Also for these examples, we have copied the xml-apis. On Windows, this can be done via the following. Click the "Advanced" tab and create the new environmental variables.
It is often better to use WordPad to create the variable string and then paste it into the appropriate text field. Unix users have to do something similar. See your shell's documentation for differences. To make variables permanent you will need to add them to your shell's startup dot files.
Again, see your shell's documentation. This document assumes that you have NOT done this. This is the deployment descriptor we want to tell Axis about. The Axis 'engine' will update its configuration, then save its state. Sometimes you see a warning message about such a file not being found--don't worry about this, because Axis auto-creates the file after you deploy something to it.
You can check in the webapp to see what this file looks like--and even copy it to other systems if you want to give them identical configurations. If you are not in this directory you will get a "java. FileNotFoundException: deploy. Tracking down such problems are foundational Java development skills--if you don't know how to do these things, learn them now! Note: You may need to replace localhost with your host name, and with the port number used by your web server. If you have renamed the web application to something other than "axis" change the URL appropriately.
If you get some AxisFault listing, then the client is working, but the deployment was unsuccessful. If you got some socket error like connection refused, the computer at the far end isn't talking to you, so find the cause of that and fix it. If you get an HTTP error code back find out what the error means and correct the problem.
These skills are fundamental to using web services. The user's guide covers the AdminClient in more detail, and there is also an Ant task to automate the use of Axis in your Ant build scripts. This step is optional, but highly recommended. For illustrative purposes, it is presumed that you have installed and deployed the stock quote demo. Note: Again, you may need to replace localhost with your host name, and with the port number used by your web server.
0コメント