| Thank you for your comments. I'm the one responsible for migrating AXIS to the commons-logging API. Let me first acknowledge that recent builds of the commons-logging API DO tend to (unnaturally) favor Log4j. However, the fundamental principle of being able to remove Log4j is still available. If you are interested in pursuing AXIS further, or in helping us to improve logging implementation pluggability, please let us know more detail. Specific problems with the integration guide & user's guide related to removing Log4j? Did you override the Log implementation, or the LogFactory? Thanks, <ras> ******************************************* Richard A. Sitze [EMAIL PROTECTED] CORBA Interoperability & WebServices IBM WebSphere Development  Alice Byrne <[EMAIL PROTECTED]>
Hello, The AXIS toolkit is very impressive and we used it up until the java policies got in the way running stubs from within applets. Apparently, it's not a trivial matter to suppress the property reads being performed by log4j. Additionally, it's not practical to remove log4j from AXIS. In short, we abandoned AXIS for the simpler requirement of transmitting XML over HTTP. Actually, it's fairly trivial to mimic SOAP using the HttpUrlConnection class (we authored a SOAP server and realize there's more to consider then just XML over transport.) I feel it's necessary to give you a heads up about our experience. We're using SOAP for a commercial solution in the broadcast and made a reasonable commitment to AXIS. We need to learn more about log4j and its benefits; however, it did get in the way of production. AXIS is a great a product. By the way, the stub generator is very useful. Sincerely, William Byrne Manager Interactive Engineering Development Chyron, Corp. |
