Solved

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

Forum|Forum|6 years ago
January 28, 2019
7 replies
4332 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by Gaurav-Behl

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.

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

M

mohanj30558408Author

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-BehlAccepted 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.

M

mohanj30558408Author

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"

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded