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:
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
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.
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
it picks up the config with no problem.
That all being said, I guess I have 2 questions:
Is there a way to get this to work when using the /apps/myapp/osgiconfig/config structure?
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!
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
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.