[
https://issues.apache.org/jira/browse/IGNITE-28661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Valuyskiy updated IGNITE-28661:
------------------------------------
Description:
Currently Apache Ignite uses the *ignite.properties* classpath resource to
store internal build metadata such as:
* product version (ignite.version)
* build number (ignite.build)
* revision (ignite.revision)
* release date (ignite.rel.date)
* update notifier parameters
However, the current name *ignite.properties* is misleading because it looks
like a regular user configuration file. This creates two problems:
*1. Misleading semantics*
Users may attempt to store custom application properties there.
*2. Accidental classpath resource collision*
A user may independently create their own application configuration file named
*ignite.properties* and place it in the application classpath, without knowing
that Apache Ignite already uses a resource with the same name. In such cases,
the user resource may accidentally override Ignite’s internal
{*}ignite.properties{*}, leading to unexpected runtime issues.
Reproducer: [^IgniteBuildInfoPropertiesTest.patch]
To reduce confusion and avoid accidental resource overriding, the internal
resource should be renamed to something that clearly reflects its purpose, for
example {*}ignite-build-info.properties{*}.
was:
Currently Apache Ignite uses the *ignite.properties* classpath resource to
store internal build metadata such as:
* product version (ignite.version)
* build number (ignite.build)
* revision (ignite.revision)
* release date (ignite.rel.date)
* update notifier parameters
However, the current name *ignite.properties* is misleading because it looks
like a regular user configuration file. This creates two problems:
*1. Misleading semantics*
Users may attempt to store custom application properties there.
*2. Accidental classpath resource collision*
A user may independently create their own application configuration file named
*ignite.properties* and place it in the application classpath, without knowing
that Apache Ignite already uses a resource with the same name. In such cases,
the user resource may accidentally override Ignite’s internal
{*}ignite.properties{*}, leading to unexpected runtime issues.
To reduce confusion and avoid accidental resource overriding, the internal
resource should be renamed to something that clearly reflects its purpose, for
example {*}ignite-build-info.properties{*}.
> Rename ignite.properties build metadata resource to avoid confusion with user
> configuration
> -------------------------------------------------------------------------------------------
>
> Key: IGNITE-28661
> URL: https://issues.apache.org/jira/browse/IGNITE-28661
> Project: Ignite
> Issue Type: Task
> Reporter: Oleg Valuyskiy
> Assignee: Oleg Valuyskiy
> Priority: Minor
> Labels: ise
> Attachments: IgniteBuildInfoPropertiesTest.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently Apache Ignite uses the *ignite.properties* classpath resource to
> store internal build metadata such as:
> * product version (ignite.version)
> * build number (ignite.build)
> * revision (ignite.revision)
> * release date (ignite.rel.date)
> * update notifier parameters
> However, the current name *ignite.properties* is misleading because it looks
> like a regular user configuration file. This creates two problems:
> *1. Misleading semantics*
> Users may attempt to store custom application properties there.
> *2. Accidental classpath resource collision*
> A user may independently create their own application configuration file
> named *ignite.properties* and place it in the application classpath, without
> knowing that Apache Ignite already uses a resource with the same name. In
> such cases, the user resource may accidentally override Ignite’s internal
> {*}ignite.properties{*}, leading to unexpected runtime issues.
> Reproducer: [^IgniteBuildInfoPropertiesTest.patch]
> To reduce confusion and avoid accidental resource overriding, the internal
> resource should be renamed to something that clearly reflects its purpose,
> for example {*}ignite-build-info.properties{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
