Make BeanOutputConverter more extensible

[markpollack]

Summary

• Makes BeanOutputConverter class more subclass-friendly by changing access modifiers for key fields and methods
• Extracts template string in getFormat() to allow customization by subclasses
• Provides better extension points for customizing behavior

Fixes #1985

[ThomasVitale]

@markpollack since BeanOutputConverter implements StructuredOutputConverter, would it be enough to create a custom StructuredOutputConverter implementation if a different logic is desired?

I can already define a MyBeanOutputConverter which implements StructuredOutputConverter and define my custom logic for the schema generation. Actually, that's what I do in my projects. I implemented my own version, and re-used the JsonSchemaGenerator class for generating the schema, which is the same logic used for tool calling. I didn't experience limitations in terms of extensibility.

I'm afraid that by opening up methods and fields in BeanOutputConverter, it will be more difficult to evolve the structured output support due to backward compatibility. We had a similar issue in the old FunctionCallback implementations, which exposed methods to customise schemas and ObjectMapper, and that made it difficult to change the internal implementation since all the internal methods were protected, leaking internal implementation details and preventing from changing the implementation. In that case, we solved it by introducing a different API (ToolCallback), but here it would be more challenging.

I would tend to suggest evolving BeanOutputConverter to be a final class. Customizations would still be possible either via a delegate pattern or by introducing a custom implementation.

What do you think?

[xak2000]

It would be great to actually make JsonSchemaGenerator customizable.

E.g. currently there is no way to modify the options list of JacksonModule that I needed to enable FLATTENED_ENUMS_FROM_JSONVALUE and FLATTENED_ENUMS_FROM_JSONPROPERTY options.

For these specific 2 options I think they should be enabled by default, but it would be still very good to have ability to customize.

Of course it is always possible to just write and use custom schema generator, but it is quite a lot of error-prone code, so an out-of-the-box configurability would be much appreciated.