@Konrad: I agree that on AEM the JCR package manager is the main issue. However, I believe the JSP implementation of the REST API has already been replaced with the PackageManagerServlet. The problem is that the PackageManagerServlet has a reference to the DCLM in order to allow InstallHook implementations to load classes from OSGi.
Regards Julian On Fri, Oct 25, 2019 at 8:51 AM Konrad Windszus <[email protected]> wrote: > > One of the main issues with the DCLM restart is the availability of the AEM > package manager itself. As the AEM package manager ReST endpoint depends as > well on the DCLM (written in JSP) it is usually restarted after a bundle > deployment triggered by package installation (and therefore for quite a time > no longer available for a subsequent package installation). Although some of > the pain has been taken with https://issues.apache.org/jira/browse/SLING-3747 > <https://issues.apache.org/jira/browse/SLING-3747>, it is still an issue for > subsequent package installations. > I guess much of the pain would already be resolved in case something like > https://issues.apache.org/jira/browse/JCRVLT-151 > <https://issues.apache.org/jira/browse/JCRVLT-151> would be implemented in a > way which doesn't rely on scripts (but rather on precompiled servlets). > Konrad > > > > On 22. Oct 2019, at 10:21, Konrad Windszus <[email protected]> wrote: > > > > Hi Julian, > > thanks a lot for bringing up this topic. Indeed the restart cascade causes > > some issues for me as well. Just invalidating the cache of the DCLM without > > restarting it fully sounds reasonable to me, but I am not that familiar > > with class loader insights. I vaguely remember that the restart might be > > necessary due to static cache fields but I don't remember the details... > > Maybe Carsten remembers... > > Konrad > > > >> On 22. Oct 2019, at 10:00, Julian Sedding <[email protected]> wrote: > >> > >> Hi all > >> > >> I have observed repeatedly that reinstalling bundles of a custom Sling > >> (actually AEM) application causes a lot of activity in the OSGi > >> framework and thus can take quite a long time (10s of seconds to > >> minutes), which feels quite disruptive during development where > >> frequent deployments are common. > >> > >> As far as I can see the Dynamic Class Loader Manager (DCLM) does "the > >> right thing" and restarts itself when a bundle whose classes have been > >> loaded via the dynamic class loader is reinstalled. The restart of the > >> DCLM then causes all services referencing it to restart as well, > >> causing, amongst others, scripting engines to restart and generally > >> triggering a cascade of service restarts. > >> > >> This seems to be especially common with bundles providing model > >> classes that are used in rendering scripts (a prime use-case for > >> customizations), but is not limited to such cases. Note: it is > >> necessary to run a rendering script using the model before > >> reinstalling the bundle in order to cause the restarts > >> > >> I was wondering if it wouldn't be possible to change the DCLM in a way > >> that it doesn't need to restart, but that it just swaps out the class > >> loader(s) behind the facade.I don't have much experience with > >> implementing custom class loaders, but I have a hunch that this may be > >> difficult to get right due to class loader internal caching of loaded > >> classes. > >> > >> Is there anyone more knowledgable in this area who could provide an > >> assessment regarding the feasibility of such an approach? > >> > >> Regards > >> Julian > > >
