The solution you proposed will not solve the issue as you cannot replace the classloader of the application server. 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. Cheers, Daniel
> -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Craig McClanahan > Gesendet: Sonntag, 19. Dezember 2004 22:46 > An: Jakarta Commons Developers List > Betreff: Re: AW: AW: [proposal] avoiding jar version nightmares > > On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata > <[EMAIL PROTECTED]> wrote: > > This may work, but does BCEL require the use of its own custom > > classloader also? > > > > This seems to me that this isn't just a problem with commons; it is a > > problem with Java itself that .NET already has a very nice solution for. > > I'm wondering if this isn't something that should be taken care of at > > the JVM level i.e. - in Java 1.6. The obvious solution seems to be that > > we need to fix classloaders. They're already a huge nightmare in EJB > > containers. > > > > How do we go about petitioning Sun for something like this? > > A while back now (while the details for Tiger were being planned), I > happened to be in a meeting with Graham Hamilton (who basically owns > the direction that J2SE is going from a Sun perspective), talking > about the very issue of class loaders and the contortions that you > have to go through in order to implement things like webapp reloading. > I asked him for a Christmas present to all Java developers -- add > something like ClassLoader.unloadClass() or ClassLoader.replaceClass() > to deal with things like this. He said "hmm ... that's a hard > problem" and proceeded to describe several of the places where > implementing this would be extremely difficult (and/or would have > nasty performance impacts) in the current architecture of JVMs. > > Regarding the original use case in this thread (an app that wants to > use two modules that have conflicting versions of common > dependencies), about the best you can do right now is to have your > application create its own class loaders for the modules involved, and > set up their classpaths to pick up their own versions of the > dependencies. That is essentially what a servlet container does > (creates a class loader for each webapp) to maintain separation, and > allows each webapp to load its own version of a common dependency JAR > from its own "class path" ... the /WEB-INF/classes and /WEB-INF/lib > directories of that app. > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
