feat(langchain4j): implement model provider strategies with capabilit…

[KevinDavilaDotCMS]

• Added new model provider strategies for various AI services (Anthropic, Azure OpenAI, Bedrock, Google AI, OpenAI, OpenRouter, Vertex AI).
• Introduced enum to define supported capabilities (CHAT, EMBEDDINGS, IMAGE).
• Implemented and to manage configuration fields for each provider.
• Created to aggregate provider capabilities and fields for dynamic form rendering.
• Added REST endpoint to expose provider metadata for client consumption.
• Updated OpenAPI documentation to reflect new endpoints and data structures.
• Added unit tests for provider metadata functionality.

This commit enhances the AI provider configuration system, allowing for more flexible and dynamic integration of various AI models.

Proposed Changes

• change 1
• change 2

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

** any additional useful context or info **

Screenshots

Original	Updated
** original screenshot **	** updated screenshot **

[claude]

Claude finished @KevinDavilaDotCMS's task in 2m 32s —— View job

---

Claude Code Review

• Read changed files
• Analyze for bugs, security, conventions
• Post review

I reviewed the full diff against origin/main. This is a clean, well-documented addition. The metadata model, factory aggregation, and REST endpoint all follow dotCMS conventions. Verified specifics:

• Every declared field name (apiKey, model, endpoint, deploymentName, apiVersion, dimensions, size, region, accessKeyId, secretAccessKey, embeddingInputType, projectId, location, credentialsJson, maxRetries, timeout, temperature, maxTokens) matches an actual accessor on ProviderConfig, so the metadata contract is accurate.
• Credential fields are correctly typed SECRET, and @Value.Redacted fields line up with them.
• supportedCapabilities() and the configFields() switch are aligned for all 7 providers, so toMetadata() never triggers an UnsupportedOperationException at runtime; test_listProviderMetadata_fieldsKeyedOnlyBySupportedCapabilities guards this against future drift.
• AiProviderResource is auto-registered via the com.dotcms.ai.rest package scan in DotRestApplication, and @Path("/") on the method matches the sibling EmbeddingsResource convention.
• requiredBackendUser(true) is the right guard — the payload is static, non-sensitive metadata (field names only, no values).
• openapi.yaml reflects the new endpoint/schemas and appears generated (path /v1/ai/providers, correct $refs).

New Issues

• 🟡 Medium: dotCMS/src/test/java/com/dotcms/ai/client/langchain4j/ProviderMetadataTest.java — The class javadoc correctly notes the declarative metadata "restates knowledge already enforced imperatively" with nothing keeping them in sync, and assertMissingRequiredFieldBreaksChatBuild cross-checks required fields — but only for CHAT. Required-field declarations for EMBEDDINGS and IMAGE (e.g. Azure/Bedrock/Google embeddings apiKey/endpoint/region) are never cross-checked against actual build validation, so those can silently drift. Non-blocking; the shared required fields overlap CHAT, but a dedicated embeddings/image check would close the gap. Fix this →
• 🟡 Medium: dotCMS/src/main/java/com/dotcms/ai/client/langchain4j/ProviderField.java:19 / ProviderMetadata.java:26 — The compact-constructor validation (blank name, null type, null provider) has no test coverage. Cheap to add and locks in the invariant these records advertise.

No blocking issues found.

· 36826-dotai-provider-configuration-ui