for
example).
But making such a change would be out of my league as well.
And for the record, we already have Jörg’s improvement in place .
Kind regards
Wim
Van: Julian Sedding
Datum: maandag, 30 november 2020 om 11:59
Aan: Sling Developers List
Onderwerp: Re: Dynamic Class Loader Manager
Hi Wim
I looked into this issue back then and concluded that it may not be
feasible at all to (significantly) improve the restart-performance of
the DCLM. The reason is that it is very hard or impossible to
correctly replace class-loaders due to JVM internal caching (I forgot
the details, it's
Hi all,
We upgraded from AEM 6.4 to AEM 6.5 last week and unfortunately we learned
about DLCM.
Before AEM 6.5 we had absolutely no trouble to keep the AEM author online while
deploying and had no JSP/HTL errors during deploys.
As of AEM 6.5 that changed for the worse.
Because of all the Sling
Big +1 to improve the situation
One thought to make it simpler (without knowing this piece of code very
well): As far as I understood there is exactly one instance of the
dynamic
classloader at one time, and if classes that it delivered change, all
consumers are restarted. Could we not just
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 wrote:
>
>
> Am 24.10.2019 um 11:29 schrieb Julian Sedding:
> > Thank you
@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
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
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
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
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
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
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
12 matches
Mail list logo
