-
Notifications
You must be signed in to change notification settings - Fork 686
Description
Description
I can repeatedly recreate situations in which Epilogue doesn't log classes marked as @Logged.
Epilogue seems to rely too heavily on the hierarchical structure of classes in a robot project. If an instance of a class that isn't marked as @Logged contains an instance of a class that is marked as @Logged, then the logged class is not logged. This is really inconvenient, confusing, and unexpected behavior. This also applies across multiple "levels"; that is, to log any one class, all the classes "above" it need to also be marked as @Logged.
- Link to code: this is an example codebase I made to demonstrate the problem. This is literally just the steps listed above. Check out the other branches to see other examples that relate to this topic.
To Reproduce
Steps to reproduce the behavior:
- From a basic command-based project, add the
@Loggedannotation to theRobotclass - Create a new class,
SomeLoggedClass, marked as@Logged, with some field/methods declared in it. Basically, this is any class that needs to log something. - Assign an instance of this
SomeLoggedClassto a field inRobotContainer. - Done! Even though the
SomeLoggedClassclass is being created, and is marked as@Logged, nothing in it gets logged/recorded when the robot program runs. - If you add the
@Loggedannotation toRobotContainer, the classSomeLoggedClassbegins to log itself, too. This completes the "hierarchy" of@Loggedclasses that seems to be necessary for Epilogue to work.
Note that the above is the best-case scenario; in the real world, there's rarely just one class between a logged class and a robot, and it turns out that every class between the two needs to be @Logged: if you replace the @Logged SomeLoggedClass with a SomeNotLoggedClass that is not @Logged, and this SomeNotLoggedClass has a member variable that is an instance of SomeLoggedClass, both RobotContainer and SomeNotLoggedClass need to be marked as @Logged in order to log the SomeLoggedClass class.
This means that some classes are completely impossible to log! Consider a singleton class. I know you can't log static fields, but you should still be able to log regular fields on the one instance of the singleton! But because there's no @Logged class which is marked as @Logged and contains an instance of the singleton class (because that's not really how singletons should work), the singleton can't be logged (Adding @Logged to the singleton class itself doesn't work)! It's almost like Epilogue starts at Robot and looks for any fields/accessors which it can log (i.e. the type is marked @Loggable) and then looks at those classes, stopping whenever it finds a class that isn't @Logged, thus ignoring many classes that should be logged.
Expected behavior
Epilogue's docs say:
The
@Loggedannotation, when placed on a class, tells the Java compiler to run WPILib’s code generator to write custom logging code that will log everything it can in your class
This would imply that any class that is marked as @Logged would be a logged class. However, this is definitely not the case. If I want a class to be logged, I do not feel like I should have to add the @Logged annotation to the class that holds an instance of this class, and all the way up until I reach Robot.java—that just seems strange.
I don't know exactly what I'd expect for a class that's not a field of any other class (like a singleton), but I know I didn't expect nothing. I understand that this one is significantly trickier (under what name would you name that class in the log), but I would at least appreciate a note in the documentation saying "Epilogue doesn't know how to handle an object that's not a field of another class". Just saying "Add @Logged to your class and it'll log all the member fields" is too general because it doesn't actually reflect how Epilogue seems to decide what to log.
The documentation also should do a better job of illustrating this necessary "chain" of @Logged annotations that seems to be necessary to log a single class. Each class that wants to be logged appears to have to be a field in an instance of a class that is logged, and that object needs to be a field in another class (which again must be logged), leading all the way back to Robot.
Additional Details
Desktop:
- OS: MacOS Sequoia 15.7.3
- Project Information:
WPILib Information:
Project Version: 2026.2.1
VS Code Version: 1.105.1
WPILib Extension Version: 2026.2.1
Project Year: 2026
Language: java
C++ Extension Version: 1.28.3
Java Extension Version: 1.38.0
Java Debug Extension Version: 0.58.2
Java Dependencies Extension Version 0.24.1
Java Version: 17
Java Location: /Users/rekrab/wpilib/2026/jdk
Vendor Libraries:
WPILib-New-Commands (1.0.0)
It is noteworthy that Epilogue does actually generate the *Logger files in the build/generated/sources/annotationProcessor/main/frc/robot/ directory, but they simply don't seem to be used.