Open evie-lau opened 2 years ago
Cc @cbridgha @hlhoots @mbroz2
Hi All --
In general the server.env and bootstrap.properties files are user-centric in that they are locations where users can define values related to their individual environments. Specifically, server.env is used to supply user defined environment variables to open liberty and the bootstrap.properties is used to define things (like logging settings or osgi diagnostics) that happen while the server is being started up, but before the server.xml file is read by the startup process. Thus I don't think we would want to document more than what is already documented in various locations. Some well known values that can be pulled from existing documentation that may help with your catalog:
bootstrap.properites: https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-specifying-bootstrap-properties server.env: https://openliberty.io/docs/latest/reference/config/server-configuration-overview.html#server-env
@hlhoots We already used those links among others to gather a list of predefined props/vars and their descriptions. The point is it was a very manual process, and now we have duplicated information in our Liberty Language Server. If that info gets updated in the docs, our duplicated text descriptions will be out of sync and incorrect. @evie-lau was suggesting something that could be consumed in an automated why by multiple tools.
Other links we used:
https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-logging-trace https://www.ibm.com/docs/en/was-liberty/base?topic=logging-configuring-binary-in-liberty https://www.ibm.com/docs/en/was-liberty/base?topic=manually-customizing-liberty-environment
The request here seems reasonable, and I agree we'd want the building of this list to be somehow automated. This would likely need a feature opened in the open-liberty repo and follow the regular feature process. @cbridgha and @NottyCode for their feedback.
The scope of this would probably be outside this project, but it would be very useful here. May have to bubble this up to a higher project. Having a catalog of the properties, values, and descriptions would make it much easier to handle and maintain consistency across tools and documentation.
Some of the places it could be used are: