From some light-testing on a local instance installing the Hotfix won't
break 6.4.It brings the minor version up from 1.2.60 to 1.2.100.There's
virtually zero active development within the CRX space of AEM. It's a
very mature part of the product. So changes across AEM versions is
generally minimal. You should be okay with this fix. Test on a local
first. The fix won't be available in a service pack until :AEM 6.5.6AEM
NOTE -- you will need to use Firefox or some other non-Chrome browser to
install. NOTE -- this was built for AEM 6.5
I made the post before I fully realized where the change needed to be
made. I saw the GIT commit in a JS file and incorrectly assumed we could
manually patch it. But unfortunately, the change is within the bundle
itself so a new JAR will be needed. The fix is within build -
May want to log a ticket. DISP-818 removed the Cache-Control header from
requests with query parameters BUT -- this introduced some unintended
things which are currently being handled under the open JIRA
When you manually touch a config via ConfigMgr in the OSGI Felix Console
it will create the config as a nt:file node under /apps/system/config .
It's not touching the pre-existing sling:OsgiConfig node or config file.
You can see which configuration is taking precedence here :
Can you share the output in the error.log from the HTML Library Manager?
It likely spits out some more details on why the minification fails. Can
you manually minify your JS directly on Google Closure? Here :
With the Dispatcher log level at DEBUG can you share the log output for
the vanityUrl request? Do you have the vanityurls component
installed?It's an old package from 2015 that oddly enough doesn't come
with the product ootb.
sling.servlet.methods is only applicable on registration of a servlet
via sling.servlet.resourceTypes your servlet example is registered on
The JDK Downloads are hosted on the Adobe Software Distribution
OpenJDK is still not supported. Generally you'd do the upgrade from 6.3
to 6.5 on JDK8.Then it's start AEM with Java11. If you're running into
an issue please log a Daycare ticket and provide the logs as well as the
everything under /crx-quickstart/conf The sling.properties file could
have some weird things going on that prevents start up. Aga...
When you made the change to the workflow model did you sync it to
generate the runtime model? See :
If you manually change something via /system/console/configMgr then it
will create an nt:file node corresponding to the PID of the thing
configured under /apps/system/config But -- ideally you shouldn't be
manually configuring things via the Web Console. You should have configs
defined by runmodes See :
It has to do with resolving context-aware configuration stuff. It's
using an underlying service user cloudconfig-scripttags with jcr:read
permissions to read the ScriptTagComponents from all cloud services.
The handles (highlighted in red) will only let you reorder if the
underlying folder is of type sling:OrderedFolder. Folders can be -
sling:folder- nt:folder- sling:OrderedFolder two of those three won't
re-order. much of /content/dam is sling:folders fyi -- so not
reorderable Open a Daycare ticket if you want to pursue this further.
I don't expect you will get an answer here on this public community
forum. The way this post is worded to me can be construed as a potential
social-engineering attack trying to extract account information.
Why step 3? You don't need to restart AEM after installing a
ServicePack. The main thing to be cognizant about for a Publish Service
Pack install is you don't want live web traffic hitting that instance so
a practical approach here is to remove each Publish one-by-one out of
your load balancer and upgrade each individually. Rotating instances in
and out of service while doing it as to not impact your production site.