This solution didnt work for us, because we have so many servlets,
maintained by different teams, returning responses in hundreds of places
in different ways. AEM forces you to choose between UTF-8 or
application/json, you can't have both (without a significant rewrite of
the code and very large cost of retesting every aspect). I would say
that the "side effect" of setting UTF-8 causing the response type to
change to text is a pretty serious bug.
OK, we have got a step further. In the Author AEM instance web control
panel, there is indeed The option to "create dynamic media
configuration" under Hammer->Cloud Services.Creating a configuration you
have to chose:1) title: dev-test2) email: my adobe email3) password: my
adobe password4) region: europe. Then it just says "connection failed"
We are using the cloud AEM, and have several sites using the built in
DAM for assets.We have also purchased Adobe Dynamic media, and we can
see it listed in our https://adminconsole.adobe.com/as one of our
products. However, there seems to be no control panel for it, no way to
login or activate it, no way to use it. The settings for it in
adminconsole are just name and description. Any suggestions? This
article says to activate scene7 you have to edit the java settings, but
this is obviously not...
AEM build time is a signficant problem,as it takes 1-2 hours for each of
our 5 envs, and you cant deploy a built artifiact from one end (e.g.
dev) into another (e.g. test). We have always done a full stack build,
but I notice there is a front end build only. As AEM has front end
(react etc) and backend (java, osgi files etc) in one repo, how does the
bild process know if it should built font end only, or full stack?
Presumably its unsafe to do FE, in case someone changed something in the
When we want to add some redirects, the process takes several weeks and
costs tens if not hundreds of thousands of pounds. This is because we
have to update the dispatcher configs in our project, build it several
times on dev (which takes on average 1.5 hours each build) to test it,
then schedule the change to go into test env, then UAT env, then stage,
then prod, each time doing a 1-2 hour build, and several rounds of smoke
tests (as there is no way to ensure that what was build in one env is
We create the content on production, then sync the content down to UAT /
test / dev cloud AEM envs. The problem is that its easy to miss items
(such as policies), or take too much (and cause issues). We tried the
as /conf/ourweb contains several important dirs, including templates,
template types and policies. However, when we try to deploy the above
package to another of our envs, we get: "Package ...
yes, we have tried just join, same error unfortunately. The issue is
that join does not exist, our page is called register.html. There is no
point in vanity url if it has to be identical to the url its being a
vanity url for. The url the browser uses for our site is
oursite.com/uk/en/register.html. We have dispatcher rules to rewrite
this under the hood to /content/our-web/oursite_com/uk/en/register.html.
Vanity URLs dont work at all. They not only dont rewrite to the actual
All commands give this error, e.g: % aio cloudmanager:list-environments
› Error: 400 (Bad Request) % npm -version7.6.0% node Welcome to Node.js
v15.10.0.% aio -v @adobe/aio-cli/8.2.0 darwin-arm64 node-v15.10.0 how to
reproduce:1) install aio2) install cloud manager2) login3) run any
(core) aio command (works)4) run any aio cloudmanager command (fails
with bad request) Installed via this method:npm install -g
@adobe/aio-cliaio plugins:install @adobe/aio-cli-plugin-cloudmanageraio