Hi all, Looking at the `PropertyKey` abstraction in `3.x`, I was wondering what advantages it brings over simple string constants. From my perspective it has more cons than pros.
Pros: * it is typesafe; a committer must create an instance of it to use it; Cons: * it is hard to list for documentation purposes. It would be easier to document all available properties if they were declared as: /** * Makes Foo into bars. */ @Log4jProperty private static final String FOO_BAR = "Foo.bar"; Such a definition can be trivially detected by an annotation processor, whereas currently I would need to call `PropertyKey#getKey` to even find the name of the property. * the split into "component" and "name" isn't really used in real code, so `PropertyKey` is basically a wrapper for a single String, * IMHO the `getSystemKey` method does not belong in `PropertyKey`. It is something that is used only by those property sources that are global in the JVM (like env variables or system properties). Other property sources like `TestPropertySource` have no use of it. * since a `PropertyKey` is not a compile-time constant, we have several `Constant` classes that contain string constants, so that we can use them in tests (e.g. in the `@SetSystemProperty` annotation). If you don't have any objections, I would prefer to refactor all these `PropertyKey` implementations to simple classes that contain only constant string fields. In a **longer** term it would be nice to reintroduce type safety, but for the **values** of properties instead of their keys. We could copy the way Spring does it, create classes like: /** * Configures a https://logging.apache.org/log4j/3.x/recycler.html */ @Log4jPropertySource(prefix = "Recycler") public class RecyclerConfig { /** * Type of recycler. */ public String type; /** * Size of the recyclers queue. */ public int size; } and we could retrieve all the properties at once with `PropertyEnvironment#getProperties(Recycler.class)`. What do you think?
