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]
