David, Can u please log a bug in bugzilla? patches are welcome as well.
Thanks, dims --- David Ekholm <[EMAIL PROTECTED]> wrote: > > 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 > > > ATTACHMENT part 2 application/ms-tnef name=winmail.dat ===== Davanum Srinivas - http://webservices.apache.org/~dims/ __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
