That particular concern can easily get addressed via this trick [1]:
protected static Map<ClassLoader, WeakReference<Config>> configs = Collections.synchronizedMap(new WeakHashMap<ClassLoader, WeakReference<Config>>()); LieGrue, strub [1] https://github.com/struberg/javaConfig/blob/master/impl/src/main/java/org/apache/geronimo/config/DefaultConfigProvider.java#L33 On Tuesday, 23 August 2016, 17:18, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > > > >2016-08-23 17:15 GMT+02:00 Clebert Suconic <clebert.suco...@gmail.com>: > >On Tue, Aug 23, 2016 at 10:55 AM, Romain Manni-Bucau >><rmannibu...@gmail.com> wrote: >>> >>> 2016-08-23 16:51 GMT+02:00 Clebert Suconic <clebert.suco...@gmail.com>: >>>> >>>> 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 > > > >
