MappingsEndpoint reports the context's own ID as parentId when a parent exists

[dlwldnjs1009]

MappingsEndpoint sets the parentId of ContextMappingsDescriptor to the context's own ID when a parent exists, rather than the parent's ID:

return new ContextMappingsDescriptor(mappings,
    (applicationContext.getParent() != null) ? applicationContext.getId() : null);

mappings() already keys the response map by target.getId(), so the descriptor's parentId ends up equal to its own map key when a parent is present, which prevents reconstructing the context tree from the response.

The other actuator endpoints with the same parentId field use getParent().getId():

• BeansEndpoint.java:124 — (parent != null) ? parent.getId() : null
• ConfigurationPropertiesReportEndpoint.java:150 — context.getParent().getId()
• ConditionsReportEndpoint.java:124 — context.getParent().getId()

A separate parity observation between the two Dispatcher*MappingDescriptionProvider classes:

• DispatcherServletsMappingDescriptionProvider (webmvc) wraps its static provider list with Collections.unmodifiableList(...).
• DispatcherHandlersMappingDescriptionProvider (webflux) uses Arrays.asList(...), which is fixed-size but mutable via set(i, ...).

I can submit a PR for the parentId fix if this is accepted. Let me know whether to bundle or skip the Arrays.asList alignment.

[wilkinsona]

Thanks for spotting this, @dlwldnjs1009.

I can submit a PR for the parentId fix if this is accepted.

Yes please.

Let me know whether to bundle or skip the Arrays.asList alignment.

Let's skip that for now.