On Sun, 19 Dec 2004 14:06:40 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Sun, 19 Dec 2004 22:52:48 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote: > > The solution you proposed will not solve the issue as you cannot replace the > > classloader of the application server. > > That's not what I proposed. If you're inside a webapp, what I > proposed is that you create your own classloaders *within* your > application, and load the conflicting portions into their own class > loaders (i.e. instead of loading them from /WEB-INF/classes or > /WEB-INF/lib).
This does not work when you rely on software you can not change. > > Finally I think that my proposal is not that bad. If it's not possible to > > address this issue in future versions of the java language, this seems to be > > the only solution. > > So my vote is +1 to add at least the major version number to the components > > package name. > > That would have unacceptable impacts on people who don't have the > cross-dependency issue, but just want to use a newer version of a > particular library that *does* maintain backwards compatibilty across > versions. Therefore, I'd -1 such a proposal on any Commons package > that I'm involved with. Major releases, i.e. e.g. from 1.x to 2.x are there not to be backward compatible. Especially, I would even consider it dangerous to replace a 1.x version with 2.x without checks just to have a newer version. Semantics could have chages. Consider collections from 2. to 3. What was done there was perfectly alright. I am +1 for all components I am involved with. Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
