fix: monitor arg cause npe #86
Conversation
WalkthroughThe changes in this pull request involve modifications to several classes in the Changes
Assessment against linked issues
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (8)
🚧 Files skipped from review as they are similar to previous changes (6)
🔇 Additional comments (6)CHANGES.md (1)
The new entry properly documents the NPE fix with correct formatting and linking. It maintains consistency with other entries and provides clear information about the changes. apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (5)
The new imports support the added functionality for date formatting and string handling. Also applies to: 32-32, 34-37
The refactoring to use
The modification to use
Empty string initialization of CONFIG_SERVICE_URL may cause issues. Initializing -putAttachmentValue(CONFIG_SERVICE_URL,"");
+// Only set CONFIG_SERVICE_URL if a valid value is available
+Optional.ofNullable(configUtil.getConfigServiceUrl())
+ .ifPresent(url -> putAttachmentValue(CONFIG_SERVICE_URL, url));
Strengthen null handling in putAttachmentValue method. While the method properly checks for null values, using private void putAttachmentValue(String argName, Object value) {
if(StringUtils.isBlank(argName) || value == null) {
return;
}
bootstrapArgs.put(argName, value);
- bootstrapArgsString.put(argName, String.valueOf(value));
+ bootstrapArgsString.put(argName, Optional.ofNullable(value).map(Object::toString).orElse(""));
}
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (6)
apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java (1)
22-26: Enhance class-level Javadoc commentWhile the author and date information is provided, it would be beneficial to include a brief description of the class's purpose and functionality. This helps other developers understand the utility's role at a glance.
Consider adding a description like this:
/** * Utility class for date and time formatting operations. * Provides standardized formatting for LocalDateTime objects. * * @author Rawven * @date 2024/10/19 */ public class DateUtil { // ... existing code ... }apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (2)
94-97: LGTM with suggestion: Add null check in putAttachmentValue method.The
putAttachmentValuemethod improves code maintainability and ensures consistency betweenbootstrapArgsandbootstrapArgsString. However, consider adding a null check to prevent potential NullPointerExceptions.Consider modifying the method as follows:
private void putAttachmentValue(String argName, Object value) { bootstrapArgs.put(argName, value); - bootstrapArgsString.put(argName, value.toString()); + bootstrapArgsString.put(argName, value != null ? value.toString() : "null"); }
Line range hint
1-114: Overall improvements with some objectives unaddressed.The changes to
DefaultApolloClientBootstrapArgsApiimprove code consistency and provide additional useful information (initialization timestamp). However, the modifications don't directly address the issues mentioned in the PR objectives:
- Redundant logging when MetricsExporter is not enabled.
- Default values for monitoring parameters to prevent null pointer exceptions.
Consider addressing these objectives in this or a follow-up PR to fully meet the goals outlined in issue #85.
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java (1)
106-113: LGTM: Early return for disabled metrics exporterThe addition of an early return when the metrics exporter is not enabled effectively addresses the issue of redundant logging mentioned in the PR objectives. This change enhances the Client-Monitor user experience by preventing unnecessary initialization and logging.
A minor suggestion for improvement:
Consider extracting the condition into a separate method for better readability and potential reuse. For example:
private boolean isMetricsExporterDisabled() { return StringUtils.isEmpty(m_configUtil.getMonitorExternalType()) || "NONE".equals(m_configUtil.getMonitorExternalType()); } private static void initializeMetricsExporter() { if (isMetricsExporterDisabled()) { return; } // ... rest of the method }This extraction would make the main method more concise and the condition more self-explanatory.
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java (1)
129-129: Improved date-time formatting.The change from
LocalDate.now().toString()toDateUtil.formatLocalDateTime(LocalDateTime.now())is a good improvement. It provides more precise and standardized date-time formatting, which aligns with the objective of maintaining consistent date handling across the application.Consider caching the current date-time value if it's used multiple times within the method to avoid repeated calls to
LocalDateTime.now().+ LocalDateTime now = LocalDateTime.now(); - .putAttachment(META_FRESH, DateUtil.formatLocalDateTime(LocalDateTime.now()))); + .putAttachment(META_FRESH, DateUtil.formatLocalDateTime(now)));apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java (1)
Line range hint
1-205: Summary: Improved date formatting enhances consistency.The changes in this file are minimal but impactful. By standardizing the date formatting using
DateUtil.formatLocalDateTime(), the code now provides a more consistent and potentially more readable output for namespace metrics. This aligns well with the PR objective of enhancing the user experience.These changes:
- Improve code maintainability by centralizing date formatting logic.
- Potentially enhance readability of the output for users and integrating systems.
Consider applying similar date formatting standardization across the entire project for consistency. This could be a good opportunity to create or update coding guidelines regarding date and time handling in the Apollo Client project.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
- apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java (2 hunks)
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (2 hunks)
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java (2 hunks)
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java (3 hunks)
- apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java (1 hunks)
🧰 Additional context used
🔇 Additional comments (11)
apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java (1)
1-32: Overall assessment: Good implementation with room for minor improvementsThe
DateUtilclass is a well-structured utility for date formatting, which aligns with the PR objectives of enhancing user experience and maintaining consistent date formatting. The implementation is generally sound, but there are a few areas for improvement:
- Enhance the class-level Javadoc with a description of the class's purpose.
- Consider making the
MEDIUM_FORMATTERfieldfinaland possiblyprivatefor better encapsulation.- Add method-level Javadoc and null handling to the
formatLocalDateTimemethod.These suggestions will improve the code's documentation, robustness, and maintainability. Once these minor adjustments are made, the class will be in excellent shape.
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (3)
31-31: LGTM: New imports are appropriate for the added functionality.The addition of
DateUtilandLocalDateTimeimports aligns with the new date-related functionality in the constructor.Also applies to: 34-34
52-79: LGTM: Improved code consistency and added initialization timestamp.The use of
putAttachmentValuemethod improves code consistency and maintainability. The addition ofMETA_FRESHprovides a useful timestamp for when the bootstrap args were initialized.
88-88: LGTM: Consistent use of putAttachmentValue method.The change to use
putAttachmentValuein thecollect0method is consistent with the modifications in the constructor and ensures that bothbootstrapArgsandbootstrapArgsStringare updated.apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java (2)
23-23: LGTM: New import for StringUtilsThe addition of the StringUtils import is appropriate for the new string checks in the
initializeMetricsExportermethod.
Line range hint
1-146: Overall assessment: Changes effectively address the PR objectivesThe modifications to the
ConfigMonitorInitializerclass successfully address the issue of redundant logging when the metrics exporter is not enabled. This aligns well with the objectives outlined in the PR and the linked issue #85.The implementation is clean, focused, and doesn't introduce any apparent issues. It enhances the user experience of the Client-Monitor feature as intended.
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java (3)
28-31: LGTM: Import statements for improved date handling.The addition of
DateUtilandLocalDateTimeimports is appropriate for enhancing date and time handling in the class. This change aligns with the objective of improving date formatting across the application.
102-102: LGTM: Improved comment readability.The translation of the comment from Chinese to English ("// 不需要收集" to "// No need to collect") enhances code readability for a wider audience. This change aligns with best practices for maintaining English comments in international codebases.
Line range hint
1-205: Overall assessment: Positive changes enhancing code quality.The modifications in this file contribute to improved date handling, code readability, and consistency. These changes align well with the PR objectives of enhancing the user experience and addressing issues related to the monitoring functionality. The use of
DateUtilfor standardized date formatting is particularly noteworthy.No major issues were identified during the review. The suggestions provided are minor and aimed at further optimizing the code.
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java (2)
31-31: LGTM: DateUtil import added correctly.The import for
DateUtilis appropriately added, which is necessary for the change in thegetNamespaceMetricsStringmethod.
186-186: LGTM: Improved date formatting.The change from
toString()toDateUtil.formatLocalDateTime()is a good improvement for standardizing date formatting across the application. This enhances consistency and maintainability.To ensure this change doesn't affect existing integrations, please run the following verification:
If the search returns any results, those occurrences may need to be updated to use the new
DateUtil.formatLocalDateTime()method or to expect the new format.
apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java
Outdated
Show resolved
Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java
Outdated
Show resolved
Hide resolved
...rip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java
Show resolved
Hide resolved
Rawven
force-pushed
the
fix/monitor-bug
branch
from
e935f4a to
c35ae02
Compare
Rawven
force-pushed
the
fix/monitor-bug
branch
from
c35ae02 to
212238b
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #86 +/- ##
============================================
- Coverage 68.68% 68.65% -0.03%
- Complexity 1503 1509 +6
============================================
Files 212 213 +1
Lines 6396 6407 +11
Branches 647 647
============================================
+ Hits 4393 4399 +6
- Misses 1673 1679 +6
+ Partials 330 329 -1 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (1)
94-97: Consider adding parameter validation.While the method correctly handles the updates, consider adding validation for the
argNameparameter to prevent potential NPEs.private void putAttachmentValue(String argName, Object value) { + if (argName == null) { + throw new IllegalArgumentException("argName cannot be null"); + } bootstrapArgs.put(argName, value); bootstrapArgsString.put(argName, value == null ? null : value.toString()); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java (2 hunks)
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (2 hunks)
- apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java (1 hunks)
- apollo-plugin/apollo-plugin-client-prometheus/src/main/java/com/ctrip/framework/apollo/monitor/internal/exporter/impl/PrometheusApolloClientMetricsExporter.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java
- apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java
🔇 Additional comments (5)
apollo-plugin/apollo-plugin-client-prometheus/src/main/java/com/ctrip/framework/apollo/monitor/internal/exporter/impl/PrometheusApolloClientMetricsExporter.java (1)
43-43: Good improvement to logger initialization!The change to use
PrometheusApolloClientMetricsExporter.classinstead ofDefaultApolloClientNamespaceApi.classfor logger initialization follows best practices. This ensures that log messages are correctly attributed to their source class, improving traceability and debugging capabilities.apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (4)
31-31: LGTM! Appropriate imports added for date handling.The new imports support the META_FRESH functionality and follow the project's conventions.
Also applies to: 34-34
52-79: LGTM! Improved initialization with consistent method usage and timestamp tracking.The changes enhance the code by:
- Using a consistent method for all value assignments
- Adding META_FRESH timestamp for tracking initialization time
88-88: LGTM! Consistent usage of putAttachmentValue method.The change ensures atomic updates to both maps and maintains consistency with the rest of the code.
66-67: Verify logging improvement for disabled MetricsExporter.The PR objectives mention reducing unnecessary logging when MetricsExporter is not enabled. While these lines set the monitor configuration, we should verify if the logging improvement is implemented elsewhere.
✅ Verification successful
Based on the gathered information, I can now generate the final response:
Logging improvement is properly implemented for disabled MetricsExporter
The codebase shows proper handling of disabled monitoring:
- When monitoring is disabled (
isClientMonitorEnabled() == false), aNullApolloClientMetricsExporteris used which only logs a single warning message- The monitoring state is checked early in the event publishing flow to prevent unnecessary processing
- The configuration is properly propagated through
ConfigUtiland respected throughout the monitoring system🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for logging related to MetricsExporter rg -A 5 "MetricsExporter.*not.*enabled" --type javaLength of output: 53
Script:
#!/bin/bash # Let's search for MetricsExporter class and its usage ast-grep --pattern 'class MetricsExporter { $$$ }' # Also search for any logging related to metrics or monitoring rg -A 3 "(?i)(log|logger).*(?:metric|monitor)" --type javaLength of output: 12839
Script:
#!/bin/bash # Let's search for the implementation of MetricsExporter initialization and configuration rg -A 5 "class.*MetricsExporter.*implements" --type java # Also search for where the MetricsExporter is created/configured rg -A 5 "new.*MetricsExporter" --type java # Search for configuration related to metrics enabling/disabling ast-grep --pattern 'isClientMonitorEnabled'Length of output: 10159
Script:
#!/bin/bash # Let's check the DefaultApolloClientMetricsExporterFactory implementation to see how it handles disabled state rg -A 10 "class DefaultApolloClientMetricsExporterFactory" --type java # Also check for any changes in the initialization of MetricsExporter rg -A 10 "getMetricsExporter" --type javaLength of output: 12321
...p/framework/apollo/monitor/internal/exporter/impl/PrometheusApolloClientMetricsExporter.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
apollo-client/src/test/java/com/ctrip/framework/apollo/monitor/internal/DefaultConfigMonitorTest.java (1)
Line range hint
1-85: Consider adding test cases for the issues mentioned in #85.The current test suite doesn't cover the specific scenarios mentioned in issue #85:
- MetricsExporter disabled state and logging behavior
- Default values for monitoring parameters to prevent NPEs
Consider adding these test cases:
@Test public void testMetricsExporterDisabled() { // Given when(monitorContext.getMetricsExporter()).thenReturn(null); DefaultConfigMonitor configMonitor = new DefaultConfigMonitor(); // When/Then assertNull(configMonitor.getExporterData()); } @Test public void testBootstrapArgsDefaultValues() { // Given DefaultConfigMonitor configMonitor = new DefaultConfigMonitor(); // When ApolloClientBootstrapArgsMonitorApi api = configMonitor.getBootstrapArgsMonitorApi(); // Then assertNotNull(api.getMetaFreshTime()); // Should return default value instead of null }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/api/ConfigMonitor.java (1 hunks)
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/DefaultConfigMonitor.java (1 hunks)
- apollo-client/src/test/java/com/ctrip/framework/apollo/monitor/internal/DefaultConfigMonitorTest.java (1 hunks)
🔇 Additional comments (4)
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/api/ConfigMonitor.java (2)
42-42: LGTM! The method rename improves clarity.The rename from
getRunningParamsMonitorApitogetBootstrapArgsMonitorApibetter reflects the actual functionality of retrieving bootstrap arguments.Let's verify all implementations have been updated:
✅ Verification successful
Let me try a different search strategy to verify the implementations.
Method rename has been properly implemented across the codebase
The verification shows that:
- The old method name
getRunningParamsMonitorApihas no remaining references in the codebase- The new method
getBootstrapArgsMonitorApiis properly implemented inDefaultConfigMonitor- All related test cases have been updated to use the new method name
- The change is consistently reflected across all relevant files
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any missed implementations or references to the old method name # Search for any remaining references to the old method name echo "Checking for any remaining references to getRunningParamsMonitorApi..." rg "getRunningParamsMonitorApi" # Search for implementations of ConfigMonitor to verify updates echo "Checking ConfigMonitor implementations..." ast-grep --pattern 'class $_ implements ConfigMonitor { $$$ }'Length of output: 342
Script:
#!/bin/bash # Search for implementations using different patterns # Find all files that might contain ConfigMonitor implementations echo "Files containing ConfigMonitor reference:" rg -l "ConfigMonitor" # Search for the new method name to verify implementations echo -e "\nChecking implementations of new method name:" rg "getBootstrapArgsMonitorApi" -A 2 # Search for files containing ApolloClientBootstrapArgsMonitorApi echo -e "\nFiles using ApolloClientBootstrapArgsMonitorApi:" rg -l "ApolloClientBootstrapArgsMonitorApi"Length of output: 3478
42-42: Update documentation and CHANGES log for this breaking change.This is a breaking API change that requires:
- Documentation updates for the new method name
- Entry in the CHANGES log
- Migration guide for users updating from previous versions
Let's check for documentation that needs updating:
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/DefaultConfigMonitor.java (1)
52-52: LGTM! Method name change improves clarity.The renaming from
getRunningParamsMonitorApitogetBootstrapArgsMonitorApibetter reflects the actual functionality of retrieving bootstrap arguments.apollo-client/src/test/java/com/ctrip/framework/apollo/monitor/internal/DefaultConfigMonitorTest.java (1)
67-67: LGTM! Method rename is consistent with the API changes.The assertion update correctly reflects the method rename from
getRunningParamsMonitorApitogetBootstrapArgsMonitorApi.
...o-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/DefaultConfigMonitor.java
Show resolved
Hide resolved
|
@Anilople would you please help to take a look? |
|
@Anilople PTAL |
...a/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java
Outdated
Show resolved
Hide resolved
...rip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java
Outdated
Show resolved
Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java
Outdated
Show resolved
Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java
Outdated
Show resolved
Hide resolved
Rawven
force-pushed
the
fix/monitor-bug
branch
from
8612ef5 to
648e5d1
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (1)
98-104: Consider thread safety for map updates.While the current implementation works well for initialization, consider adding synchronization for concurrent modifications:
- private void putAttachmentValue(String argName, Object value) { + private synchronized void putAttachmentValue(String argName, Object value) { if(StringUtils.isBlank(argName) || value == null) { return; } bootstrapArgs.put(argName, value); bootstrapArgsString.put(argName, value.toString()); }Alternatively, you could use concurrent map implementations:
private final Map<String, Object> bootstrapArgs = new ConcurrentHashMap<>(); private final Map<String, String> bootstrapArgsString = new ConcurrentHashMap<>();apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java (2)
23-27: Enhance class-level documentationThe current documentation only includes author and date. Consider adding a class-level description explaining the purpose and usage of this utility class.
/** + * Utility class providing date formatting functionality for Apollo Client monitoring. + * This class standardizes date formatting across the application. + * * @author Rawven * @date 2024/10/19 */
28-28: Consider making MEDIUM_FORMATTER privateWhile the formatter is correctly declared as final, consider making it private to prevent external modifications and maintain encapsulation. If external access is needed, provide a getter method.
- public static final DateTimeFormatter MEDIUM_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); + private static final DateTimeFormatter MEDIUM_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");apollo-client/src/test/java/com/ctrip/framework/apollo/util/date/DateUtilTest.java (1)
26-37: Consider adding more test cases for edge scenariosWhile the basic test case is good, consider adding tests for:
- Dates at year boundaries (e.g., 9999-12-31 23:59:59)
- Different time components (with/without seconds)
- Different time zones
Here's an example of additional test cases:
@Test public void testFormatLocalDateTime_edgeCases() { // Test year boundary LocalDateTime maxDate = LocalDateTime.of(9999, 12, 31, 23, 59, 59); Optional<String> result = DateUtil.formatLocalDateTime(maxDate); assertTrue(result.isPresent()); assertEquals("9999-12-31 23:59:59", result.get()); // Test minimum date LocalDateTime minDate = LocalDateTime.of(1, 1, 1, 0, 0, 0); result = DateUtil.formatLocalDateTime(minDate); assertTrue(result.isPresent()); assertEquals("0001-01-01 00:00:00", result.get()); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java(3 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java(1 hunks)apollo-client/src/test/java/com/ctrip/framework/apollo/util/date/DateUtilTest.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java
🔇 Additional comments (8)
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (4)
26-38: LGTM! Import changes are appropriate.
The new imports support the added functionality for date formatting and null checking.
55-83: LGTM! Good refactoring of map updates.
The change to use putAttachmentValue centralizes the null checking logic and ensures consistent updates to both maps. The addition of monitoring parameters with proper initialization addresses the issue mentioned in PR #85 regarding default values.
84-84: Empty string initialization of CONFIG_SERVICE_URL needs review.
Initializing CONFIG_SERVICE_URL with an empty string may cause issues. Consider:
- Using a default value from
configUtil - Omitting the initialization if there's no valid default
- Using
Optionalto handle the absence of a value
92-92: LGTM! Consistent use of putAttachmentValue.
The change maintains consistency with the refactoring pattern and ensures proper null checking.
apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (2)
559-559: LGTM! Property initialization is consistent with field default
The change to use "" as the fallback value in getProperty maintains consistency with the field's default value, ensuring uniform behavior regardless of initialization path.
77-77: LGTM! Verify the impact on ConfigMonitorInitializer
The change from "NONE" to "" as the default value is appropriate and aligns with the PR objective to prevent redundant logging when monitoring is not configured.
Let's verify the integration with ConfigMonitorInitializer:
✅ Verification successful
LGTM! The change from "NONE" to "" is safe and working as intended
The code review shows that changing monitorExternalType's default value from "NONE" to "" is safe and properly integrated with ConfigMonitorInitializer. The initialization logic in ConfigMonitorInitializer.initializeMetricsExporter() explicitly checks for empty strings using StringUtils.isEmpty() and returns early when the type is empty, which aligns perfectly with the new default value. This change effectively prevents redundant logging while maintaining the expected behavior of skipping metrics initialization when monitoring is not configured.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check how ConfigMonitorInitializer uses monitorExternalType
# Expected: Should find early return condition when type is empty
ast-grep --pattern 'if ($condition) {
return;
}' apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/ConfigMonitorInitializer.java
Length of output: 285
Script:
#!/bin/bash
# Let's first find the correct path for ConfigMonitorInitializer
fd -t f "ConfigMonitorInitializer.java"
# Then search for any files that use monitorExternalType
rg -l "monitorExternalType"
Length of output: 238
Script:
#!/bin/bash
# Let's check how ConfigMonitorInitializer uses the monitorExternalType
rg -A 5 "monitorExternalType" apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java
# Also check the complete implementation of ConfigMonitorInitializer
cat apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java
Length of output: 6531
apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java (1)
36-39: LGTM! Well-implemented null handling using Optional
The implementation correctly uses Optional to handle null values, addressing the previous review comment. The method is concise and follows functional programming principles.
apollo-client/src/test/java/com/ctrip/framework/apollo/util/date/DateUtilTest.java (1)
39-46: LGTM! Null handling test is well implemented
The test case properly verifies the Optional behavior for null input.
|
@Anilople Fixed completed ，sir |
...rip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java
Outdated
Show resolved
Hide resolved
...m/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java
Outdated
Show resolved
Hide resolved
...a/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java
Outdated
Show resolved
Hide resolved
Rawven
force-pushed
the
fix/monitor-bug
branch
from
648e5d1 to
4f29c75
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (1)
97-103: Improve null safety in string conversion.While the null check prevents null values from being processed, using String.valueOf directly could lead to "null" strings being stored if the validation changes in the future. Consider using Optional for more robust null handling.
private void putAttachmentValue(String argName, Object value) { if(StringUtils.isBlank(argName) || value == null) { return; } bootstrapArgs.put(argName, value); - bootstrapArgsString.put(argName, String.valueOf(value)); + bootstrapArgsString.put(argName, Optional.ofNullable(value) + .map(Object::toString) + .orElse("")); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java(3 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java(2 hunks)apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java(1 hunks)apollo-client/src/test/java/com/ctrip/framework/apollo/util/date/DateUtilTest.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigMonitorInitializer.java
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/tracer/ApolloClientMonitorMessageProducer.java
- apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientNamespaceApi.java
- apollo-client/src/main/java/com/ctrip/framework/apollo/util/date/DateUtil.java
- apollo-client/src/test/java/com/ctrip/framework/apollo/util/date/DateUtilTest.java
- apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java
🔇 Additional comments (5)
apollo-client/src/main/java/com/ctrip/framework/apollo/monitor/internal/listener/impl/DefaultApolloClientBootstrapArgsApi.java (5)
26-38: LGTM! The new imports support the added functionality.
The added imports for StringUtils, DateUtil, and LocalDateTime are appropriate for the new date formatting and string handling capabilities.
82-83: Good use of Optional for safe date handling.
The use of Optional with DateUtil.formatLocalDateTime ensures null-safe handling of the date value, and the ifPresent consumer provides a clean way to conditionally set the value.
90-91: LGTM! Good use of centralized value setting.
The change to use putAttachmentValue maintains consistency with the rest of the class and ensures proper validation of values.
84-84:
Initialization of CONFIG_SERVICE_URL needs improvement.
Initializing CONFIG_SERVICE_URL with an empty string may cause issues. Consider either:
- Initializing it with a meaningful default value
- Skipping the initialization if there's no valid value
-putAttachmentValue(CONFIG_SERVICE_URL,"");
+// Only set CONFIG_SERVICE_URL if a valid value is available
+Optional.ofNullable(configUtil.getConfigServiceUrl())
+ .ifPresent(url -> putAttachmentValue(CONFIG_SERVICE_URL, url));69-70: Verify monitor configuration handling.
Let's verify that the monitor configuration is properly handled across the codebase.
✅ Verification successful
Based on the search results, I can verify that the monitor configuration changes are properly integrated across the codebase. Let me explain my findings:
Monitor configuration is properly integrated and tested
The changes are well-integrated because:
- The configuration constants are properly defined in
apollo-core/.../ApolloClientSystemConsts.java - The configuration is used consistently across multiple components:
ConfigMonitorInitializerfor initialization logicDefaultApolloClientMetricsExporterFactoryfor metrics exportApolloClientBootstrapArgsMonitorApifor API accessConfigUtilfor core configuration handling
- Comprehensive test coverage exists in:
ConfigUtilTestfor configuration handlingConfigMonitorInitializerTestfor initializationDefaultApolloClientMetricsExporterFactoryTestfor metrics exportApolloClientMonitorEventPublisherTestfor event handling
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for monitor configuration usage
echo "Checking monitor configuration handling..."
# Search for monitor type configuration
echo "Monitor type configuration:"
rg --type java "getMonitorExternalType|APOLLO_CLIENT_MONITOR_EXTERNAL_TYPE"
# Search for monitor enabled configuration
echo "Monitor enabled configuration:"
rg --type java "isClientMonitorEnabled|APOLLO_CLIENT_MONITOR_ENABLED"
# Search for related test cases
echo "Related test cases:"
rg --type java -l "class.*Test.*Monitor"
Length of output: 7459
Rawven
force-pushed
the
fix/monitor-bug
branch
from
4f29c75 to
8ce2dac
Compare
|
@Anilople @nobodyiam Done,you can merge it now |
What's the purpose of this PR
修复当初合并PR #74 时未及时找出来的bug与问题
基于以下仓库持续测试中
apollo-ospp-test apollo-demo-java
Which issue(s) this PR fixes:
Fixes #85
Brief changelog
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:
mvn clean testto make sure this pull request doesn't break anything.CHANGESlog.Summary by CodeRabbit
Summary by CodeRabbit
New Features
DateUtilclass for standardized date and time formatting.DateUtilclass to ensure correct functionality.Bug Fixes
DateUtilclass.Documentation
Refactor
monitorExternalTypefor more flexible configuration.