> Ok. I see what your are talking about. The problem is, Magnus > does not respond anymore (probably got too rich after the > oracle deal ;). So it would be good to make sure orion does > use different classloaders to load the common jar resources > you are referring to. From what you are describing it sounds > like the class gets loaded just once for all applications. As > far I can tell axis does not do anything wrong apart from > using current thread classloaders (which might lead to > classnotfound issues, but see side effects below). > Are you sure you don't run into the same problem using the > same approach without axis? If there would have been clear > separation from orion you would not be able to alter > attributes of another application.
Thank you for taking time trying to resolve this. I totally agree that the Orion team are probably too rich by now. We haven't got any answers from them for a long time either :-/ Orion has several layers of classloaders. There is one common base classloader which we Only use for third party jars, after that the following classloaders branch for each application. The class in question is loaded, one copy for each such application. If I for example access it from a JSP page which I copy to each application, I will get a unique return value from the static variable from each application. > So my question is: Do you access your common statics using a > static initializer or equal inside EJBs? Because then the > axis current thread context classloader approach might be a > problem, in conjunction with a broken deployment process in > orion. I could image a global deployment thread which does > have access to all resources through its classloader. I have checked the code, no we don't access this particular object in the static initializers we have (or code called from them.). This is how we first refer to this common static and set its value, once and for all: * During startup of each application, each application has a "load on startup" servlet started. * In the init() method of that servlet, code is executed that uses the JNDI to locate the application ID from "java:comp/env/" (the application Id is set as a env-entry in web.xml for the web module of each application). * The servlet then goes on to call an initializer EJB bean and passes the application id as a parameter. This bean directly references the class with the magic static variable by asking it to set the application id in its only static variable. This way the application ID has been set in the EJB layer, thereby being acessible to both the EJB layer and web layers on top of it. One might argue why we don't set the application id in the env-entry of ejb-jar.xml instead. The reason is that we maintain one common ejb-jar file for all applications. -Each application share the same base functionality but has different web layers.
