----- Original Message ----- From: "Jens Schumann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 03, 2003 13:36 Subject: Re: Bug 17347 - Provider Lookup Fails within EARs
>> The problem is choosing which classloader to use. We could consider >> standardising on ServletContext.getResourceAsStream(), as it doesnt have to >> be a classloader at all. Or we have a method >> AxisEngine.getResourceAsStream(String path) that tries the ServletContext >> call first, then its own classloader if that fails to find resources. At the >> very least, it would give us a single place to instrument and toy with when >> trying to fix future problems. > >That�s exactly what I am looking for. I could spend another 10 pages about >classloaders in EARs/WAR archives - using ServletContext.getResource() or >ServletContext.getResourceAsStream() solved all those problems. I don't want >to mix up things here, but be aware that some people need to be able to have >multiple AxisEngines within one WAR, something which does not work right now >(because one AxisServer instance is "cached" in the servlet context). So >whatever we do to fix classloading, it should not prevent this setup. I havent heard of anyone trying to do >1 engine per webapp; you can always multi-webapp if that is needed. We have to cache the engine somewhere, and its either a static variable, a JMX registration or a servlet context, and since we dont support JMX, servlet contexts are what you get (though I would like to also register the engine in JMX). The trouble with servlet contexts is what will we do when we start supporting other transports more seriously? we have dependencies on servlets deep into Axis, which is mixing layers too closely for my liking
