AEM 6.4 upgrade - Cross-boundary resource type usage of internal marked path

[mohanj30558408]

While upgrading to 6.4, we ran Pattern Detector tool and got below lines for ECU category. There are many other similar issues. Any idea how to fix these?

Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/projectteam referenced at /apps/cq/core/content/projects/gadgets/xtrftranslationprojectsummary/jcr:content/content/items/form/items/fixedcolumns/items/column2/items/tabs/items/tab1/items/projectmembers

One more:

Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/wizard/properties/thumbnail referenced at /apps/cq/core/content/projects/wizard/xtrftranslationproject/defaultproject/items/column1/items/cover

[smacdonald2008]

Never seen this myself. Checking with our AEM team.

[smacdonald2008]

Please refer to this doc - ECU

[Gaurav-Behl]

It means that your custom code is using <something> of granite type <something> that may cause an issue. The onus is on the developer to identify and fix it.

E.g.  In this one - your code uses "thumbnail" from /libs path which is classified as  "granite:internal area" now in 6.4 in "cover" node of dialog. You can do the assessment if that may/may not break your code in author. It's not recommended to overlay/override granite:internal area going forward.

Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/wizard/properties/thumbnail referenced at /apps/cq/core/content/projects/wizard/xtrftranslationproject/defaultproject/items/column1 /items/cover

In this example, your project uses "projectteam" code in either overlay/override format which is now classified as "granite:internal" area. Hence, it should be removed/substituted accordingly. It may/may not break your project's code but it's not recommended to overlay/override granite:internal area going forward.

Cross-boundary resource type usage of internal marked path /libs/cq/gui/components/projects/admin/projectteam referenced at /apps/cq/core/content/projects/gadgets/xtrftranslationprojectsummary/jcr:content/content/ items/form/items/fixedcolumns/items/column2/items/tabs/items/tab1/items/projectmembers

HTH

[mohanj30558408]

smacdonald2008​ @gauravb10066713

We have few more in the same ECU category. Is there any reference to fix these?

Cross-boundary resource type usage of internal marked path -

Referenced by:	/apps/kporg/kporg-cms/translation/templates/xtrf/xtrf-servicepage
Referencing:	/libs/cq/cloudserviceconfigs/templates/configpage

Referenced by:	/apps/cq/gui/content/facets/archivedpages
Referencing:	/libs/granite/ui/components/foundation/contsys

Referenced by:	/apps/wcm/core/content/futurereleases/jcr:content/body/content/aside/items/references/items/references/items/list/items/copies/items/languageCopies/items/start/items/trigger/items/form/items/projectType/items/new
Referencing:	/libs/granite/ui/components/foundation/form/option

Referenced by:	/apps/cq/core/content/projects/gadgets/xtrftranslationjobpodlinks/jcr:content/actions/primary/add/granite:rendercondition
Referencing:	/libs/cq/gui/components/projects/admin/translation/renderconditions/addtranslationobjectaccess

Referenced by:	/apps/cq/core/content/projects/gadgets/xtrftranslationjobpodlinks/jcr:content/actions/selection/deleteobject/granite:rendercondition
Referencing:	/libs/cq/gui/components/projects/admin/translation/renderconditions/addtranslationobjectaccess

Referenced by:	/apps/cq/core/content/projects/gadgets/xtrftranslationjobpodlinks/jcr:content/head/viewinasset
Referencing:	/libs/cq/gui/components/projects/admin/actions/view/translationpage

Referenced by:	/apps/cq/core/content/projects/gadgets/xtrftranslationjobpodlinks/jcr:content/head/configurecolumndialog/items/chooseColumns
Referencing:	/libs/cq/gui/components/projects/admin/translation/translationpodcolumnchooser

[Gaurav-Behl · Accepted solution]

I'm not aware of any specific references like that. If all these patterns follow the same warning of "Internal marked path", that means it follows the same pattern.

First level check is to make sure the warning is correct - Open the node mentioned by Referencing: path in /crx/de and check that node structure. You must see an overlay with partial opacity and on the node, you would notice property - jcr:mixing = graniteInternalArea or others as mentioned below.

Then you could check the custom source code to find how is it being used in the code. Figure out, if you really want to overlay/override them then, find an alternative solution to each of these customization.

Go through this link -

Adobe Experience Manager Help | Sustainable Upgrades

• Public (granite:PublicArea) - Defines a node as public so that it can overlaid, inherited (sling:resourceSuperType) or used directly (sling:resourceType). Nodes beneath /libs marked as Public will be safe to upgrade with the addition of a Compatibility Package. In general customers should only leverage nodes marked as Public.
• Abstract (granite:AbstractArea) - Defines a node as abstract. Nodes can be overlaid or inherited (sling:resourceSupertype) but must not be used directly (sling:resourceType).
• Final (granite:FinalArea) - Defines a node as final. Nodes classified as final cannot be overlaid or inherited. Final nodes can be used directly via sling:resourceType. Subnodes under final node are considered internal by default
• Internal (granite:InternalArea) - Defines a node as internal. Nodes classified as internal cannot be overlaid, inherited, or used directly. These nodes are meant only for internal functionality of AEM
• No Annotation - Nodes inherit classification based on the tree hierachy. The / root is by default Public. Nodes with a parent classified as Internal or Final are also to be treated as Internal.

Note:

These policies are only enforced against Sling search path based mechanisms. Other areas of /libs like a client-side library may be marked as Internal, but could still be used with standard clientlib inclusion. It is important that a customer continues to respect the Internal classification in these cases.

[mohanj30558408]

Thanks @gauravb10066713

In one of our component, we have sling:resourceSuperType as granite/ui/components/coral/foundation/table. And when i looked in crx/de for this path /libs/granite/ui/components/coral/foundation/table - there is node jcr:mixinTypes - granite:FinalArea.  so, In this scenario, what could be the possible fix because we need to inherit the OOTB table component.

[Gaurav-Behl]

Per docs, FinalArea should not be overlayed/overridden.

Options available:

1) Could your use case simply use sling:resourceType rather than resourceSuperType like [1]? e.g. Table — Granite UI 1.0 documentation

2) Change this code to use some other API/library (potentially jquery or external table library)

3) Copy and duplicate the bare minimum code (if possible) and work with assumption that each upgrade might break this custom code

4) Raise a ticket with DayCare and ask for recommendations regarding same

[1]

+ mytable

  - sling:resourceType = "granite/ui/components/coral/foundation/table"

  - src = "/a/b/c{.offset,limit}.html{+id}{?sortName,sortDir}"

  - rowReorderAction = "/reorder{?item,before}"

  + columns

  + select

  - select = true

  + col1

  - jcr:title = "Column 1"

  + col2

  - jcr:title = "Column 2"

  + order

  - order = true

  + datasource

  - sling:resourceType = "my/datasource"