HTML Transformer With AEM As A Cloud Service

[evancooperman-r]

Hi everyone,

I'm new to AEM as a Cloud Service so bear with me here.  I've been working with AEM since the CQ 4.1 days, but it's unclear to me how some of the decisions being made will impact the things I'm used to be able to do.

The gist is that I'm trying to get an HTML transformer to work so that I can leverage it to properly rewrite Experience Fragment links into their appropriate country/language.  Currently, the links in our XFs always reference back to language-masters/en where they were created, and when we roll out the links are not updated.  We are intending to use XFs for our header and footer, so it's very important that all the links within our XFs are actually rewritten properly as we're going to have a boatload of different country/language combinations.

In order to do this, I tried registering a new Transformer via OSGi.  In the past, this was always done by creating a rewriter folder under our config node, and then putting a configuration under there which specified what the new pipelines are.  For example, something like this:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
    jcr:primaryType="nt:unstructured"
    enabled="{Boolean}true" 
    generatorType="htmlparser"
    transformerTypes="[referencelinkrewriter,linkchecker]"
    serializerType="htmlwriter" 
    order="100"
    contentTypes="[text/html]"
    resourceTypes="[myapp/components/page]"
    paths="[/content/myapp]">
    <generator-htmlparser
        jcr:primaryType="nt:unstructured"
        includeTags="[A,/A,IMG,/IMG,AREA,FORM,BASE,LINK,BODY,/BODY,IFRAME,/IFRAME,INPUT,/INPUT,SCRIPT,DIV,/DIV]" />
</jcr:root>

After doing this, the new rewriter should be registered as a sling rewriter (which can be seen by looking at http://localhost:4502/system/console/status-slingrewriter for the new entry).  While this works in the situation described above, there is now an additional level added to the OSGi config folders.  So where before, the structure was

/apps/myapp/config/rewriter/referencelinkrewriter

it's now

/apps/myapp/osgiconfig/config/rewriter/referencelinkrewriter

With this additional osgiconfig node added, it will no longer pick up my config and register the rewriter.  I've tried a number of things to try and get it to pick up, but it feels like it's expecting there to be EXACTLY 4 levels in the structure for some reason.  I know ACS Commons versioned clientlibs also might not work with this from what I've read, I'm guessing for a similar reason. 

I also tried the following path:

/apps/myapp/osgiconfig/config/referencelinkrewriter

as well, but I believe the node needs to be called rewriter, with the config under it.  To confirm, I tried adding the standard folder to my filter and used it the way I have in the past, and had no issues.  So, when the structure is

/apps/myapp/config/rewriter/referencelinkrewriter

it picks up the config with no problem.

That all being said, I guess I have 2 questions:

1. Is there a way to get this to work when using the /apps/myapp/osgiconfig/config structure?
2. If not, does AEMAACS require me to put all OSGi configs in the osgiconfig folder?  In other words, if I move the folder back up a level and get rid of the osgiconfig folder, will that cause me issues when attempting to deploy to the cloud?

Surely there's a way to deal with this without breaking cloud deployments?  Please help!

[Pawan-Gupta]

Hello,

just want to share my thoughts here as i searched about osgiconfig node just for curiosity and found this https://github.com/AdobeDocs/experience-manager-cloud-service.en/blob/master/help/implementing/devel... where in document they talk about /config as well as /osgiconfig both. 

so i am sure, they will also support /config because /config you can cross check under /libs/*/config area if it exist there and same we extend under /apps (until unless /libs/*/config configuration also changed)

Now, if this is latest change then it should support ../osgiconfig/config as well if not, then plz reach adobe for same

also, did you try /apps/myapp/osgiconfig/rewriter/referencelinkrewriter as per above documentation this is valid.

hope it helps!!

[evancooperman-r]

Thanks for the quick response, but yes I've tried /apps/myapp/osgiconfig/rewriter/referencelinkrewriter and it didn't work (that part is in my post). It works for normal OSGi configs but not for rewriters for some reason, I think there might be something coded in to check 4 levels deep but I haven't dug into the source code to determine for sure.

[Vijayalakshmi_S · Accepted solution]

Hi @evancooperman-r,

"osgiconfig" additional folder is an Organizational folder for holding all OSGI config definitions and is to be part of ui.config package/project structure as mentioned here - https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/aem...

On the other hand, Apache Sling Rewriter is not a OSGI config but the configuration is available/created with path say, /level1/leve2/config/rewriter/customrewriter - 4 levels with config preceded by folder structure config/rewriter where level1 and level2 can be anything. (As evident from available OOTB Apache Sling Rewriter Configuration in http://localhost:4502/system/console/status-slingrewriter - "Resource Path" in each configuration entry)

Note : Cross verify the available OOTB rewriter configuration from the above path in Cloud Service SDK instance.

Given this, you can have

• Sling Rewriter config in the path - /apps/myapp/config/rewriter/referencelinkrewriter and this filter be part of ui.apps package (per the below highlighted note)
• OSGI config for your project, myapp can then reside under /apps/myapp/osgiconfig/config, /apps/myapp/osgiconfig/config.<author|publish>.<dev|stage|prod> and be part of ui.config package

[evancooperman-r]

Hi there, I understand all of this but I guess the name of the module is confusing. It's called ui.config and not ui.osgiconfig, which seems like it ought to be for all configs. I'm not sure whether Adobe's recommended approach would be to separate out OSGi configs from other configs, but it seems like it would make more sense to just have the rewriter configs in the ui.config module. All of that being said, there have been some thing that Adobe has done which don't play well in the cloud, so while I figured I could probably create the standard config directory used for rewriters, I don't have a cloud instance provisioned yet and so I can't actually test whether deployments work. Thanks for your comments, for now I'll just add the config folder I need and test it as soon as our environment is provisioned.