Thanks Carsten for the hint about how to create artificial bundles on the fly. As you say refactoring towards that goal would be a significant undertaking.
Regards Julian On Fri, Oct 25, 2019 at 7:34 AM Carsten Ziegeler <[email protected]> wrote: > > > Am 24.10.2019 um 11:29 schrieb Julian Sedding: > > Thank you for your insights, Carsten! That saves me hitting that wall ;) > > > > I'm curious how your idea with artificial bundles would work. Would > > the scripts in the resource tree be exposed via one or more artificial > > bundle, each, importing the packages required by the scripts? And then > > the scripting engines could run the scripts using the bundle class > > loader of these artificial bundles. Is that right? > > > Yes, something along those lines. It makes sense to have more than one > artifical bundle otherwise again you have one bundle with a very large > list of imports. > > > If that is correct, I guess that would benefit from the upcoming OSGi > > Connect specification (if I recall the name correctly). > > > I assume you mean to install the artificial bundle? This can be done > without connect as you basically just have to create a jar file with a > manifest and then pass this as an input stream into the framework to > install it. > > Regards > Carsten > > > Regards > > Julian > > > > On Tue, Oct 22, 2019 at 12:44 PM Carsten Ziegeler <[email protected]> > > wrote: > >> > >> As Julian suspected class loaders are caching. Initially we tried just > >> swapping things in the background but that didn't work due to the class > >> loader caching and that's out of control. > >> > >> A better solution would be to avoid the DCLM completely and rather > >> leverage OSGi more by for example creating artificial bundles with > >> imports which are then used by scripting. Similarly all scripts are > >> currently loaded by a single class loader. If a class changes where just > >> one of the scripts is based on, everything is still reloaded. That's not > >> really modular :) > >> > >> Or in other words the problem could potentially be solved but that's a > >> rather larger work. Unless there is something we haven't thought of yet. > >> > >> Regards > >> Carsten > >> > >> Am 22.10.2019 um 10:21 schrieb Konrad Windszus: > >>> 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 > >>> > >> > >> -- > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> [email protected] > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
