Fix: Property resolution for extensions within @OpenAPIDefinition Info object
          #3039
        
          
      
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
Fixes #3032
Problem:
Property placeholders (
${...}) were not being resolved within theextensionsattribute of@OpenAPIDefinition'sinfoobject. This was inconsistent, as placeholders in other@Infoattributes, such astitleandversion, were resolving correctly.Example Code:
Actual JSON Output:
{ "info": { "title": "OpenAPI Demo", "version": "v1", "x-created-ts": "${git.build.time}" // Expected: "2024-07-08T12:00:00Z" (resolved value) }, ... }Root Cause:
The root cause of this issue was two-fold, involving problems in both property resolution logic and its invocation:
Incomplete Resolution in
PropertyResolverUtils:The
resolveExtensionsmethod was not designed to resolve simple String values of top-level extension properties. It correctly handled the resolution of extension keys and the key-value pairs within nested maps, but it skipped the crucial step of resolving the extension's primary String value itself.Conditional Logic in
OpenAPIService:The invocation of the property resolution logic for
@OpenAPIDefinition'sinfoextensions was wrapped in a conditional check (propertyResolverUtils.isResolveExtensionsProperties()). This internal property defaults tofalse, which prevented the necessary resolution logic from being triggered in a standard configuration. This created an inconsistency with how other@Infoattributes were handled, as their resolution was not similarly gated.Solution:
This PR addresses both identified issues to ensure consistent and predictable behavior:
PropertyResolverUtils:The
resolveExtensionsmethod has been updated to properly resolve top-level String values within the extensions map. This was achieved by adding a specific check for String instances:OpenAPIService:The conditional check for
isResolveExtensionsProperties()has been removed from theresolveProperties(Info info, ...)method. This ensures that property resolution for extensions is always applied, making the behavior consistent with all other@Infoattributes.