2016-08-23 17:15 GMT+02:00 Clebert Suconic <[email protected]>:
> On Tue, Aug 23, 2016 at 10:55 AM, Romain Manni-Bucau > <[email protected]> wrote: > > > > 2016-08-23 16:51 GMT+02:00 Clebert Suconic <[email protected]>: > >> > >> TBH: I don't expect the implementation to ever change on a given > >> classLoader. > >> > > > > So you accept to not work for tomcat, tomee, geronimo, wildfly (ok they > will > > not use that jar), karaf etc...? Point is a serious amount of users rely > on > > redeployment so we have to support cleaning up somehow. > > As Far as I know redeployment means a classLoader change. If you cache > per classLoader a redeployment will remove the old classLoader and add > a new one. > > No applicaition server that I know will change loaded classes once the > classLoader is up. Redeployments will remove the old classloader and > create a new one. > > "Redeployments will remove the old classloader" this is were we "split" I suspect. This is not true since the key is a classloader and classloader is the root of most of everything so GC is rarely enough > > There are serious implications to the application server if that > doesn't work this way. So I doubt any application server would behave > differently. > > > I may be wrong, but this is what I have seen over the years. > Think we agree on what we want but disagree on what actually happens there. What about starting with the registry I proposed and enhance/fix it on demand? Sounds like a compromise
