> Hmm. > What do you mean by "share a common classpath"? They all refer to the same > jar within an EAR? Or you added the class to the system classpath?
In our system we don't pack each application to EARs, we leave them unpacked. Each application.xml refers to the same classpath, -a path to a directory > I am not sure what you mean by classloader separation either. This is not > mandatory, just one way to deploy applications. Therefore write access to > statics is prohibited by EJB spec, because it would leave an application in > an undefined state, as yours. Until the EJB specification matures we have found ourselves forced to rely on static variables in some rare occations (write once, read many), knowing it is a bit unorthodox (can cause problem with clustering for example if you do write many). I see no reason however for AXIS to mix up the separation of classloaders encforced by Orion/Oracle. Of course having separate classloaders is just one implementation, one could separate J2EE applications by running them inside different VMs too, but that was not the way Orion/Oracle choose to do it. I know we broke one rule by using a static variable, but the fact is that the EJB specification, (or at least the implementation we use) doesn't well support some important things one needs to be able to do, one of them being able to, from an EJB layer, look up the name/identifier of an application that has been set in a way that is practical and safe from a deployment perspective. We use a write once, read many static variable for this purpose. There may be a suitable solution with a particuar EJB implementation, but we haven't found a good one for Orion/Oracle. In short: AXIS is probably not breaking a rule here with its implementation, but with an adjustment to how it uses classloaders, it would be more compatible with existing J2EE solutions. -Solutions that may not be 100% orthodox, but solutions that look the way they do for a good reason. /David
<<winmail.dat>>
