You may also want to try the hint re -Djava.endorsed.dirs=path_to_axis_lib
Not sure this fixes your problem, but I've seen wierdness when the jar files were all spec'ed explicitly in the classpath, but that still failed because of conflict with other jars in the jdk/jvm, but worked when the jars were picked up via -Djava.endorsed.dirs=path_to_axis_lib There's a lot of dll-hell that's going on with xml parsers et all. I've seen it with struts needing a latest-greatest xerces that wasn't being picked up because ... etc. I know this isn't an xml parser problem, but it's still a confusing mess java equivalent of dll-hell. I haven't seen a clean write up on what gets picked up when/where depending on what jvm (remember when ibm's came with jre/lib/ext which differed from sun's setup but all of the jars there were guaranteed to be one revision less than what you needed?) On Thu, 2002-05-16 at 14:05, Mike Spreitzer wrote: > I solved this one on my own (after getting zero help from the list). The > problem is that log4j-core.jar needs to be in the same classloader, or a parent of >the classloader, that > contains commons-logging.jar. In my case, a little re-ordering solved the > problem (once I understood it).
