Add streamline Logger #1500
Merged
Add streamline Logger #1500
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mattdailis
force-pushed
the
refactor/streamline-logging
branch
from
1e6fe63 to
a5a577f
Compare
mattdailis
force-pushed
the
refactor/streamline-logging
branch
from
a5a577f to
1ebe02d
Compare
mattdailis
force-pushed
the
refactor/streamline-logging
branch
from
9d57c41 to
b64bb1e
Compare
mattdailis
reviewed
Aug 6, 2024
contrib/src/main/java/gov/nasa/jpl/aerie/contrib/streamline/debugging/Logger.java
Outdated
Show resolved
Hide resolved
mattdailis
reviewed
Aug 6, 2024
contrib/src/main/java/gov/nasa/jpl/aerie/contrib/streamline/modeling/Registrar.java
Outdated
Show resolved
Hide resolved
DavidLegg
force-pushed
the
refactor/streamline-logging
branch
from
53d36cb to
efecb61
Compare
mattdailis
approved these changes
Aug 17, 2024
There was a problem hiding this comment.
Thanks for making this backwards compatible! Looks good to me
EDIT: Resolving conversation below so it doesn't block merge, but copying up here for visibility:
In the event that users have written constraints that depend on the previous resource definition, it may be worth calling out in the release notes [that the errors resources has been replaced with a numberOfErrors resource]. Not a reason not to make this change, but worth communicating explicitly.
contrib/src/main/java/gov/nasa/jpl/aerie/contrib/streamline/modeling/Registrar.java
Show resolved
Hide resolved
|
One slight correction to that note on the |
Adds a Logger class to the streamline framework, which uses topics to emit log messages directly as events. Also builds such a Logger when the Registrar is initialized, and reconfigures errors to go to that logger when the error behavior is set to LOG. Before this, errors were collected awkwardly into a discrete string resource.
Move the primary Logger instance to a separate class, out of Registrar. This makes more sense logically, as Logging only incidentally depends on the Registrar, in the sense that creating the Registrar is a natural place to initialize all of the singletons. It also makes the logger easier to find (I hope).
Per @mattdailis' suggestion, since serialized events are tagged with the time they're emitted already, there's no need to include that information in the log message itself. Further, removing that dependency on the plan start time makes this PR fully backwards-compatible.
dandelany
force-pushed
the
refactor/streamline-logging
branch
from
efecb61 to
f4ddb29
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Adds a Logger class to the streamline framework, which uses topics to emit log messages directly as events. Also builds such a Logger when the Registrar is initialized, and reconfigures errors to go to that logger when the error behavior is set to LOG. Before this, errors were collected awkwardly into a discrete string resource.
Verification
Since the logger is connected to the Registrar's error behavior, this was tested using the streamline-demo example model. By adding "CauseError" activities to the plan, we can trip the resource error handling machinery, and verify that appropriate error messages appear in the Simulation Events tab.
Documentation
None yet - #1494 should probably be updated to tell users how to use the logger in their model/activities.
This does remove the
errorsresource, but it leaves thenumberOfErrorsresource intact, which we should note for any users who may have depended onerrors.Future work
None planned