Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add multiple appId,pull other appId config into config. #70

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

add multiple appId,pull other appId config into config. #70

wants to merge 6 commits into from

Conversation

TerryLam2010
Copy link

@TerryLam2010 TerryLam2010 commented Jul 10, 2024 •
edited by coderabbitai bot
Loading

What's the purpose of this PR

add multiple appId pull into config
see #66

Which issue(s) this PR fixes:

Fixes #

Follow this checklist to help us incorporate your contribution quickly and easily:

Summary by CodeRabbit

  • New Features

    • Introduced appId parameter across various configuration classes, allowing configuration queries and changes to be associated with a specific application ID.
    • Added new method getAccessKeySecret(String appId) to manage access keys based on application IDs.
    • Implemented new methods for retrieving the default local cache directory using appId.

  • Changes in APIs

    • Updated method signatures in multiple configuration classes and services to include appId.
    • Enhanced configuration management methods to support application-specific identifiers.

  • Refactor

    • Refactored internal data structures and methods to support the inclusion of appId.

These changes enhance the ability to manage and query configurations on a per-application basis, improving flexibility and granularity in configuration management.

@github-actions GitHub Actions
Copy link

github-actions bot commented Jul 10, 2024 •
edited
Loading

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

@coderabbitai coderabbitai
Copy link
Contributor

coderabbitai bot commented Jul 10, 2024 •
edited
Loading

Walkthrough

The recent updates to the Apollo Client introduce an appId parameter across multiple classes and methods. This enhancement improves configuration management by allowing retrieval and handling of configurations tailored to specific applications, facilitating greater flexibility and organization in multi-application environments. Additionally, the CHANGES.md file reflects a version update from 2.3.0 to 2.4.0, with a significant reduction in detailed entries.

Changes

Files/Groups Changes Summary
ConfigService.java, DefaultConfigManager.java, RemoteConfigLongPollService.java, DefaultConfigFactoryManager.java, PropertySourcesProcessor.java Added appId parameter to methods, enhancing multi-application configuration management.
AbstractSpringIntegrationTest.java, ConfigServiceTest.java, RemoteConfigLongPollServiceTest.java, PropertySourcesProcessorTest.java Updated test cases to reflect changes in method signatures and improve clarity in testing configurations.
AbstractConfig.java, AbstractConfigFile.java, AbstractConfigRepository.java, DefaultConfig.java, LocalFileConfigRepository.java, RemoteConfigRepository.java, SimpleConfig.java, YamlConfigFile.java Modified constructors and methods to include appId, improving configuration handling across various classes.
MockConfig.java, MockConfigFile.java, MockConfigFactory.java, MockConfigUtil.java Updated constructors and methods to incorporate appId, ensuring consistency in configuration handling.
ConfigUtil.java Added new methods for retrieving local cache directories and access keys based on appId.
CHANGES.md Updated milestone link and removed detailed entries for version 2.4.0.

Sequence Diagrams

Configuration Retrieval Flow

sequenceDiagram
    participant Client as Client
    participant ConfigService as ConfigService
    participant ConfigManager as ConfigManager
    participant ConfigRepository as ConfigRepository

    Client->>ConfigService: getConfig(appId, namespace)
    ConfigService->>ConfigManager: getConfig(appId, namespace)
    ConfigManager->>ConfigRepository: fetchConfig(appId, namespace)
    ConfigRepository-->>ConfigManager: return Config
    ConfigManager-->>ConfigService: return Config
    ConfigService-->>Client: return Config
Loading

Configuration Change Notification Flow

sequenceDiagram
    participant ConfigRepository as ConfigRepository
    participant RemoteConfigLongPollService as RemoteConfigLongPollService
    participant Client as Client
    
    ConfigRepository->>RemoteConfigLongPollService: submit(appId, namespace)
    RemoteConfigLongPollService->>Client: notify(appId, namespace, changes)
    Client-->>ConfigRepository: onRepositoryChange(appId, namespace, newProperties)
Loading
  • Possibly related issues:
    • apollo-client支持多appid拉取配置的功能: This PR directly addresses the need for multi-app ID support in configuration retrieval, as outlined in the issue description.

🐰 In fields of green, I hop with glee,
New app IDs bloom, oh what a spree!
Configs now dance, tailored with care,
Multi-app magic fills the air!
With each little change, our dreams take flight,
A brighter tomorrow, oh what a delight! 🌼

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

coderabbitai[bot]
coderabbitai bot reviewed Jul 10, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range, codebase verification and nitpick comments (4)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (1)

82-83: Update getConfigFile method calls to include appId parameter.

The following instances of getConfigFile calls are still using the old signature and need to be updated to include the appId parameter:

  • ApolloClientConfigurationFactory.java

    • Line: 12

  • ConfigServiceTest.java

    • Line: 4

  • DefaultConfigManagerTest.java

    • Line: 12
    • Line: 18
    • Line: 24

Please update these method calls to match the new signature.

Analysis chain

Verify the function usage for the updated signature.

The getConfigFile method now includes appId as a parameter. Ensure all calls to this method are updated accordingly.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `getConfigFile` match the new signature.

# Test: Search for the function usage. Expect: Only occurances of the new signature.
rg --type java -A 5 $'getConfigFile'

Length of output: 20390

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (2)

106-110: Issue Found: Update setConfig Method to Include appId Parameter

The setConfig method in ConfigService.java does not include the new appId parameter as suggested in the review comment. Please update the method to include the appId parameter.

  • File: apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java
  • Lines: 106-110

Please ensure that all calls to this method are updated accordingly.

Analysis chain

Verify the function usage for the updated signature.

The setConfig method now includes appId as a parameter. Ensure all calls to this method are updated accordingly.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `setConfig` match the new signature.

# Test: Search for the function usage. Expect: Only occurances of the new signature.
rg --type java -A 5 $'setConfig'

Length of output: 10705

Script:

#!/bin/bash
# Description: Verify if the setConfig method in ConfigService.java includes the new appId parameter.

# Test: Search for the setConfig method usage in ConfigService.java. Expect: Occurrences of the new signature with appId.
rg --type java -A 5 'setConfig' apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java

Length of output: 940

80-82: Update calls to ConfigService.getConfig to use the new signature.

The getConfig method now includes appId as a parameter. The following instances still use the old signature and need to be updated:

  • apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiWhileCacheDirSpecifiedTest.java
  • apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XMLConfigAnnotationTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/integration/ConfigIntegrationTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/integration/ConfigServiceTimeoutIntegrationTest.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/importer/ApolloConfigDataLoader.java

Please update these instances to use the new method signature that includes appId.

Analysis chain

Verify the function usage for the updated signature.

The getConfig method now includes appId as a parameter. Ensure all calls to this method are updated accordingly.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `getConfig` match the new signature.

# Test: Search for the function usage. Expect: Only occurances of the new signature.
rg --type java -A 5 $'getConfig'

Length of output: 149777

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (1)

102-104: Update all instances of onRepositoryChange to the new signature.

The following instances of onRepositoryChange still use the old signature without appId. Please update them to include appId:

  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java:
    • Line 1: simpleConfig.onRepositoryChange(TestApolloConfigChangeListenerWithInterestedKeyPrefixesBean1.SPECIAL_NAMESPACE, properties);
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderAutoUpdateTest.java:
    • Line 1: config.onRepositoryChange(ConfigConsts.NAMESPACE_APPLICATION, newProperties);
    • Line 2: config.onRepositoryChange(ConfigConsts.NAMESPACE_APPLICATION, newProperties);
    • Line 3: config.onRepositoryChange(ConfigConsts.NAMESPACE_APPLICATION, newProperties);
    • Line 4: config.onRepositoryChange(ConfigConsts.NAMESPACE_APPLICATION, newProperties);
    • Line 5: applicationConfig.onRepositoryChange(ConfigConsts.NAMESPACE_APPLICATION, newProperties);
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java:
    • Line 1: configFile.onRepositoryChange(someNamespace, anotherProperties);
    • Line 2: configFile.onRepositoryChange(someNamespace, someProperties);
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java:
    • Line 1: defaultConfig.onRepositoryChange(someNamespace, anotherProperties);
    • Line 2: defaultConfig.onRepositoryChange(someNamespace, someProperties);
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepositoryTest.java:
    • Line 1: verify(someListener, times(1)).onRepositoryChange(someNamespaceName, anotherProperties);
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java:
    • Line 1: verify(someListener, times(1)).onRepositoryChange(eq(someNamespace), captor.capture());
    • Line 2: verify(someListener, times(1)).onRepositoryChange(any(String.class), any(Properties.class));
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java:
    • Line 1: configFile.onRepositoryChange(someNamespace, anotherProperties);
    • Line 2: configFile.onRepositoryChange(someNamespace, someProperties);

Please review and update these instances to ensure consistency with the new method signature.

Analysis chain

Verify the function usage for the updated signature.

The onRepositoryChange method now includes appId as a parameter. Ensure all calls to this method are updated accordingly.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `onRepositoryChange` match the new signature.

# Test: Search for the function usage. Expect: Only occurances of the new signature.
rg --type java -A 5 $'onRepositoryChange'

Length of output: 63294

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 6b0d4c7 and 598e03a.

Files selected for processing (57)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1 hunks)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfigFactory.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (7 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEvent.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/JsonConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepository.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/TxtConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/XmlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YmlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactory.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactoryManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigRegistry.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/property/AutoUpdateConfigChangeListener.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/property/SpringValue.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java (30 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepositoryTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java (9 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (9 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/SimpleConfigTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/YamlConfigFileTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (3 hunks)
Files not processed due to max files limit (14)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistryTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderAutoUpdateTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XMLConfigAnnotationTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderAutoUpdateTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java
  • apollo-mockserver/src/main/java/com/ctrip/framework/apollo/mockserver/ApolloTestingServer.java
  • apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiWhileCacheDirSpecifiedTest.java
Files skipped from review due to trivial changes (1)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/property/AutoUpdateConfigChangeListener.java
Additional comments not posted (200)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1)

1-29: Review of the new MultipleConfig annotation

  1. Annotation Purpose:
    The MultipleConfig annotation is designed to supplement @EnableApolloConfig for handling multiple appId configurations.

  2. Attributes:

    • appId: This attribute is correctly defined to hold a single application ID.
    • namespaces: This attribute is correctly defined to hold multiple namespaces.
    • secret: This attribute is correctly defined with a default value and an example in the documentation.

The provided code looks good and correctly defines the annotation and its attributes.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/TxtConfigFile.java (1)

23-24: Constructor modification to include appId

The constructor now includes the appId parameter, which is correctly passed to the superclass constructor.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YmlConfigFile.java (1)

25-26: Constructor modification to include appId

The constructor now includes the appId parameter, which is correctly passed to the superclass constructor.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/XmlConfigFile.java (1)

25-27: Constructor modification to include appId

The constructor now includes the appId parameter, which is correctly passed to the superclass constructor.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/JsonConfigFile.java (1)

25-27: Constructor change to include appId looks good.

The addition of appId in the constructor and passing it to the superclass is appropriate.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactoryManager.java (1)

30-37: New method to get the config factory by appId looks good.

The new method getFactory with appId parameter is consistent with the existing method and extends functionality appropriately.

apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfigFactory.java (1)

30-31: Overridden method to include appId looks good.

The overridden method createRepositoryConfig now includes appId, ensuring PureApolloConfig is created correctly.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java (1)

31-38: New method to handle repository changes by appId looks good.

The new method onRepositoryChange with appId parameter is consistent with the existing method and extends functionality appropriately.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java (1)

27-28: Constructor change approved.

The constructor now includes appId, aligning with the PR objectives of adding appId to configurations.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigRegistry.java (2)

33-41: Method register change approved.

The method now includes appId, aligning with the PR objectives of adding appId to configurations.

50-57: Method getFactory change approved.

The method now includes appId, aligning with the PR objectives of adding appId to configurations.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactory.java (2)

35-43: Method create change approved.

The method now includes appId, aligning with the PR objectives of adding appId to configurations.

51-57: Method createConfigFile change approved.

The method now includes appId, aligning with the PR objectives of adding appId to configurations.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEvent.java (1)

44-46: Constructor change approved.

The constructor now includes appId, aligning with the PR objectives of adding appId to configurations.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java (4)

34-34: Add someAppId field.

The someAppId field is added to the test class to facilitate testing the new appId parameter in the TxtConfigFile class.

41-41: Initialize someAppId in setUp method.

The someAppId variable is initialized in the setUp method to be used in the test cases.

54-54: Update TxtConfigFile instantiation to include appId.

The instantiation of TxtConfigFile is updated to include the new appId parameter, ensuring the test reflects the updated constructor.

57-57: Add assertion for appId in TxtConfigFile.

An assertion is added to verify that the appId is correctly set in the TxtConfigFile instance.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (2)

34-34: Add getConfig method with appId.

A new method getConfig is added to the ConfigManager interface to retrieve configuration instances based on appId and namespace.

41-41: Add getConfigFile method with appId.

A new method getConfigFile is added to the ConfigManager interface to retrieve configuration file instances based on appId, namespace, and configFileFormat.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1)

38-38: Add getAppId method.

A new method getAppId is added to the ConfigFile interface to retrieve the appId of the configuration file instance.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (5)

22-22: Import ConfigUtil.

The ConfigUtil class is imported to facilitate retrieving the appId in the getFactory method.

33-34: Add m_configUtil field.

A new field m_configUtil is added to store the ConfigUtil instance, which is used to retrieve the appId.

37-37: Initialize m_configUtil in constructor.

The m_configUtil field is initialized in the constructor to ensure it is available for use in the getFactory method.

42-43: Update getFactory method to use appId.

The getFactory method is updated to retrieve the appId using m_configUtil and delegate to the overloaded getFactory method with appId and namespace.

45-45: Add overloaded getFactory method with appId.

An overloaded getFactory method is added to handle retrieving configuration factories based on appId and namespace.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (3)

26-26: Addition of appId field.

The new field appId has been introduced to store the application ID associated with the config file change event. This change aligns with the PR objective to support multiple appId configurations.

41-43: Constructor update to include appId.

The constructor now includes appId as a parameter to initialize the new field. This change ensures that each config file change event is associated with a specific application ID.

69-70: Update to toString() method to include appId.

The toString() method now includes the appId field in its output. This change ensures that the string representation of the config file change event includes the application ID.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (3)

39-39: Usage of Tables.synchronizedTable.

The m_instances field is now initialized using Tables.synchronizedTable to ensure thread safety. This change is crucial for concurrent access to the configuration instances.

47-48: Update to register method to include appId.

The register method now includes appId as a parameter, and the existing method delegates to the new method with appId. This change ensures that configurations are registered with a specific application ID.

61-62: Update to getFactory method to include appId.

The getFactory method now includes appId as a parameter, and the existing method delegates to the new method with appId. This change ensures that the correct configuration factory is retrieved based on the application ID.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepository.java (1)

46-46: Update to fireRepositoryChange method call to include appId.

The fireRepositoryChange method call now includes appId as a parameter. This change ensures that repository changes are correctly associated with the specific application ID.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (3)

28-28: Addition of appId field.

The new field appId has been introduced to store the application ID associated with the config change event. This change aligns with the PR objective to support multiple appId configurations.

36-38: Constructor update to include appId.

The constructor now includes appId as a parameter to initialize the new field. This change ensures that each config change event is associated with a specific application ID.

83-85: Addition of getAppId method.

The new getAppId method provides access to the appId field. This change is necessary to retrieve the application ID associated with the config change event.

apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1)

37-39: Constructor updated to include appId.

The constructor now includes the appId parameter, which is passed to the superclass. Ensure that the appId is correctly utilized in the superclass and throughout the configuration management logic.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1)

66-69: Method fireRepositoryChange updated to include appId.

The fireRepositoryChange method now includes the appId parameter. Ensure that all listeners handle the appId correctly and that this change is consistently propagated throughout the repository change notification logic.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1)

72-76: New parameter multipleConfig added.

The multipleConfig parameter supports additional appId and namespace configurations. Ensure this parameter is correctly utilized in the annotation processing logic and that it does not interfere with existing configurations.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (2)

27-27: New field appId added.

The appId field is now part of the ConfigChange class. Ensure this field is correctly utilized in all relevant methods and that it is properly initialized.

36-45: Constructor updated to include appId.

The constructor now includes the appId parameter. Ensure that this parameter is correctly utilized in the initialization logic and that it is consistently propagated throughout the configuration change management logic.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesConfigFile.java (1)

39-41: Constructor change: Initialization of appId looks good.

The constructor correctly passes appId to the superclass.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (1)

39-40: Constructor change: Initialization of appId looks good.

The constructor correctly passes appId to the superclass.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java (3)

41-46: Test setup: Initialization of appId and namespace looks good.

The test setup correctly initializes someAppId and someNamespace.

58-62: Test method: Handling of appId looks good.

The test method correctly passes appId in the method calls and assertions.

70-74: Test method: Handling of appId looks good.

The test method correctly passes appId in the method calls and assertions.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (1)

74-77: Test method: Handling of appId looks good.

The test method correctly passes appId in the ConfigChange and fireConfigChange method calls.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (3)

61-73: Concurrency handling review.

The method uses computeIfAbsent and synchronized blocks for concurrency control. This approach is correct, but ensure that the lock object is not excessively contended.

Line range hint 86-119:
Concurrency handling review.

The method uses computeIfAbsent and synchronized blocks for concurrency control. This approach is correct, but ensure that the lock object is not excessively contended.

57-58: Verify the function usage for the updated signature.

The getConfig method now includes appId as a parameter. Ensure all calls to this method are updated accordingly.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/property/SpringValue.java (1)

131-131: LGTM!

The isTargetBeanValid method correctly checks if the bean reference is still valid.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (1)

116-119: Verify the function usage for the updated signature.

The setConfigFactory method now includes appId as a parameter. Ensure all calls to this method are updated accordingly.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (2)

Line range hint 106-126:
Concurrency handling review.

The method uses synchronized blocks for concurrency control. This approach is correct, but ensure that the lock object is not excessively contended.

57-58: Verify the constructor usage for the updated signature.

The SimpleConfig constructor now includes appId as a parameter. Ensure all calls to this constructor are updated accordingly.

Verification successful

Verified the constructor usage for the updated signature.

The SimpleConfig constructor now includes appId as a parameter, and all calls to this constructor have been updated accordingly.

  • All instances of SimpleConfig in the codebase correctly use the new constructor signature.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `SimpleConfig` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurances of the new signature.
rg --type java -A 5 $'SimpleConfig'

Length of output: 46034

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java (6)

Line range hint 42-51:
LGTM! Initialization of someAppId and someNamespace.

The initialization of someAppId and someNamespace in the setUp method is correct.

67-67: LGTM! Integration of someAppId in testWhenHasContent.

The integration of someAppId in the JsonConfigFile constructor and the subsequent assertions are correct.

80-80: LGTM! Integration of someAppId in testWhenHasNoContent.

The integration of someAppId in the JsonConfigFile constructor and the subsequent assertions are correct.

90-90: LGTM! Integration of someAppId in testWhenConfigRepositoryHasError.

The integration of someAppId in the JsonConfigFile constructor and the subsequent assertions are correct.

Line range hint 110-121:
LGTM! Integration of someAppId in testOnRepositoryChange.

The integration of someAppId in the JsonConfigFile constructor and the onRepositoryChange method is correct. The test verifies the behavior correctly.

139-145: LGTM! Integration of someAppId in testWhenConfigRepositoryHasErrorAndThenRecovered.

The integration of someAppId in the JsonConfigFile constructor and the onRepositoryChange method is correct. The test verifies the recovery behavior correctly.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (13)

101-105: LGTM! Addition of create method with appId in MockConfigRegistry.

The addition of the create method with the appId parameter in the MockConfigRegistry class is correct.

111-115: LGTM! Addition of createConfigFile method with appId in MockConfigRegistry.

The addition of the createConfigFile method with the appId parameter in the MockConfigRegistry class is correct.

123-126: LGTM! Addition of register method with appId in MockConfigRegistry.

The addition of the register method with the appId parameter in the MockConfigRegistry class is correct.

136-139: LGTM! Addition of getFactory method with appId in MockConfigRegistry.

The addition of the getFactory method with the appId parameter in the MockConfigRegistry class is correct.

148-152: LGTM! Addition of create method with appId in SomeConfigFactory.

The addition of the create method with the appId parameter in the SomeConfigFactory class is correct.

158-161: LGTM! Addition of createConfigFile method with appId in SomeConfigFactory.

The addition of the createConfigFile method with the appId parameter in the SomeConfigFactory class is correct.

170-174: LGTM! Addition of create method with appId in AnotherConfigFactory.

The addition of the create method with the appId parameter in the AnotherConfigFactory class is correct.

180-183: LGTM! Addition of createConfigFile method with appId in AnotherConfigFactory.

The addition of the createConfigFile method with the appId parameter in the AnotherConfigFactory class is correct.

116-119: LGTM! Addition of getFactory method with appId in MockConfigFactoryManager.

The addition of the getFactory method with the appId parameter in the MockConfigFactoryManager class is correct.

139-142: LGTM! Addition of create method with appId in MockConfigFactoryManager.

The addition of the create method with the appId parameter in the MockConfigFactoryManager class is correct.

Line range hint 144-146:
LGTM! Addition of createConfigFile method with appId in MockConfigFactoryManager.

The addition of the createConfigFile method with the appId parameter in the MockConfigFactoryManager class is correct.

171-173: LGTM! Addition of createConfigFile method with appId in MockConfigFactoryManager.

The addition of the createConfigFile method with the appId parameter in the MockConfigFactoryManager class is correct.

177-180: LGTM! Addition of getFactory method with appId in MockConfigFactoryManager.

The addition of the getFactory method with the appId parameter in the MockConfigFactoryManager class is correct.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (4)

61-63: LGTM! Integration of appId in the constructor.

The integration of the appId parameter in the constructor of the AbstractConfigFile class is correct.

85-88: LGTM! Implementation of getAppId.

The implementation of the getAppId method in the AbstractConfigFile class is correct.

99-100: LGTM! Integration of appId in onRepositoryChange.

The integration of the appId parameter in the onRepositoryChange method of the AbstractConfigFile class is correct.

Line range hint 102-125:
LGTM! Integration of appId in the synchronized onRepositoryChange method.

The integration of the appId parameter in the synchronized onRepositoryChange method of the AbstractConfigFile class is correct.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java (3)

46-54: LGTM! Initialization of someAppId.

The initialization of someAppId in the setUp method is correct.

116-119: LGTM! Addition of getFactory method with appId in MockConfigFactoryManager.

The addition of the getFactory method with the appId parameter in the MockConfigFactoryManager class is correct.

139-142: LGTM! Addition of create method with appId in MockConfigFactoryManager.

The addition of the create method with the appId parameter in the MockConfigFactoryManager class is correct.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/SimpleConfigTest.java (3)

Line range hint 52-62: LGTM! Initialization and mocking are correctly done.

The setUp function correctly initializes the someAppId variable and mocks the configRepository and propertiesFactory.

91-93: LGTM! The test case correctly verifies the functionality.

The testGetProperty test case correctly verifies the getProperty and getSourceType methods of the SimpleConfig class.

Line range hint 138-166: LGTM! The test case correctly verifies the functionality.

The testOnRepositoryChange test case correctly verifies the onRepositoryChange method of the SimpleConfig class.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (2)

56-77: LGTM! The method correctly handles multiple appId configurations.

The registerBeanDefinitions method correctly handles multiple appId configurations and sets the secret property.

106-112: LGTM! The method correctly resolves the secret using the environment.

The resolveSecret method correctly resolves the secret using the environment.

apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (4)

62-66: LGTM! The test case correctly verifies the functionality.

The testHackConfig test case correctly verifies the getAppConfig method of the ConfigService class.

89-91: LGTM! The test case correctly verifies the functionality.

The testMockConfigFactory test case correctly verifies the getConfig method of the ConfigService class.

102-103: LGTM! The test case correctly verifies the functionality.

The testMockConfigFactoryForConfigFile test case correctly verifies the getConfigFile method of the ConfigService class.

197-212: LGTM! The methods correctly create Config and ConfigFile instances.

The MockConfigFactory class methods correctly create Config and ConfigFile instances with the appId parameter.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java (3)

68-72: LGTM! The test case correctly verifies the functionality.

The testFireConfigChange_cannot_notify test case correctly verifies the fireConfigChange method of the AbstractConfig class.

111-112: LGTM! The test case correctly verifies the functionality.

The testFireConfigChange_event_notify_once test case correctly verifies the fireConfigChange method of the AbstractConfig class.

156-158: LGTM! The test case correctly verifies the functionality.

The testFireConfigChange_changes_notify_once test case correctly verifies the fireConfigChange method of the AbstractConfig class.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (4)

99-100: LGTM!

The changes correctly integrate the appId parameter.

104-118: LGTM!

The changes correctly integrate the appId parameter.

124-138: LGTM!

The changes correctly integrate the appId parameter.

68-69: Verify the usage of create method with appId.

Ensure that all calls to the create method are updated to use the new method with appId where appropriate.

Verification successful

Verify the usage of create method with appId.

The create method with the appId parameter is correctly used in the codebase. The instances of the new method signature have been found and verified.

  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all calls to the `create` method with `appId`.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'create($_, $_)'

Length of output: 38

Script:

#!/bin/bash
# Description: Verify all calls to the `create` method with `appId`.

# Test: Search for the function usage. Expect: Occurrences of the new signature.
rg --type java -A 5 -w 'create'

Length of output: 96565

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java (8)

60-60: LGTM!

The initialization of someAppId is correct and integrates well with existing code.

85-85: LGTM!

The changes correctly integrate the appId parameter.

97-97: LGTM!

The changes correctly integrate the appId parameter.

107-107: LGTM!

The changes correctly integrate the appId parameter.

123-123: LGTM!

The changes correctly integrate the appId parameter.

162-162: LGTM!

The changes correctly integrate the appId parameter.

182-182: LGTM!

The changes correctly integrate the appId parameter.

197-197: LGTM!

The changes correctly integrate the appId parameter.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (6)

68-70: LGTM!

The initialization of configUtil is correct and integrates well with existing code.

73-74: LGTM!

The changes correctly integrate the appId parameter.

76-79: LGTM!

The changes correctly integrate the appId parameter.

102-118: LGTM!

The changes correctly integrate the appId parameter.

176-176: LGTM!

The reset logic is correct and integrates well with existing code.

Line range hint 204-208: LGTM!

The changes correctly integrate the appId parameter.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepositoryTest.java (7)

122-122: LGTM!

The changes correctly integrate the appId parameter.

122-122: LGTM!

The changes correctly integrate the appId parameter.

138-138: LGTM!

The changes correctly integrate the appId parameter.

150-150: LGTM!

The changes correctly integrate the appId parameter.

164-171: LGTM!

The changes correctly integrate the appId parameter.

Line range hint 187-208: LGTM!

The changes correctly integrate the appId parameter.

204-204: LGTM!

The changes correctly integrate the appId parameter.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java (5)

52-52: Initialize someAppId correctly.

Ensure that the someAppId variable is correctly initialized and used in the tests.

Also applies to: 61-61

88-88: Pass appId correctly to constructor.

Ensure that the appId parameter is correctly passed to the XmlConfigFile constructor.

100-100: Pass appId correctly to constructor.

Ensure that the appId parameter is correctly passed to the XmlConfigFile constructor.

110-110: Pass appId correctly to constructor.

Ensure that the appId parameter is correctly passed to the XmlConfigFile constructor.

126-126: Pass appId correctly to constructor and method.

Ensure that the appId parameter is correctly passed to the XmlConfigFile constructor and onRepositoryChange method.

Also applies to: 143-143

apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java (1)

121-121: Initialize someAppId correctly.

Ensure that the someAppId variable is correctly initialized and used in the integration tests.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/YamlConfigFileTest.java (5)

42-42: Initialize someAppId correctly.

Ensure that the someAppId variable is correctly initialized and used in the tests.

Also applies to: 55-55

89-89: Pass appId correctly to constructor.

Ensure that the appId parameter is correctly passed to the YamlConfigFile constructor.

115-115: Pass appId correctly to constructor.

Ensure that the appId parameter is correctly passed to the YamlConfigFile constructor.

129-129: Pass appId correctly to constructor.

Ensure that the appId parameter is correctly passed to the YamlConfigFile constructor.

203-203: Pass appId correctly to constructor and method.

Ensure that the appId parameter is correctly passed to the YamlConfigFile constructor and onRepositoryChange method.

Also applies to: 215-215

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (6)

52-52: Add and initialize m_appId field correctly.

Ensure that the appId parameter is correctly passed and assigned to the m_appId field.

Also applies to: 66-71

139-150: Overload onRepositoryChange correctly.

Ensure that the appId parameter is correctly passed and utilized in the method.

Line range hint 151-193: Ensure existing logic remains intact.

The sync method does not involve changes related to appId. Ensure that the existing logic remains intact.

Line range hint 194-208: Ensure existing logic remains intact.

The trySyncFromUpstream method does not involve changes related to appId. Ensure that the existing logic remains intact.

Line range hint 209-222: Ensure existing logic remains intact.

The updateFileProperties method does not involve changes related to appId. Ensure that the existing logic remains intact.

142-150: Overload onRepositoryChange correctly.

Ensure that the appId parameter is correctly passed and utilized in the method.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (6)

49-49: Add appId initialization.

The new m_appId field is correctly initialized in the constructor.

224-225: Update onRepositoryChange method to include appId.

The onRepositoryChange method has been overloaded to include appId. Ensure it is called with the correct parameters.

Line range hint 227-245:
Add new onRepositoryChange method with appId.

The new onRepositoryChange method correctly includes the appId parameter. Ensure consistency in its usage.

Line range hint 309-321:
Load resource config using appId.

The loadFromResource method now includes appId in the resource path. Ensure the resource files follow this naming convention.

258-258: Update calcPropertyChanges call to include appId.

The calcPropertyChanges method is now called with appId. Ensure the method signature matches this change.

Verification successful

Method signature already includes appId.

The calcPropertyChanges method signature in AbstractConfig.java already includes appId as a parameter, which matches the suggested change.

  • calcPropertyChanges method definition: 
    List<ConfigChange> calcPropertyChanges(String appId, String namespace, Properties previous, Properties current)
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the method signature of `calcPropertyChanges` to include `appId`.

# Test: Search for the method definition. Expect: Signature includes `appId`.
rg --type java $'List<ConfigChange> calcPropertyChanges'

Length of output: 236

61-68: Constructor updated to include appId.

The constructor has been updated to include the appId parameter. Ensure all calls to this constructor are updated accordingly.

Verification successful

Constructor updated to include appId successfully.

All calls to the DefaultConfig constructor have been updated to include the appId parameter as required.

  • Verified instances in:
    • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistryTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `DefaultConfig` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurrences with the new signature.
rg --type java -A 5 $'new DefaultConfig'

Length of output: 26924

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5)

75-75: Add appId initialization.

The new m_appId field is correctly initialized in the constructor.

191-194: Update loadApolloConfig to use m_appId.

The loadApolloConfig method now uses m_appId. Ensure the logic correctly handles the appId.

336-336: Update submit call to include appId.

The submit method is now called with appId. Ensure consistency in its usage.

93-97: Constructor updated to include appId.

The constructor has been updated to include the appId parameter. Ensure all calls to this constructor are updated accordingly.

Verification successful

Constructor calls updated to include appId.

All instances of the RemoteConfigRepository constructor have been updated to include the appId parameter:

  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `RemoteConfigRepository` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurrences with the new signature.
rg --type java -A 5 $'new RemoteConfigRepository'

Length of output: 8134

160-160: Update fireRepositoryChange call to include appId.

The fireRepositoryChange method is now called with appId. Ensure the method signature matches this change.

Verification successful

The method fireRepositoryChange in AbstractConfigRepository.java does include appId in its signature:

protected void fireRepositoryChange(String appId, String namespace, Properties newProperties) {

The call to fireRepositoryChange in RemoteConfigRepository.java appears to correctly pass m_appId as the first parameter:

this.fireRepositoryChange(m_appId, m_namespace, this.getConfig());

To ensure everything is correctly implemented, let's verify the definition of m_appId within RemoteConfigRepository.java.

Verified: The fireRepositoryChange method call in RemoteConfigRepository.java correctly includes appId as per the method signature in AbstractConfigRepository.java.

  • The m_appId is properly defined and initialized in the RemoteConfigRepository class.
  • The call to fireRepositoryChange correctly passes m_appId as the first parameter.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the method signature of `fireRepositoryChange` to include `appId`.

# Test: Search for the method definition. Expect: Signature includes `appId`.
rg --type java $'protected void fireRepositoryChange'

Length of output: 247

Script:

#!/bin/bash
# Description: Verify the definition and usage of `m_appId` in RemoteConfigRepository.java

# Search for the definition of `m_appId` in RemoteConfigRepository.java
rg 'm_appId' --type java -A 5

# Search for the constructor of `RemoteConfigRepository` to see how `m_appId` is initialized
rg 'public RemoteConfigRepository' --type java -A 10

Length of output: 30555

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (9)

71-73: Use ConcurrentHashMap and Table for managing configurations.

The use of ConcurrentHashMap and Table improves concurrency handling. Ensure thread safety throughout the code.

106-112: Update submit method to include appId.

The submit method is now called with appId. Ensure consistency in its usage.

Line range hint 115-141:
Update startLongPolling method to include appId.

The startLongPolling method is now called with appId. Ensure consistency in its usage.

172-172: Update URL assembly to include appId notifications.

The assembleLongPollRefreshUrl method now includes appId in the notifications. Ensure the URL format is correct.

190-193: Update notify method to include appId.

The notify method is now called with appId. Ensure consistency in its usage.

211-211: Update error logging to include appId.

The error logging now includes appId. This change improves debugging and traceability.

223-236: Update notify method to include appId.

The notify method is now called with appId. Ensure consistency in its usage.

247-260: Update updateNotifications method to include appId.

The updateNotifications method is now called with appId. Ensure consistency in its usage.

286-287: Update assembleNamespaces method to include appId.

The assembleNamespaces method now includes appId. Ensure consistency in its usage.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (8)

148-148: Add appId parameter in test setup.

The RemoteConfigRepository is now instantiated with appId in the test setup. Ensure consistency in all tests.

174-174: Update test to include appId parameter.

The test testLoadConfigWithOrderedProperties has been updated to include appId. Ensure test coverage for the new parameter.

211-211: Update test to include appId parameter.

The test testLoadConfigWithAccessKeySecret has been updated to include appId. Ensure test coverage for the new parameter.

224-224: Update test to include appId parameter.

The test testGetRemoteConfigWithServerError has been updated to include appId. Ensure test coverage for the new parameter.

237-237: Update test to include appId parameter.

The test testGetRemoteConfigWithNotFount has been updated to include appId. Ensure test coverage for the new parameter.

Line range hint 254-265:
Update test to include appId parameter.

The test testRepositoryChangeListener has been updated to include appId. Ensure test coverage for the new parameter.

290-290: Update test to include appId parameter.

The test testLongPollingRefresh has been updated to include appId. Ensure test coverage for the new parameter.

342-342: Update test to include appId parameter.

The test testAssembleQueryConfigUrl has been updated to include appId. Ensure test coverage for the new parameter.

apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (1)

513-518: LGTM! Verify test coverage for the new method.

The getAppSecret method correctly retrieves the app secret based on the given appId. Ensure that there are tests covering this new functionality.

Verification successful

Indirect test coverage for getAppSecret is confirmed.

The method getAppSecret is indirectly tested through various test cases in RemoteConfigRepositoryTest.java, such as testLoadConfigWithAccessKeySecret. This ensures that the functionality is adequately covered.

  • RemoteConfigRepositoryTest.java: Contains tests that indirectly verify the behavior of getAppSecret.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of tests for the getAppSecret method.

# Test: Search for test cases. Expect: Test cases for getAppSecret method.
rg --type java -A 5 'getAppSecret'

Length of output: 2449

Script:

#!/bin/bash
# Description: Search for test classes related to RemoteConfigRepository and RemoteConfigLongPollService to check if getAppSecret is indirectly tested.

# Find test files for RemoteConfigRepository
rg --type java -l 'RemoteConfigRepository' | grep -i 'test'

# Find test files for RemoteConfigLongPollService
rg --type java -l 'RemoteConfigLongPollService' | grep -i 'test'

Length of output: 704

Script:

#!/bin/bash
# Description: Check if getAppSecret is tested indirectly in the test files.

# Search for invocations of getAppSecret in RemoteConfigRepositoryTest.java
rg --type java 'getAppSecret' apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java

# Search for invocations of getAppSecret in RemoteConfigLongPollServiceTest.java
rg --type java 'getAppSecret' apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java

Length of output: 258

Script:

#!/bin/bash
# Description: Examine the contents of the test files to confirm if getAppSecret is indirectly tested.

# Display the contents of RemoteConfigRepositoryTest.java
cat apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java

# Display the contents of RemoteConfigLongPollServiceTest.java
cat apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java

Length of output: 40892

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (2)

457-465: LGTM! The method update is consistent.

The fireConfigChange method now correctly includes appId in the change event handling logic.

Line range hint 570-605:
LGTM! The method update is consistent.

The calcPropertyChanges method now correctly includes appId in the property change calculation logic.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (5)

136-136: LGTM! The test case update is consistent.

The testSubmitLongPollNamespaceWith304Response method now correctly includes appId as a parameter.

187-187: LGTM! The test case update is consistent.

The testSubmitLongPollNamespaceWith200Response method now correctly includes appId as a parameter.

249-249: LGTM! The test case update is consistent.

The testSubmitLongPollNamespaceWithAccessKeySecret method now correctly includes appId as a parameter.

320-323: LGTM! The test case update is consistent.

The testSubmitLongPollMultipleNamespaces method now correctly includes appId as a parameter.

391-392: LGTM! The test case update is consistent.

The testSubmitLongPollMultipleNamespacesWithMultipleNotificationsReturned method now correctly includes appId as a parameter.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java (30)

74-74: Initialize someAppId field

The someAppId field is introduced to support the new constructor signature of DefaultConfig.

95-95: Set someAppId in setup method

Initializing someAppId in the setup method ensures it's available for all tests.

150-150: Update constructor call to include appId

The constructor of DefaultConfig is updated to include appId. Ensure all instances are updated accordingly.

183-183: Update constructor call to include appId

Consistently updating the constructor to include appId.

202-202: Update constructor call to include appId

Ensure consistency in constructor updates.

225-225: Update constructor call to include appId

Constructor update is consistent with the new signature.

256-256: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

288-288: Update constructor call to include appId

Constructor updated to match new signature.

323-323: Update constructor call to include appId

Constructor update is consistent with the new signature.

346-346: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

369-369: Update constructor call to include appId

Constructor updated to match new signature.

392-392: Update constructor call to include appId

Constructor update is consistent with the new signature.

415-415: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

438-438: Update constructor call to include appId

Constructor updated to match new signature.

461-461: Update constructor call to include appId

Constructor update is consistent with the new signature.

485-485: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

521-521: Update constructor call to include appId

Constructor updated to match new signature.

547-547: Update constructor call to include appId

Constructor update is consistent with the new signature.

577-577: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

596-596: Update constructor call to include appId

Constructor updated to match new signature.

614-614: Update constructor call to include appId

Constructor update is consistent with the new signature.

652-652: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

719-719: Update ConfigChangeEvent constructor to include appId

Constructor update is consistent with the new signature.

745-745: Update constructor call to include appId

Constructor updated to match new signature.

805-805: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

840-840: Update constructor call to include appId

Constructor updated to match new signature.

867-867: Update constructor call to include appId

Constructor update is consistent with the new signature.

880-880: Update constructor call to include appId

Constructor update aligns with the new appId parameter.

900-900: Update constructor call to include appId

Constructor updated to match new signature.

926-926: Update constructor call to include appId

Constructor update is consistent with the new signature.

coderabbitai[bot]
coderabbitai bot reviewed Jul 10, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 598e03a and 39d3d86.

Files selected for processing (4)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (9 hunks)
Files skipped from review as they are similar to previous changes (3)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java
Additional comments not posted (8)
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8)

30-31: Imports approved.

The new imports for HashBasedTable and Table from Guava are necessary for the changes in the data structure to support the appId parameter.

64-64: Field type change approved.

The CONFIG_REGISTRY field type change to Table<String, String, Config> is necessary to support the new appId parameter.

90-97: Method update approved.

The prepareConfig method update to include the appId parameter ensures that configurations can be prepared for specific application IDs.

118-124: Method update approved.

The prepareYamlConfigFile method update to include the appId parameter ensures that YAML configuration files can be prepared for specific application IDs.

166-167: Method update approved.

The mockConfig method update to include the appId parameter ensures that configurations can be mocked for specific application IDs.

183-188: Method update approved.

The doSetUp method update to include setup for MockConfigUtil ensures that the configuration utility can be properly mocked for testing.

Line range hint 206-225:
Class update approved.

The MockConfigManager class update to include methods with the appId parameter ensures that the mock configuration manager can handle configurations for specific application IDs.

246-248: Class update approved.

The MockConfigUtil class update to include the getAppId method ensures that the mock configuration utility can provide an application ID for testing.

@nobodyiam
Copy link
Member

Thanks, it may take some time to reivew. In the meantime, could you please sign the CLA following the instructions provided by the CLA Assistant Lite bot?

coderabbitai[bot]
coderabbitai bot reviewed Jul 16, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 39d3d86 and db6f733.

Files selected for processing (16)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (7 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (9 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/integration/ConfigIntegrationTest.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java (30 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepositoryTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (29 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderTest.java (20 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/StringUtils.java (1 hunks)
Files skipped from review due to trivial changes (1)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java
Files skipped from review as they are similar to previous changes (6)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java
Additional comments not posted (24)
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepositoryTest.java (3)

43-43: Addition of appId field.

The addition of the someAppId field aligns with the new requirement to handle multiple appIds. This change is necessary for testing configurations specific to an appId.

51-53: Setup method updates to handle appId.

The setUp method now initializes someAppId and mocks its retrieval. This is crucial for ensuring that the unit tests can simulate scenarios where different appIds are used to fetch configurations.

135-135: Verification of repository change handling with appId.

The testOnChange method now verifies that the onRepositoryChange method is called with the correct appId. This ensures that the repository change events are correctly propagated with the appId context, which is essential for multi-app configurations.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (6)

29-29: Import addition for ConfigConsts.

The addition of ConfigConsts import suggests usage of constants related to configuration, possibly related to appId. This is a good practice as it promotes the use of constants instead of hard-coded values.

84-84: Modification to use appId in config repository creation.

The createConfigRepository method is modified to accept appId, which is essential for creating configurations specific to an application. This change is crucial for supporting multi-tenancy.

99-99: Local configuration repository creation with appId.

The createLocalConfigRepository method now includes appId in its parameters, ensuring that local configurations are associated with the correct application. This is a necessary change for maintaining the integrity of configurations across different applications.

117-119: Creation of PropertiesCompatibleFileConfigRepository with appId.

The method now correctly handles appId when creating a PropertiesCompatibleFileConfigRepository. This ensures that properties files are correctly associated with their respective applications, which is vital for accurate configuration management.

136-138: Multiple local repository creations with appId.

The test now covers scenarios where multiple local repositories are created with different appIds. This is important for testing the factory's ability to handle multiple applications simultaneously.

191-204: Namespace trimming with appId.

The checkNamespaceName method now includes appId in its logic. This is crucial for ensuring that namespace names are correctly processed in the context of an application, preventing potential conflicts or errors in multi-tenant environments.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (1)

109-113: Integration of appId in ApolloConfig processing.

The processApolloConfig method now includes logic to handle appId. This is crucial for ensuring that configurations are fetched and injected based on the correct application identifier, aligning with the multi-tenancy requirements.

apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/StringUtils.java (1)

343-345: Addition of defaultIfBlank method.

The defaultIfBlank method provides a default value if the input string is blank, using appId as the fallback. This utility method is a valuable addition, especially in configurations where default values are needed based on the application context.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (5)

49-49: Addition of appId field.

The addition of the m_appId field is consistent with the PR's objective to handle configurations for multiple apps. Ensure that all usages of this field are correctly implemented across the class.

61-65: Constructor modification to include appId.

The constructor now includes an appId parameter and initializes m_appId. This change is necessary for supporting multiple app configurations. The method loadFromResource has been adapted to use appId which is a good practice to ensure configurations are loaded per app basis.

Also applies to: 68-68

224-225: Method Overloading for onRepositoryChange.

The onRepositoryChange method has been overloaded to include an appId parameter. This is a crucial change to ensure that repository changes are handled per app. The logic inside the method appears to be correct and properly checks for changes before firing a configuration change event.

Also applies to: 227-245

258-258: Calculation of property changes now includes appId.

The method calcPropertyChanges has been updated to include appId. This is important for correctly calculating changes per app. Ensure that this method is used consistently across the class.

Line range hint 309-321: Resource loading adapted for appId.

The method loadFromResource has been adapted to include appId in the resource path. This change ensures that app-specific configurations can be loaded. The error handling and resource stream closure are correctly implemented.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (2)

60-61: Addition of appId constant for testing.

The constant someAppId has been added to use across tests, ensuring consistency when testing multi-app configurations.

96-96: Updated mockConfig calls to include appId.

All mockConfig method calls have been updated to include appId. This change is necessary to ensure that the tests are aligned with the new multi-app support in the Apollo client.

Also applies to: 140-141, 176-180, 218-218, 250-250, 284-284, 317-317, 353-353, 382-382, 414-414

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderTest.java (2)

63-63: Addition of appId constant for testing.

The constant someAppId has been added to use across tests, ensuring consistency when testing multi-app configurations.

74-74: Updated mockConfig and mockConfigFile calls to include appId.

All mockConfig and mockConfigFile method calls have been updated to include appId. This change is necessary to ensure that the tests are aligned with the new multi-app support in the Apollo client.

Also applies to: 82-82, 95-95, 111-111, 127-127, 139-139, 143-143, 161-161, 165-165, 180-180, 184-184, 199-199, 203-203, 217-217, 221-221, 235-235, 254-254, 276-276, 297-297, 315-315, 338-338, 360-360, 378-378, 409-409, 428-428, 436-436

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (4)

Line range hint 22-33: Added imports and annotations are appropriate.

The imports and the new @MultipleConfig annotation align with the changes made to support multiple appId configurations. These changes are necessary for the tests to reflect the new application structure.

79-79: Introduction of someAppId as a constant.

Defining someAppId as a constant is a good practice for reusability and maintainability in tests. This ensures that all test cases use a consistent appId, which is crucial for testing the new multi-app configuration feature.

114-115: Proper use of mockConfig with appId.

The mockConfig method is correctly used with the appId parameter to simulate configuration settings for different applications. This is key to testing the new functionality introduced in the PR.

Also applies to: 117-117

133-133: Consistent application of appId across various test methods.

Throughout the test file, the appId parameter is consistently used in various contexts, ensuring that the new functionality is thoroughly tested. This includes mocks, configuration setups, and assertions. The changes are well-integrated and cover a wide range of scenarios, which is crucial for the robustness of the feature.

Also applies to: 143-145, 159-162, 174-183, 195-196, 210-211, 264-264, 273-273, 283-284, 340-341, 372-372, 398-405, 437-448, 462-469, 493-499, 518-524, 539-544, 563-566, 578-578, 584-587, 594-598, 607-616, 625-625, 639-644, 651-675, 1093-1131

@TerryLam2010
Copy link
Author

I have read the CLA Document and I hereby sign the CLA

@nobodyiam
Copy link
Member

@TerryLam2010 It seems you committed the code with [email protected], which isn't associated with your GitHub account.

nobodyiam
nobodyiam requested changes Jul 20, 2024
View reviewed changes
...ig-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...src/main/java/com/ctrip/framework/apollo/spring/property/AutoUpdateConfigChangeListener.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/property/SpringValue.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java Outdated Show resolved Hide resolved
@Anilople
Copy link
Contributor

The monitor metric #74 maybe changed if support multiple appId @Rawven

@Rawven
Copy link
Contributor

Rawven commented Aug 12, 2024

如果支持多个 appId，监控指标#74可能会改变@Rawven

I'll adapt it after it's merged

coderabbitai[bot]
coderabbitai bot reviewed Aug 14, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range, codebase verification and nitpick comments (5)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1)

73-76: Integration of multipleConfigs() Method Not Evident

The multipleConfigs() method in the EnableApolloConfig annotation is not currently utilized in the codebase. While EnableApolloConfig is used in several places, particularly in test files, there is no evidence of multipleConfigs() being integrated or tested. Consider reviewing the intended use cases and updating the codebase to leverage this new method if necessary.

Analysis chain

LGTM! Verify the integration of multipleConfigs().

The addition of the multipleConfigs() method is well-implemented and enhances flexibility. Ensure that the integration of this method is correctly handled throughout the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the integration of `multipleConfigs()` method across the codebase.

# Test: Search for the usage of `multipleConfigs()` method. Expect: Correct integration throughout the codebase.
rg --type java 'multipleConfigs\(\)'

Length of output: 184

Script:

#!/bin/bash
# Search for references to the EnableApolloConfig class to see if it is used elsewhere.
rg --type java 'EnableApolloConfig'

Length of output: 10994

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (2)

123-125: Document the placeholder method.

The createConfigFile method currently returns null. Consider documenting its placeholder status and any future implementation plans.

+  // TODO: Implement the method or provide documentation on its intended use.

84-86: Update getConfig Method Calls to Match New Signature

The getConfig method calls in the following locations still use the old signature with a single namespace parameter. They need to be updated to include the appId parameter:

  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/importer/ApolloConfigDataLoader.java
  • apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiWhileCacheDirSpecifiedTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/integration/ConfigIntegrationTest.java

Ensure all invocations of getConfig are updated to use the new signature with both appId and namespace.

Analysis chain

LGTM! But verify the function usage in the codebase.

The addition of appId to getConfig enhances configuration specificity. Ensure that all function calls to getConfig match the new signature.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `getConfig` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'getConfig\\(String\\s+appId,\\s+String\\s+namespace\\)'

Length of output: 2477

Script:

#!/bin/bash
# Description: Check all invocations of `getConfig` in the codebase to ensure they match the new signature.

# Search for all `getConfig` calls and display surrounding context to verify parameters.
rg --type java -A 2 'getConfig\('

Length of output: 53637

apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java (1)

119-125: Handle potential null value for m_appId to prevent NullPointerException.

The initialization logic for m_appId does not guarantee a non-null value, which could lead to a NullPointerException in the getAccessKeySecret(String appId) method. Consider adding a null check for m_appId before calling equals.

  • Location: DefaultApplicationProvider.java, method getAccessKeySecret(String appId)
Analysis chain

Ensure consistent access key retrieval logic.

The new method getAccessKeySecret(String appId) enhances flexibility by allowing access key retrieval based on app ID. However, consider handling potential null values for m_appId to prevent NullPointerException.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that `m_appId` is initialized before `getAccessKeySecret(String appId)` is called.

# Test: Search for initialization and usage of `m_appId`. Expect: Proper initialization before usage.
rg --type java 'm_appId' -A 5

Length of output: 31722

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (1)

206-207: Consider implementing appId and namespace logic.

The appIdAndNamespace method currently returns the namespace unchanged. Consider implementing logic to combine appId and namespace if needed.

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between db6f733 and e814053.

Files selected for processing (26)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (8 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (7 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/build/MockInjector.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (7 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (29 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java (1 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/NullProvider.java (1 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java (1 hunks)
Files skipped from review due to trivial changes (1)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/build/MockInjector.java
Additional comments not posted (83)
apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java (1)

50-53: Addition of getAccessKeySecret(String appId) approved.

The new method enhances the interface by providing access to the access key secret for a specific app ID. Ensure that this method is correctly implemented in all classes that implement this interface.

Verify the implementation of this method across the codebase to ensure consistency.

Verification successful

Method Implemented Consistently

The getAccessKeySecret(String appId) method is implemented in the following classes that implement the ApplicationProvider interface:

  • DefaultApplicationProvider
  • NullProvider

This confirms that the method has been consistently implemented across the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the implementation of `getAccessKeySecret(String appId)` in classes implementing `ApplicationProvider`.

# Test: Search for the method implementation. Expect: Implementations in all relevant classes.
ast-grep --lang java --pattern $'class $_ implements ApplicationProvider {
  $$$
  String getAccessKeySecret(String appId) {
    $$$
  }
  $$$
}'

Length of output: 146

Script:

#!/bin/bash
# Find all classes implementing ApplicationProvider and check for the getAccessKeySecret method.
fd -e java -x grep -H 'class .* implements ApplicationProvider' {} | cut -d: -f1 | sort -u | xargs -I {} sh -c 'echo "Checking {}"; grep -q "String getAccessKeySecret(String appId)" {} && echo "Method implemented in {}" || echo "Method not implemented in {}"'

Length of output: 739

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (2)

51-58: Addition of getConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) approved.

The method extends configuration file retrieval capabilities by allowing specification of app ID and namespace. Ensure that this method is correctly implemented and tested.

Verify the implementation and usage of this method across the codebase.

Verification successful

Implementation and Usage Verified

The getConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) method is implemented in the DefaultConfigManager class and is also present in a test class, indicating it is being tested. This confirms the method's implementation and usage in the codebase. No further issues found.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the implementation and usage of `getConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat)`.

# Test: Search for the method implementation and usage. Expect: Implementations and usages in all relevant classes.
ast-grep --lang java --pattern $'class $_ implements ConfigManager {
  $$$
  ConfigFile getConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) {
    $$$
  }
  $$$
}'

Length of output: 772

Script:

#!/bin/bash
# Description: Find the implementation of `getConfigFile` method in classes implementing `ConfigManager`.

# Search for classes implementing `ConfigManager` and having `getConfigFile` method.
ast-grep --lang java --pattern $'class $_ implements ConfigManager {
  $$$
  public ConfigFile getConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat);
  $$$
}'

Length of output: 186

Script:

#!/bin/bash
# Description: Find the usage of `getConfigFile` method across the codebase.

# Search for usages of the `getConfigFile` method.
rg 'getConfigFile\s*\(\s*String\s+appId\s*,\s*String\s+namespace\s*,\s*ConfigFileFormat\s+configFileFormat\s*\)' -A 3

Length of output: 1711

35-41: Addition of getConfig(String appId, String namespace) approved.

The method enhances configuration management by allowing retrieval based on both app ID and namespace. Ensure that this method is correctly implemented and tested.

Verify the implementation and usage of this method across the codebase.

Verification successful

Implementation and Usage of getConfig(String appId, String namespace) Verified

The getConfig(String appId, String namespace) method is implemented and used correctly across the codebase:

  • DefaultConfigManager: Contains the main implementation of the method.
  • ConfigService: Provides a static method that delegates to the ConfigManager implementation.
  • AbstractSpringIntegrationTest: Used for testing purposes.

These implementations ensure the method is integrated into the configuration management workflow.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the implementation and usage of `getConfig(String appId, String namespace)`.

# Test: Search for the method implementation and usage. Expect: Implementations and usages in all relevant classes.
ast-grep --lang java --pattern $'class $_ implements ConfigManager {
  $$$
  Config getConfig(String appId, String namespace) {
    $$$
  }
  $$$
}'

Length of output: 149

Script:

#!/bin/bash
# Search for the implementation of `getConfig(String appId, String namespace)` across the codebase
rg 'Config getConfig\(String appId, String namespace\)' -A 5

Length of output: 2466

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1)

38-44: Addition of default method getAppId() approved.

The method provides a way to retrieve the app ID associated with the config file instance, with a default implementation returning null. Ensure that this method is overridden where necessary.

Verify the usage and overriding of this method across the codebase.

Verification successful

getAppId() Method Usage Verified

The getAppId() method in the ConfigFile interface is overridden in the AbstractConfigFile class, which is the only class implementing ConfigFile. This confirms that the method is appropriately overridden where necessary. No further action is required.

  • Implementations of ConfigFile:
    • AbstractConfigFile (overrides getAppId())
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage and overriding of `getAppId()` in classes implementing `ConfigFile`.

# Test: Search for the method overriding. Expect: Overriding in all relevant classes.
ast-grep --lang java --pattern $'class $_ implements ConfigFile {
  $$$
  @Override
  String getAppId() {
    $$$
  }
  $$$
}'

Length of output: 127

Script:

#!/bin/bash
# Find all classes implementing ConfigFile
ast-grep --lang java --pattern 'class $_ implements ConfigFile { $$$ }' --json | jq -r '.[].matches[].text' > implementing_classes.txt

# Check for getAppId method in these classes
while IFS= read -r class; do
  echo "Checking class: $class"
  ast-grep --lang java --pattern "class $class { $$$ String getAppId() { $$$ } $$$ }"
done < implementing_classes.txt

Length of output: 132

Script:

#!/bin/bash
# Search for any implementation of ConfigFile
rg --no-heading --line-number 'implements ConfigFile' > implementations.txt

# Search for any usage or overriding of getAppId()
rg --no-heading --line-number 'getAppId' > getAppId_usages.txt

# Output the results
echo "Implementations of ConfigFile:"
cat implementations.txt

echo "Usages or overrides of getAppId():"
cat getAppId_usages.txt

Length of output: 10138

apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/NullProvider.java (1)

87-90: Addition of getAccessKeySecret(String appId) aligns with class purpose.

The new method getAccessKeySecret(String appId) returns null, which is consistent with the NullProvider class's role as a default or placeholder implementation. This ensures that the interface contract is fulfilled without altering existing behavior.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (4)

26-26: Introduction of appId field enhances context.

The new appId field provides additional context for configuration file change events, aligning with the PR's objective to support multiple app IDs.

41-43: Constructor updated to include appId.

The constructor now accepts appId, ensuring that instances of ConfigFileChangeEvent are initialized with complete context.

50-52: Addition of getAppId() method.

The getAppId() method provides access to the appId field, improving encapsulation and usability.

73-73: toString() method updated to include appId.

Including appId in the toString() method enhances the string representation of the event, providing more detailed information.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (3)

28-28: Addition of m_appId field enhances context.

The m_appId field provides additional context for configuration change events, aligning with the PR's objective to support multiple app IDs.

36-38: Constructor updated to include appId.

The constructor now includes appId, ensuring that ConfigChangeEvent instances are initialized with complete context.

83-85: Addition of getAppId() method.

The getAppId() method allows retrieval of the appId, enhancing the class's utility.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (1)

27-27: LGTM! Verify the impact of appId integration.

The introduction of the appId field and its integration into the constructor and the new getter method are well-executed. Ensure that existing code using the ConfigChange constructor is updated accordingly.

Also applies to: 43-45, 81-83

Verification successful

Integration of appId Verified in ConfigChange Constructor

The addition of the appId parameter to the ConfigChange constructor has been successfully integrated across the codebase. All instances of ConfigChange creation have been updated to include the appId parameter.

  • Files Updated:
    • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the impact of `appId` integration in the `ConfigChange` constructor across the codebase.

# Test: Search for instantiations of `ConfigChange`. Expect: Updated constructor usage with `appId`.
rg --type java 'new ConfigChange\('

Length of output: 1593

apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1)

45-55: LGTM! Verify the usage of the new constructor.

The addition of the new constructor with appId is well-implemented and maintains backward compatibility. Ensure that the new constructor is used appropriately in the codebase.

Verification successful

Verified Usage of New Constructor

The new constructor for PureApolloConfig with parameters appId, namespace, and configRepository is correctly used in the codebase. It appears in PureApolloConfigFactory.java, and no other constructors are in use, ensuring consistency and correctness.

  • Location of usage: apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfigFactory.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the new `PureApolloConfig` constructor with `appId`.

# Test: Search for instantiations of `PureApolloConfig`. Expect: Usage of both constructors.
rg --type java 'new PureApolloConfig\('

Length of output: 228

Script:

#!/bin/bash
# Description: Search for all instantiations of `PureApolloConfig` to verify constructor usage.

# Test: List all usages of `PureApolloConfig` constructors.
rg --type java 'new PureApolloConfig\(' -A 3

Length of output: 475

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (1)

110-114: Verify the appId validation logic.

Ensure that the validation logic for appId is correct and that it doesn't introduce breaking changes.

Verification successful

Validation logic for appId is correctly implemented.

The validation logic in the create method uses StringUtils.equals to compare the provided appId with the expected one from m_configUtil. If they do not match, an IllegalArgumentException is thrown. This is a standard and correct approach for ensuring appId consistency.

  • The logic is correctly implemented and does not introduce breaking changes.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the appId validation logic in the `create` method.

# Test: Search for the appId validation logic. Expect: Correct comparison and exception handling.
rg --type java -A 5 $'if\\(!StringUtils.equals\\(appId,m_configUtil.getAppId\\(\\)\\)\\)'

Length of output: 699

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (3)

61-63: Constructor changes look good.

The constructor now correctly initializes m_appId alongside other fields.

85-88: Method getAppId looks good.

The method correctly returns the initialized m_appId.

Line range hint 102-125:
Method onRepositoryChange changes look good.

The method now correctly handles configuration changes with the appId parameter.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (3)

45-46: Field initialization for configUtil looks good.

The field is correctly initialized using ApolloInjector.

56-77: Method registerBeanDefinitions changes look good.

The method now correctly handles multiple appIds and resolves secrets, enhancing configuration flexibility.

106-112: Method resolveSecret looks good.

The method correctly resolves secrets and logs warnings for unsupported Spring versions.

apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (8)

68-72: LGTM! Test assertions updated for appId.

The test assertions now correctly incorporate the appId, ensuring that the configuration retrieval logic is validated for the new parameter.

83-83: LGTM! Test assertions updated for appId.

The test assertions now correctly incorporate the appId, ensuring that the configuration factory logic is validated for the new parameter.

95-95: LGTM! Test assertions updated for appId.

The test assertions now correctly incorporate the appId, ensuring that the mock configuration factory logic is validated for the new parameter.

Line range hint 113-127:
LGTM! Constructor and methods updated for appId.

The MockConfig class now correctly incorporates the appId parameter, enhancing the fidelity of mock configurations.

Line range hint 143-157:
LGTM! Constructor updated for appId.

The MockConfigFile class now correctly incorporates the appId parameter, enhancing the fidelity of mock configuration files.

203-218: LGTM! Methods updated for appId.

The MockConfigFactory class methods now correctly incorporate the appId parameter, enhancing the fidelity of mock configuration factories.

49-52: Verify the use of reflection for setting private fields.

Ensure that using reflection to access and modify private fields is necessary and correctly implemented, as it can lead to maintenance challenges.

Verification successful

Reflection usage is isolated and correctly implemented.

The use of reflection to access the m_configUtil field is limited to the ConfigServiceTest.java file, indicating it's specifically for testing purposes. This is a common practice for accessing private fields in tests and is correctly implemented in this context. No further issues found.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the use of reflection for accessing `m_configUtil` in tests.

# Test: Search for occurrences of reflection usage in test files. Expect: Consistent usage.
rg --type java --pattern 'getDeclaredField\("m_configUtil"\)'

Length of output: 475

Script:

#!/bin/bash
# Description: Verify the use of reflection for accessing `m_configUtil` in tests.

# Corrected Test: Search for occurrences of reflection usage in test files. Expect: Consistent usage.
rg 'getDeclaredField\("m_configUtil"\)' --type java

Length of output: 203

169-172: Verify the getAppId method returning null.

Ensure that returning null from the getAppId method is intentional and does not affect the test logic.

Verification successful

The getAppId method returning null is intentional and handled in tests.

The test suite includes assertions that explicitly check for a null return value from the getAppId() method, indicating that this behavior is expected and managed within the test logic.

  • DefaultApplicationProviderTest contains a test case that asserts null as the expected value.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of `getAppId` method in tests.

# Test: Search for calls to `getAppId` in test files. Expect: Handled cases for null return.
rg --type java --pattern '\.getAppId\(\)'

Length of output: 455

Script:

#!/bin/bash
# Corrected: Search for calls to `getAppId` in test files to verify handling of null return.
rg '\.getAppId\(\)' --type java

Length of output: 5923

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (10)

67-68: LGTM! Method updated to use appId.

The create method now correctly delegates to the overloaded version with appId, ensuring consistent configuration creation.

Line range hint 70-91:
LGTM! Method updated to handle appId.

The create method now correctly incorporates the appId parameter, ensuring configurations are created with the correct application context.

93-95: LGTM! Method updated to use appId.

The createConfigFile method now correctly delegates to the overloaded version with appId, ensuring consistent configuration file creation.

98-99: LGTM! Method updated to handle appId.

The createRepositoryConfig method now correctly incorporates the appId parameter, ensuring repository configurations are associated with the correct application context.

103-119: LGTM! Method updated to handle appId.

The createConfigFile method now correctly incorporates the appId parameter, ensuring configuration files are created with the correct application context.

123-127: LGTM! Method updated to handle appId.

The createConfigRepository method now correctly incorporates the appId parameter, ensuring configuration repositories are created with the correct application context.

137-144: LGTM! Method updated to handle appId.

The createLocalConfigRepository method now correctly incorporates the appId parameter, ensuring local configuration repositories are created with the correct application context.

147-148: LGTM! Method updated to handle appId.

The createRemoteConfigRepository method now correctly incorporates the appId parameter, ensuring remote configuration repositories are created with the correct application context.

Line range hint 152-157:
LGTM! Method updated to handle appId.

The createPropertiesCompatibleFileConfigRepository method now correctly incorporates the appId parameter, ensuring properties-compatible file configuration repositories are created with the correct application context.

Line range hint 172-176:
LGTM! Method updated to handle appId.

The trimNamespaceFormat method now correctly incorporates the appId parameter, ensuring namespace formatting is handled with the correct application context.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (3)

59-59: LGTM! Data structure updated for appId.

The APP_NAMESPACE_NAMES field now uses a more complex structure to handle multiple namespaces with specific appIds, enhancing flexibility.

73-79: LGTM! Method updated to handle appId.

The addNamespaces method now correctly incorporates the appId parameter, ensuring namespaces are associated with the correct application context.

102-124: LGTM! Method updated for appId-based configuration retrieval.

The initializePropertySources method now correctly iterates over the new data structure, enhancing the granularity of configuration management.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8)

68-68: Transition to Table for structured configuration storage.

The use of HashBasedTable for CONFIG_REGISTRY allows for more structured storage of configurations associated with both app IDs and namespaces, enhancing flexibility.

94-101: Update method signatures to include appId.

The prepareConfig method now includes appId, improving test configuration management by associating configurations with specific app IDs.

122-130: Enhance YAML configuration handling with appId.

The prepareYamlConfigFile method now accepts appId, ensuring YAML configurations are associated with the correct application context.

170-171: Store configurations using appId and namespace.

The mockConfig method now stores configurations in the CONFIG_REGISTRY using both appId and namespace, aligning with the new table structure.

178-180: Refactor config file mocking to include appId.

The mockConfigFile method now uses appId in its key, ensuring unique identification of config files across different applications.

204-204: Clear configuration registry in teardown.

The doTearDown method clears CONFIG_REGISTRY, ensuring no residual configurations affect subsequent tests.

222-228: Refactor getConfig to use appId.

The getConfig method in MockConfigManager now requires appId, improving configuration retrieval by ensuring the correct application context is used.

Line range hint 236-242: Refactor getConfigFile to use appId.

The getConfigFile method in MockConfigManager now includes appId, aligning file retrieval with the new configuration structure.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (6)

62-62: Initialize someAppId for test clarity.

The someAppId variable is now initialized to "someAppId", enhancing the clarity and context of the tests.

84-84: Update method calls to include appId.

The createConfigRepository method now accepts someAppId, aligning with the updated configuration management logic.

99-99: Refactor local config repository creation with appId.

The createLocalConfigRepository method now includes someAppId, ensuring the test setup reflects the new configuration structure.

117-119: Enhance properties file config repository creation with appId.

The createPropertiesCompatibleFileConfigRepository method now requires someAppId, aligning with the updated configuration logic.

136-138: Update config file creation to include appId.

The createLocalConfigRepository method calls now include someAppId, ensuring the correct application context is used in tests.

191-204: Refactor namespace name checks to include appId.

The checkNamespaceName method now incorporates appId, ensuring comprehensive validation of namespace formatting.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (7)

66-67: LGTM! Constructor changes are appropriate.

The constructor correctly initializes m_appId and delegates to the other constructor.

70-74: Constructor initialization is correct.

The constructor properly initializes all fields and sets up the local cache directory and upstream repository.

133-134: Delegation to overloaded method is correct.

The method correctly delegates to the overloaded version with m_appId.

136-144: Property update and change event handling are correct.

The method correctly updates the file properties and fires the repository change event with appId.

Line range hint 204-237:
File loading logic is correct.

The method correctly handles loading properties from a local cache file using appId and namespace, with proper exception handling.

Line range hint 239-271:
File persistence logic is correct.

The method correctly handles persisting properties to a local cache file using appId and namespace, with proper exception handling.

297-300: File path construction is correct.

The method correctly constructs the file path using appId and namespace.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (4)

67-75: Constructor initialization is correct.

The constructor properly initializes m_appId using ConfigUtil.getAppId() and sets up other fields.

Line range hint 84-92:
Constructor initialization is correct.

The constructor properly initializes all fields using the provided parameters.

243-244: Delegation to overloaded method is correct.

The method correctly delegates to the overloaded version with m_appId.

Line range hint 328-340:
Resource loading logic is correct.

The method correctly handles loading properties from a resource using appId and namespace, with proper exception handling.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (4)

Line range hint 96-114:
Constructor initialization is correct.

The constructor properly initializes m_appId and other fields, and sets up scheduled tasks.

157-160: Config cache update and change event handling are correct.

The method correctly updates the config cache and fires the repository change event with m_appId.

191-194: Config loading logic is correct.

The method correctly handles loading Apollo config using m_appId, with proper exception handling.

336-336: Long polling refresh scheduling is correct.

The method correctly schedules long polling refresh with m_appId.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (5)

Line range hint 115-141:
LGTM!

The inclusion of sysAppId as a parameter in startLongPolling is a necessary change to support multiple app IDs and allows long polling to be scoped by application.

223-236: LGTM!

The addition of the appId parameter in the notify method is appropriate for associating notifications with the correct application.

247-260: LGTM!

The addition of the appId parameter in the updateNotifications method is appropriate for ensuring that notification updates are correctly associated with the respective application.

286-287: LGTM!

The inclusion of the appId parameter in the assembleNamespaces method is necessary for assembling namespaces for a specific application ID.

106-112: LGTM! But verify the function usage in the codebase.

The addition of the appId parameter and the use of Table for m_longPollNamespaces and m_notifications are appropriate for supporting multiple app IDs.

However, ensure that all function calls to submit match the new signature.

Verification successful

Function submit Usage Verified

All instances of the submit function in the codebase match the new signature with appId, namespace, and remoteConfigRepository as arguments.

  • RemoteConfigLongPollServiceTest.java: Multiple calls using the new signature.
  • RemoteConfigRepository.java: Single call using the new signature.

No issues were found regarding the function usage.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `submit` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'submit'

Length of output: 17711

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (3)

60-61: LGTM!

The introduction of the someAppId constant improves maintainability and readability by centralizing the application ID definition.

406-414: LGTM!

The addition of throws Exception to the beforeClass method enhances error handling during the setup phase of tests.

418-418: LGTM!

The addition of throws NoSuchFieldException, IllegalAccessException to the afterClass method enhances error handling during the teardown phase of tests.

apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (1)

513-515: LGTM!

The new method getAccessKeySecret appropriately extends the functionality of ConfigUtil by enabling retrieval of access key secrets for specific app IDs.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (3)

Line range hint 22-32: Imports look good.

The addition of MockInjector and MultipleConfig imports is appropriate for the new functionality.

651-675: New test method testApolloMultipleConfig looks good.

The method effectively tests multiple configurations for different app IDs and namespaces.

1094-1131: New configuration class TestApolloMultipleConfig and bean TestApolloConfigBean5 look good.

These additions support testing multiple app IDs and namespaces.

coderabbitai[bot]
coderabbitai bot reviewed Aug 14, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between e814053 and 649b054.

Files selected for processing (5)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (9 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (14 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (29 hunks)
Additional comments not posted (28)
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (6)

94-101: LGTM!

The integration of appId into the prepareConfig method is consistent with the PR's objectives and enhances configuration handling.

122-130: LGTM!

The addition of appId to the prepareYamlConfigFile method is well-implemented and aligns with the PR's objectives.

170-171: LGTM!

The use of appId in the mockConfig method is appropriate and enhances the flexibility of configuration management.

178-180: LGTM!

The addition of appId to the mockConfigFile method and the use of a composite key enhance configuration management.

223-228: LGTM!

The integration of appId into the getConfig method in MockConfigManager is well-implemented and aligns with the PR's objectives.

Line range hint 237-242:
LGTM!

The addition of appId to the getConfigFile method in MockConfigManager enhances the retrieval process for configuration files.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (1)

109-113: LGTM!

The integration of appId in the processApolloConfig method enhances configuration retrieval and aligns with the PR's objectives.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (7)

155-155: LGTM!

The test case testLoadConfig correctly incorporates someAppId in the RemoteConfigRepository instantiation, aligning with the updated configuration handling.

181-181: LGTM!

The test case testLoadConfigWithOrderedProperties correctly uses someAppId in the RemoteConfigRepository instantiation, ensuring proper testing of ordered properties.

218-218: LGTM!

The test case testLoadConfigWithAccessKeySecret correctly incorporates someAppId in the RemoteConfigRepository instantiation, aligning with the updated configuration handling.

231-231: LGTM!

The test case testGetRemoteConfigWithServerError correctly uses someAppId in the RemoteConfigRepository instantiation, ensuring proper error handling testing.

244-244: LGTM!

The test case testGetRemoteConfigWithNotFount correctly incorporates someAppId in the RemoteConfigRepository instantiation, aligning with the updated configuration handling.

Line range hint 261-272:
LGTM!

The test case testRepositoryChangeListener correctly verifies onRepositoryChange with someAppId, ensuring proper testing of repository change notifications.

Line range hint 295-321:
LGTM!

The test case testLongPollingRefresh correctly verifies onRepositoryChange with someAppId, ensuring proper testing of long polling refresh.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (5)

194-194: LGTM!

The addition of the appId parameter to the submit method call is consistent with the changes in other test cases.

256-256: LGTM!

The addition of the appId parameter to the submit method call is consistent with the changes in other test cases.

327-330: LGTM!

The addition of the appId parameter to the submit method calls for multiple namespaces is consistent with the changes in other test cases.

398-399: LGTM!

The addition of the appId parameter to the submit method calls for multiple namespaces with multiple notifications is consistent with the changes in other test cases.

143-143: LGTM! Verify submit method usage with appId.

The addition of the appId parameter to the submit method call is consistent with the PR objectives.

Ensure that all submit method calls in the codebase correctly include the appId parameter.

Verification successful

Let's correct the regex pattern error and re-run the script to verify the usage of the submit method with the appId parameter.

Verification Successful: submit Method Usage Consistent

The submit method calls across the codebase correctly include the appId parameter, aligning with the intended changes. No issues found.

  • RemoteConfigLongPollService.java: The submit method is defined with appId.
  • RemoteConfigLongPollServiceTest.java: Test cases consistently use appId.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all `submit` method calls include the `appId` parameter.

# Test: Search for `submit` method usage. Expect: Occurrences with the `appId` parameter.
rg --type java -A 2 $'submit('

Length of output: 96

Script:

#!/bin/bash
# Description: Verify all `submit` method calls include the `appId` parameter.

# Test: Search for `submit` method usage. Expect: Occurrences with the `appId` parameter.
rg --type java -A 2 'submit\('

Length of output: 6210

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (9)

116-119: LGTM!

The addition of someAppId to the mockConfig and prepareYamlConfigFile method calls is consistent with the PR objectives.

135-135: LGTM!

The addition of someAppId to the mockConfig method call is consistent with the changes in other test cases.

145-147: LGTM!

The addition of someAppId to the mockConfig and prepareYamlConfigFile method calls is consistent with the changes in other test cases.

161-164: LGTM!

The addition of someAppId to the mockConfig method call is consistent with the changes in other test cases.

Line range hint 176-185:
LGTM!

The addition of someAppId to the mockConfig method calls is consistent with the changes in other test cases.

197-198: LGTM!

The addition of someAppId to the mockConfig method calls is consistent with the changes in other test cases.

212-213: LGTM!

The addition of someAppId to the mockConfig method calls is consistent with the changes in other test cases.

266-266: LGTM!

The addition of someAppId to the mockConfig method call is consistent with the changes in other test cases.

660-684: LGTM!

The new test method testApolloMultipleConfig effectively tests multiple configurations for different app IDs and namespaces, aligning with the PR objectives.

coderabbitai[bot]
coderabbitai bot reviewed Aug 14, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 649b054 and 7e6b56a.

Files selected for processing (4)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (15 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java (2 hunks)
Files skipped from review as they are similar to previous changes (3)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java
Additional comments not posted (8)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (8)

72-73: Good use of Table for structured data management.

The transition to using Table for m_longPollNamespaces and m_notifications is a suitable choice for managing multiple app IDs and namespaces. This enhances the capability to associate multiple values with a single key in a structured manner.

95-96: Thread-safe initialization of Table data structures.

The use of Tables.synchronizedTable for m_longPollNamespaces and m_notifications ensures thread safety, which is essential for the concurrent nature of this service.

106-112: Correct handling of appId in submit method.

The submit method appropriately handles the appId parameter, updating the Table data structures and initiating long polling if necessary.

Line range hint 115-141:
Efficient management of long polling state with appId.

The startLongPolling method effectively uses the sysAppId to manage the long polling state, ensuring that polling is only initiated once per appId.

Line range hint 172-211:
Proper integration of appId in long polling logic.

The doLongPollingRefresh method correctly incorporates the appId into its URL assembly and notification handling logic, ensuring operations are scoped to the correct application.

223-236: Correct use of appId in notification logic.

The notify method effectively uses the appId to retrieve the appropriate RemoteConfigRepository instances and notify them of changes.

247-260: Appropriate update of notifications with appId.

The updateNotifications method correctly updates the notification IDs for the given appId and namespace, ensuring accurate tracking of changes.

286-287: Correct assembly of namespaces with appId.

The assembleNamespaces method correctly assembles the namespaces for the specified appId, ensuring accurate representation of the data.

@TerryLam2010
Copy link
Author

I have changed the Email for submitting code to [email protected], and changed the name to TerryLam2010. Have not submitted open source request merge before,help me please....

nobodyiam
nobodyiam reviewed Aug 17, 2024
View reviewed changes
Copy link
Member

@nobodyiam nobodyiam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your hard work on this significant change. Here are a few comments for your review.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java Outdated Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java Outdated Show resolved Hide resolved
coderabbitai[bot]
coderabbitai bot reviewed Aug 26, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

Outside diff range, codebase verification and nitpick comments (3)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (2)

Update method calls to match the new signature

The onRepositoryChange method is being called with both the new and old signatures across the codebase. Ensure all calls are updated to match the new signature: onRepositoryChange(String appId, String namespace, Properties newProperties), unless there is a specific reason to maintain both versions.

  • Files with old signature usage:
    • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderAutoUpdateTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderAutoUpdateTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java
Analysis chain

Line range hint 116-136: LGTM! But verify the method usage in the codebase.

The method is correctly implemented. However, ensure that all method calls to onRepositoryChange match the new signature.

The code changes are approved.

Run the following script to verify the method usage:

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all method calls to `onRepositoryChange` match the new signature.

# Test: Search for the method usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'onRepositoryChange'

Length of output: 63127

113-114: Inconsistent method signature usage detected

The onRepositoryChange method is being called with both the new and old signatures across the codebase. Ensure that all calls to this method are updated to use the new signature, which includes the appId parameter, to prevent potential runtime errors or unexpected behavior.

  • Files with old signature usage:
    • JsonConfigFileTest.java
    • YamlConfigFileTest.java
    • XmlConfigFileTest.java
    • DefaultConfigTest.java
    • PropertiesConfigFileTest.java
    • JavaConfigPlaceholderAutoUpdateTest.java

Please update these instances to use the new method signature.

Analysis chain

LGTM! But verify the method usage in the codebase.

The method is correctly implemented. However, ensure that all method calls to onRepositoryChange match the new signature.

The code changes are approved.

Run the following script to verify the method usage:

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all method calls to `onRepositoryChange` match the new signature.

# Test: Search for the method usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'onRepositoryChange'

Length of output: 63127

apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (1)

Line range hint 143-172: Fix the getAppId method.

The getAppId method should return the actual appId instead of null.

Apply this diff to fix the getAppId method:

-  return null;
+  return m_appId;
Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 7e6b56a and ed8ba9b.

Files selected for processing (17)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (8 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (5 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (15 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (29 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (6 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java (1 hunks)
Additional comments not posted (58)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (1)

52-57: LGTM!

The addition of the appId parameter enhances the flexibility of the annotation. The parameter is well-documented with a brief description and version information.

The code changes are approved.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (2)

33-37: LGTM!

The constructor correctly initializes ConfigUtil and ConfigRegistry.

The code changes are approved.

42-46: LGTM!

The changes improve the flexibility of factory retrieval by making it context-aware based on appId. The logic within getFactory(String appId, String namespace) is well-structured.

The code changes are approved.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1)

38-46: LGTM!

The addition of the getAppId method enhances the interface by providing a standardized way to retrieve the appId. The default implementation ensures backward compatibility.

The code changes are approved.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1)

72-78: LGTM!

The addition of the multipleConfigs method enhances the configurability of the interface by allowing for more flexible application settings related to multiple configurations. The default value ensures backward compatibility.

The code changes are approved.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3)

100-127: LGTM! But verify the method usage in the codebase.

The method is correctly implemented. However, ensure that all method calls to setConfig match the new signature.

The code changes are approved.

Run the following script to verify the method usage:

Verification successful

Method Signature Change Verified

The setConfig method calls in the codebase match the new signature. The relevant test file confirms the correct usage. No discrepancies found.

  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java: Correct usage of setConfig.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all method calls to `setConfig` match the new signature.

# Test: Search for the method usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'setConfig'

Length of output: 10715

82-84: LGTM! But verify the method usage in the codebase.

The method is correctly implemented. However, ensure that all method calls to getConfig match the new signature.

The code changes are approved.

Run the following script to verify the method usage:

111-116: LGTM! But verify the method usage in the codebase.

The method is correctly implemented. However, ensure that all method calls to create match the new signature.

The code changes are approved.

Run the following script to verify the method usage:

Verification successful

Method Implementation and Usage Verified

The create(String appId, String namespace) method is correctly implemented in ConfigService.java and used with the expected signature in the codebase.

  • Method Definition: Found in apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java
  • Relevant Usage: Found in apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all method calls to `create` match the new signature.

# Test: Search for the method usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'create'

Length of output: 176808

Script:

#!/bin/bash
# Search for the specific `create(String appId, String namespace)` method implementation in the `ConfigService` class.
ast-grep --lang java --pattern $'class ConfigService {
  $$$
  public Config create(String appId, String namespace) {
    $$$
  }
  $$$  
}'

# Search for the usage of `create(String appId, String namespace)` method across the codebase.
ast-grep --lang java --pattern $'$_.$create($_, $_)' --pattern-insensitive

Length of output: 420

Script:

#!/bin/bash
# Corrected search for the specific `create(String appId, String namespace)` method implementation in the `ConfigService` class.
ast-grep --lang java --pattern $'class ConfigService {
  $$$
  public Config create(String appId, String namespace) {
    $$$
  }
  $$$  
}'

# Corrected search for the usage of `create(String appId, String namespace)` method across the codebase.
ast-grep --lang java --pattern $'$_.$create($_, $_)'

Length of output: 195

Script:

#!/bin/bash
# Search for the `create(String appId, String namespace)` method definition in the `ConfigService` class.
rg --type java 'public Config create\(String appId, String namespace\)'

# Search for the usage of `create(String appId, String namespace)` method across the codebase.
rg --type java '\.create\([^\)]*, [^\)]*\)'

Length of output: 2870

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (2)

57-58: LGTM! But verify the constructor usage in the codebase.

The constructor is correctly implemented. However, ensure that all constructor calls to SimpleConfig match the new signature.

The code changes are approved.

Run the following script to verify the constructor usage:

Verification successful

Constructor usage is consistent with the new signature.

The codebase correctly uses the new constructor signature for SimpleConfig, ensuring that all instances are created with the required parameters: appId, namespace, and configRepository. No instances of the old constructor signature were found.

  • Ensure that any future changes maintain this consistency.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `SimpleConfig` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'SimpleConfig'

Length of output: 46705

67-70: LGTM! But verify the constructor usage in the codebase.

The constructor is correctly implemented. However, ensure that all constructor calls to SimpleConfig match the new signature.

The code changes are approved.

Run the following script to verify the constructor usage:

Verification successful

Constructor Usage Verified: All instances align with the new signature.

The SimpleConfig constructor is correctly used across the codebase, particularly through the prepareConfig method in tests, ensuring alignment with the new signature.

  • AbstractSpringIntegrationTest.java: prepareConfig method correctly implements the new constructor signature.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `SimpleConfig` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'SimpleConfig'

Length of output: 46705

Script:

#!/bin/bash
# Description: Locate the implementation of the `prepareConfig` method to verify its correctness.

# Search for the implementation of the `prepareConfig` method in Java files.
rg --type java -A 5 'prepareConfig'

Length of output: 38742

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (4)

58-58: LGTM!

The method is correctly implemented.

The code changes are approved.

86-87: LGTM!

The method is correctly implemented.

The code changes are approved.

116-116: LGTM!

The method is correctly implemented.

The code changes are approved.

161-161: LGTM!

The method is correctly implemented.

The code changes are approved.

apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (6)

45-53: LGTM!

The setUp method correctly initializes someAppId and sets up a mock ConfigUtil.

The code changes are approved.

68-72: LGTM!

The testHackConfig method correctly tests the configuration with the new appId parameter.

The code changes are approved.

83-83: LGTM!

The testHackConfigFactory method correctly tests the configuration factory with the new appId parameter.

The code changes are approved.

95-95: LGTM!

The testMockConfigFactory method correctly tests the mock configuration factory with the new appId parameter.

The code changes are approved.

104-104: LGTM!

The testMockConfigFactoryForConfigFile method correctly tests the mock configuration factory for config files with the new appId parameter.

The code changes are approved.

Line range hint 113-127: LGTM!

The MockConfig class correctly integrates the appId parameter and updates the getProperty method to reflect this change.

The code changes are approved.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (5)

59-59: LGTM!

The static field APP_NAMESPACE_NAMES correctly represents the namespaces associated with specific application IDs.

The code changes are approved.

69-76: LGTM!

The addNamespaces method correctly updates the namespace management to accommodate multiple application IDs.

The code changes are approved.

99-121: LGTM!

The initializePropertySources method correctly updates the property source initialization to accommodate multiple application IDs.

The code changes are approved.

173-173: LGTM!

The reset method correctly updates the reset logic to accommodate the new data structure.

The code changes are approved.

78-78: LGTM!

The postProcessBeanFactory method correctly updates the bean factory post-processing to accommodate the new data structure and configuration logic.

The code changes are approved.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (7)

68-68: LGTM!

The static field CONFIG_REGISTRY correctly represents the configurations associated with specific application IDs and namespaces.

The code changes are approved.

94-101: LGTM!

The prepareConfig method correctly updates the configuration preparation to accommodate the new appId parameter.

The code changes are approved.

122-130: LGTM!

The prepareYamlConfigFile method correctly updates the YAML configuration file preparation to accommodate the new appId parameter.

The code changes are approved.

170-171: LGTM!

The mockConfig method correctly updates the configuration mocking to accommodate the new appId parameter.

The code changes are approved.

178-180: LGTM!

The mockConfigFile method correctly updates the configuration file mocking to accommodate the new appId parameter.

The code changes are approved.

Line range hint 182-201: LGTM!

The doSetUp method correctly updates the setup logic to accommodate the new appId parameter and configuration logic.

The code changes are approved.

219-238: LGTM!

The MockConfigManager class correctly updates the configuration management to accommodate the new appId parameter.

The code changes are approved.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (6)

70-71: LGTM!

The constructor correctly calls another constructor with the appId parameter.

The code changes are approved.

80-85: LGTM!

The constructor correctly initializes the class variables with the appId parameter.

The code changes are approved.

239-240: LGTM!

The method correctly calls the overloaded method with the appId parameter.

The code changes are approved.

Line range hint 243-260: LGTM!

The method correctly handles the repository change with the appId parameter.

The code changes are approved.

273-273: LGTM!

The method correctly calculates and updates the configuration changes with the appId parameter.

The code changes are approved.

Line range hint 324-336: LGTM!

The method correctly loads properties from the resource file with the appId and namespace.

The code changes are approved.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (6)

93-96: LGTM!

The constructor correctly initializes the class variables with ConcurrentHashMap and Table.

The code changes are approved.

106-112: LGTM!

The method correctly handles the submission with the appId parameter.

The code changes are approved.

Line range hint 115-145: LGTM!

The method correctly handles the long polling start with the sysAppId parameter.

The code changes are approved.

Line range hint 176-215: LGTM!

The method correctly handles the long polling refresh with the appId parameter.

The code changes are approved.

227-240: LGTM!

The method correctly handles the notifications with the appId parameter.

The code changes are approved.

251-264: LGTM!

The method correctly handles the notification updates with the appId parameter.

The code changes are approved.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (6)

Line range hint 106-135: LGTM!

The method correctly initializes the test setup with the appId parameter.

The code changes are approved.

155-155: LGTM!

The test method correctly tests the configuration loading with the appId parameter.

The code changes are approved.

181-181: LGTM!

The test method correctly tests the configuration loading with ordered properties and the appId parameter.

The code changes are approved.

218-218: LGTM!

The test method correctly tests the configuration loading with access key secret and the appId parameter.

The code changes are approved.

231-231: LGTM!

The test method correctly tests the exception handling with the appId parameter.

The code changes are approved.

Line range hint 261-272: LGTM!

The test method correctly tests the repository change listener with the appId parameter.

The code changes are approved.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (7)

87-91: LGTM!

The setUp method correctly initializes the test environment with someAppId and sets the system property for APP_ID.

The code changes are approved.

149-149: LGTM!

The test correctly includes someAppId in the submit method call and verifies the URL contains the correct appId.

The code changes are approved.

200-200: LGTM!

The test correctly includes someAppId in the submit method call and verifies the correct processing of notifications.

The code changes are approved.

262-263: LGTM!

The test correctly includes someAppId in the submit method call and verifies the request headers contain the necessary authentication information.

The code changes are approved.

333-336: LGTM!

The test correctly includes someAppId in the submit method calls for multiple namespaces and verifies the correct processing of notifications for each namespace.

The code changes are approved.

404-405: LGTM!

The test correctly includes someAppId in the submit method calls for multiple namespaces with multiple notifications and verifies the correct processing of notifications for each namespace.

The code changes are approved.

465-465: LGTM!

The test correctly includes someAppId in the submit method call and verifies the correct processing and updating of notifications.

The code changes are approved.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (1)

660-684: LGTM!

The test correctly handles multiple configurations with multiple app IDs and verifies the correct configurations are returned for each app ID and namespace.

The code changes are approved.

apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Show resolved Hide resolved
@nobodyiam
Copy link
Member

I have changed the Email for submitting code to [email protected], and changed the name to TerryLam2010. Have not submitted open source request merge before,help me please....

emm...You may first backup the local repo and try the following:

1. git checkout main
2. git checkout -b 20240703-apollo-multiple-appid-new
3. git merge --squash 20240703-apollo-multiple-appid
4. git commit -m "some commit message"
5. git push origin 20240703-apollo-multiple-appid-new:20240703-apollo-multiple-appid

nobodyiam
nobodyiam requested changes Aug 31, 2024
View reviewed changes
Copy link
Member

@nobodyiam nobodyiam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks significantly better now. Please see some comments below:

...ig-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java Outdated Show resolved Hide resolved
...ig-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java Outdated Show resolved Hide resolved
...ig-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java Outdated Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
.../src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java Outdated Show resolved Hide resolved
coderabbitai[bot]
coderabbitai bot reviewed Sep 5, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 13

Outside diff range, codebase verification and nitpick comments (10)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (4)

21-30: Enhance Annotation Documentation

Consider adding more details about how MultipleConfig interacts with @EnableApolloConfig to provide clearer guidance for developers.

32-36: Enhance appId Method Documentation

The documentation for the appId method should include more details about what constitutes an "appId" and how it should be formatted or used.

38-42: Enhance namespaces Method Documentation

The documentation for the namespaces method should include more details about the purpose of namespaces and examples of typical values.

44-50: Enhance secret Method Documentation

The documentation for the secret method should include more details about the significance of the secret, its typical use cases, and implications of not configuring it.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (1)

47-53: Approved new register method with a suggestion.

The method correctly handles potential conflicts by logging a warning. Consider adding more detailed logging or metrics to track how often conflicts occur, which could be useful for monitoring and debugging.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (1)

Line range hint 48-73: Implementation of getFactory(String appId, String namespace):

The method's implementation is robust, covering various scenarios:

  1. It first checks for a "hacked" factory specific to the app ID and namespace.
  2. It checks the cache implemented using HashBasedTable.
  3. It attempts to retrieve a declared config factory.
  4. It falls back to a default config factory if none are found.

The method ensures that the factory is never null by the end, which is crucial for avoiding null pointer exceptions. However, consider adding explicit logging or an exception throw if the factory is still null after all checks, to improve error handling and debuggability.

Consider enhancing error handling by adding logging or throwing an exception if no factory is found:

if (factory == null) {
    logger.error("No ConfigFactory found for appId: {}, namespace: {}", appId, namespace);
    throw new IllegalStateException("No ConfigFactory found for appId: " + appId + ", namespace: " + namespace);
}
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (1)

Line range hint 119-139: Approved: Handling of appId in onRepositoryChange.

The method's logic to handle configuration changes based on the specified appId is correctly implemented. However, consider adding more detailed logging for debugging purposes, especially to trace how different appIds affect the configuration changes.

apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (1)

68-68: Inconsistent use of appId across test methods.

The testHackConfig method uses the someAppId parameter, but other methods like testHackConfigFactory, testMockConfigFactory, and testMockConfigFactoryForConfigFile do not. This inconsistency may lead to incomplete test coverage if the goal is to validate behavior across different app IDs. Consider reviewing these methods to ensure they align with the intended test scenarios.

  • testHackConfig uses someAppId.
  • testHackConfigFactory, testMockConfigFactory, and testMockConfigFactoryForConfigFile do not use someAppId.
Analysis chain

Ensure consistency in the use of appId across test methods.

The addition of appId in the test methods testHackConfig, testHackConfigFactory, and testMockConfigFactory is consistent with the PR's objective to handle multiple app IDs. However, ensure that all related test methods and classes are updated accordingly to maintain consistency across the entire test suite.

Also applies to: 72-72, 83-83, 95-95

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all test methods in ConfigServiceTest.java use the `appId` parameter consistently.

# Test: Search for test methods that might not be using the `appId` parameter.
rg --type java -A 5 $'public void test' apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java

Length of output: 1217

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (2)

Line range hint 128-154: Ensure robust error handling in startLongPolling.

The method startLongPolling has been adapted to handle app-specific long polling. The use of putIfAbsent for m_longPollStarted is appropriate for concurrency control. However, the error handling could be improved by ensuring that any exceptions caught are properly logged and handled to prevent the long polling service from terminating unexpectedly.

Consider adding more detailed logging and a more robust exception handling strategy:

catch (Throwable ex) {
  m_longPollStarted.remove(sysAppId);
  ApolloConfigException exception = new ApolloConfigException("Schedule long polling refresh failed", ex);
+ logger.error("Failed to schedule long polling for appId: {}", sysAppId, ex);
  Tracer.logError(exception);
  logger.warn(ExceptionUtil.getDetailMessage(exception));
}

This enhancement ensures that all exceptions are adequately logged, providing better visibility into issues that occur during the scheduling of long polling.

Line range hint 185-206: Optimize the long polling refresh logic.

The doLongPollingRefresh method handles the core functionality of long polling. The method is well-structured to handle different scenarios and responses. However, the handling of the 304 status code could be improved to ensure that the service descriptor (lastServiceDto) is reset more reliably.

Consider refining the condition for resetting lastServiceDto:

if (response.getStatusCode() == 304 && ThreadLocalRandom.current().nextBoolean()) {
- lastServiceDto = null;
+ if (shouldResetServiceDescriptor()) {
+   lastServiceDto = null;
+ }
}

Introducing a method shouldResetServiceDescriptor allows for more controlled and testable conditions for when the service descriptor should be reset, improving the reliability of the long polling mechanism.

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between ed8ba9b and 132e2b7.

Files selected for processing (22)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (7 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (8 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java (3 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (3 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2 hunks)
Additional comments not posted (69)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java (1)

27-28: Constructor Modification: Addition of appId Parameter

The constructor now includes an appId parameter, which is a significant change aligning with the project's goal to support multiple app IDs. This change is correctly implemented as the appId is passed to the superclass constructor, ensuring that the AbstractConfigFile can utilize this new parameter.

However, it's crucial to verify that all existing usages of this constructor in the codebase have been updated to include the new appId parameter to prevent runtime errors.

Verification successful

Constructor Change Verified: appId Parameter Propagation

The addition of the appId parameter to the PlainTextConfigFile constructor has been correctly propagated to all its subclasses (XmlConfigFile, TxtConfigFile, JsonConfigFile, YamlConfigFile). Each subclass constructor includes the appId parameter, ensuring consistency and preventing potential runtime errors.

  • XmlConfigFile: public XmlConfigFile(String appId, String namespace, ...)
  • TxtConfigFile: public TxtConfigFile(String appId, String namespace, ConfigRepository configRepository)
  • JsonConfigFile: public JsonConfigFile(String appId, String namespace, ...)
  • YamlConfigFile: public YamlConfigFile(String appId, String namespace, ConfigRepository configRepository)
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `PlainTextConfigFile` include the new `appId` parameter.

# Test: Search for the constructor usage. Expect: Only occurrences with three parameters.
rg --type java -A 5 $'new PlainTextConfigFile'

Length of output: 47

Script:

#!/bin/bash
# Description: Search for all usages of the `PlainTextConfigFile` class to verify constructor usage.

# Test: Search for any references to `PlainTextConfigFile` in the codebase.
rg --type java 'PlainTextConfigFile'

Length of output: 995

Script:

#!/bin/bash
# Description: Search for constructors in subclasses of `PlainTextConfigFile` to verify if `appId` is passed correctly.

# Test: Search for constructors in subclasses of `PlainTextConfigFile`.
rg --type java -A 5 $'class XmlConfigFile {\n  public XmlConfigFile'
rg --type java -A 5 $'class TxtConfigFile {\n  public TxtConfigFile'
rg --type java -A 5 $'class JsonConfigFile {\n  public JsonConfigFile'
rg --type java -A 5 $'class YamlConfigFile {\n  public YamlConfigFile'

Length of output: 1443

Script:

#!/bin/bash
# Description: Search for constructors in subclasses of `PlainTextConfigFile` to verify if `appId` is passed correctly.

# Test: Search for constructors in subclasses of `PlainTextConfigFile`.
rg --type java 'public XmlConfigFile'
rg --type java 'public TxtConfigFile'
rg --type java 'public JsonConfigFile'
rg --type java 'public YamlConfigFile'

Length of output: 795

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1)

1-17: Header and Package Declaration Approved

The file header, including copyright and licensing information, and the package declaration are correctly formatted.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (2)

52-58: Approved: Addition of appId attribute to ApolloConfig.

The addition of the appId attribute aligns with the PR objectives and enhances configuration flexibility. The documentation is clear and specifies the version introduction. This change is consistent with the suggestions from previous reviews.

52-58: Verify the integration of the new appId attribute across the codebase.

Ensure that the new appId attribute is correctly integrated and utilized in relevant parts of the codebase.

Run the following script to verify the usage of the appId attribute:

Verification successful

The appId attribute is correctly integrated across the codebase.

The appId attribute in the ApolloConfig annotation is utilized in the ApolloAnnotationProcessor class, which processes the annotation, indicating its integration into the application logic. Additionally, its presence in various DTOs and test files confirms its usage and testing. No further action is required.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the `appId` attribute in the ApolloConfig annotation across the codebase.

# Test: Search for the usage of the `appId` attribute. Expect: Proper integration and usage.
rg --type java -A 5 $'@ApolloConfig\\(.*appId.*\\)'

Length of output: 851

Script:

#!/bin/bash
# Description: Verify the usage of the `appId` attribute in the main codebase.

# Test: Search for the usage of the `appId` attribute in the main codebase. Expect: Proper integration and usage.
rg --type java -A 5 'appId\s*='

Length of output: 38709

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (2)

34-40: Review of the new getConfig method with appId support.

The addition of the getConfig(String appId, String namespace) method is well-documented and aligns with the PR's objective to support multiple app IDs. The method signature and JavaDoc are clear and concise.

  • Correctness: The method signature correctly takes appId and namespace as parameters, which is consistent with the PR's description.
  • Documentation: The JavaDoc is appropriately detailed, providing clear information on what the method does and its parameters.

50-57: Review of the new getConfigFile method with appId support.

The addition of the getConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) method extends the functionality to fetch configuration files for specific app IDs and namespaces. This method is crucial for environments where multiple applications might share configurations but need distinct setups.

  • Correctness: The method signature is correct and includes all necessary parameters (appId, namespace, configFileFormat).
  • Documentation: The JavaDoc is well-written, clearly explaining the purpose of the method and the parameters it accepts.
apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (4)

19-23: Approved import changes.

The new imports are necessary for handling the new appId functionality and concurrency control with Table.

32-37: Approved class setup and instance variables.

The use of ConfigUtil to fetch the appId and a synchronized table for storing ConfigFactory instances ensures thread safety and supports the new functionality.

44-45: Approved method delegation for backward compatibility.

The register method now correctly delegates to the new method accepting appId, ensuring backward compatibility.

58-63: Approved method changes for getFactory.

The changes to getFactory methods are consistent with the new functionality and maintain backward compatibility by using the default appId.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (3)

19-20: Review of Imports:

The addition of HashBasedTable and Table from Guava and the import of ConfigUtil are appropriate given the changes to support multiple app IDs. Ensure that Maps is still used elsewhere in the project, or consider removing it if it's no longer needed.

Also applies to: 24-24

33-35: Initialization of New Members:

The introduction of m_factories as a HashBasedTable and m_configUtil is well-aligned with the new requirements for handling multiple app IDs. The instantiation of m_configUtil in the constructor ensures that the application ID can be dynamically retrieved, which is crucial for the new logic.

Also applies to: 39-39

44-45: Refactor of getFactory(String namespace):

The method now delegates to the new getFactory(String appId, String namespace) by fetching the app ID using m_configUtil. This is a clean and efficient way to integrate the new functionality without duplicating code.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (3)

28-28: Field addition approved: m_appId.

The addition of the m_appId field is correctly implemented as a private final String, ensuring immutability and thread safety.

36-38: Constructor modification approved.

The updated constructor now correctly includes the appId parameter and initializes the m_appId field along with m_namespace and m_changes. This change supports the new functionality of handling multiple app IDs effectively.

78-84: New method addition approved: getAppId().

The addition of the getAppId() method is correctly implemented to provide external access to the m_appId field, adhering to Java's encapsulation principles.

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (3)

27-27: Field addition approved.

The addition of the appId field is crucial for supporting multiple app IDs and is correctly declared as private final for immutability.

43-45: Constructor modification approved.

The modification to include appId as the first parameter in the constructor is logical and necessary for initializing the new field correctly.

80-82: Getter method addition approved.

The addition of the getAppId method is essential for providing external access to the appId field, enhancing the class's functionality.

apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1)

42-52: Well-implemented new constructor with appId.

The addition of the appId parameter in the constructor enhances the configuration management capabilities as intended. The constructor is well-documented and correctly initializes the superclass with the new parameter.

Please ensure that all integrations and usages of this new constructor are updated across the codebase to reflect the new parameter. This can be verified by searching for instances of PureApolloConfig instantiation and checking if they now include the appId parameter.

Verification successful

New constructor usage verified in PureApolloConfigFactory.

The instantiation of PureApolloConfig in PureApolloConfigFactory.java correctly uses the new constructor with the appId parameter. This confirms that the integration of the new constructor is consistent with its intended usage.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all instances of `PureApolloConfig` instantiation include the new `appId` parameter.

# Test: Search for the constructor usage. Expect: Only occurrences with the new signature.
rg --type java -A 5 $'new PureApolloConfig'

Length of output: 473

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (5)

27-31: Addition of new imports for enhanced configuration management.

The addition of ConfigUtil and Table from Guava supports the new functionality for handling multiple app IDs. This aligns with the PR's objective to enhance configuration capabilities.

39-46: Initialization of new data structures for configuration management.

The use of Table for m_configs and m_configFiles is a significant change that allows storing configurations with a compound key of appId and namespace. This is a robust approach to handle configurations in a multi-application environment.

52-52: Initialization of ConfigUtil in the constructor.

This change is crucial as ConfigUtil is used to fetch the appId dynamically in the overridden methods. It ensures that the appId can be retrieved consistently across different parts of the application.

57-58: Delegation of getConfig to the new method with appId.

This change maintains backward compatibility by delegating to the new getConfig method that includes appId. It's a good practice to ensure that existing code relying on the old method signature continues to work without modification.

82-83: Delegation of getConfigFile to the new method with appId.

Similar to getConfig, this change ensures backward compatibility by delegating to the new getConfigFile method that includes appId. This is a good practice for maintaining existing functionality while extending new features.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3)

82-84: New method for fetching configuration by appId and namespace.

The implementation of getConfig(String appId, String namespace) correctly extends the functionality to handle multiple app IDs, aligning with the PR's objectives.

110-116: Validation of appId in configuration creation.

The addition of appId validation in create(String appId, String namespace) ensures that configurations are correctly associated with their respective applications. This is a critical enhancement for maintaining configuration integrity.

22-22: Import of StringUtils.

The addition of StringUtils is necessary for the appId comparison logic in the new methods. This is a justified and appropriate use of the library.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (4)

42-42: Approved: Introduction of m_appId and related changes.

The addition of m_appId and its integration into the constructors and methods aligns with the PR's objective to handle multiple app IDs effectively.

Also applies to: 67-71

57-58: Approved: Constructor delegation for backward compatibility.

The updated constructor that delegates to the new constructor with appId as null ensures backward compatibility while supporting the new functionality.

116-117: Approved: Overloading of onRepositoryChange to handle appId.

The method now correctly delegates handling to the version that accepts an appId, aligning with the new functionality requirements.

68-70: Approved: Dynamic fetching of appId using ConfigUtil.

The approach to dynamically fetch the appId if not provided ensures robustness in handling configurations. Ensure that ConfigUtil is always correctly initialized and available to avoid potential null pointer exceptions.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (8)

102-104: Approved: New method signature for Config create.

The addition of the appId parameter aligns with the PR's objectives to support multiple app IDs. The implementation is consistent with the interface's requirements.

112-114: Approved: New method signature for ConfigFile createConfigFile.

The addition of the appId parameter enhances the method's capability to handle configurations specific to an application ID, which is crucial for multi-application environments.

124-126: Approved: New method signature for void register.

The updated method signature allows for more granular control over configuration factories based on both application ID and namespace, supporting the PR's goal of enhanced configuration management.

137-142: Approved: New method signature for ConfigFactory getFactory.

This method now supports fetching factories based on both appId and namespace, enhancing the flexibility and specificity of configuration retrieval.

152-154: Approved: Consistent implementation of Config create across different factories.

The method's implementation is aligned with the interface's new requirements, supporting configurations specific to both an application ID and a namespace.

162-164: Approved: Consistent implementation of ConfigFile createConfigFile across different factories.

This method now allows for the creation of configuration files that are specific to both an application ID and a namespace, enhancing the system's configurability.

174-176: Approved: Uniform implementation of Config create across all factories.

The method's implementation is consistent with the new interface requirements, ensuring that configurations can be tailored to specific applications and namespaces.

184-186: Approved: Uniform implementation of ConfigFile createConfigFile across all factories.

This method enhances the configurability of the system by allowing for the creation of configuration files that are specific to both an application ID and a namespace.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (3)

45-45: Initialization of ConfigUtil.

The direct instantiation of ConfigUtil using ApolloInjector ensures that the configuration utility is properly integrated and managed within the Apollo infrastructure. This is a good use of dependency injection principles.

74-77: Dynamic addition of namespaces to PropertySourcesProcessor.

This loop effectively adds namespaces for each app ID, ensuring that configurations are dynamically loaded based on the app ID. The use of Lists.newArrayList is appropriate here for converting arrays to lists.

Line range hint 19-28: Review of new imports and dependencies.

The addition of ConfigUtil and other imports are necessary for the new functionalities introduced. Ensure that these dependencies are properly managed and do not introduce any version conflicts or additional overhead that could affect the application's performance.

Verification successful

No Dependency Conflicts with ConfigUtil Import
The import of ConfigUtil in DefaultApolloConfigRegistrarHelper.java is consistent with its usage as an internal utility class within the Apollo project. It is managed by the ApolloInjector and does not introduce any external dependency conflicts.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential dependency conflicts.

# Test: Search for dependency declarations in build files. Expect: No conflicts with existing dependencies.
fd 'pom.xml' --exec cat {} \; | grep 'ConfigUtil'

Length of output: 50

Script:

#!/bin/bash
# Search for the definition or declaration of ConfigUtil in the codebase
ast-grep --lang java --pattern 'class ConfigUtil { $$$ }'

# Check if ConfigUtil is part of a library that is already included as a dependency
rg 'ConfigUtil' -A 5

Length of output: 116958

apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (3)

116-117: Review the constructor and method changes in MockConfig.

The constructor of MockConfig has been correctly updated to include appId, aligning with the changes required for supporting multiple app IDs. The method getProperty now correctly formats the return value to include appId, which is crucial for ensuring that the configuration keys are correctly formed and tested.

Also applies to: 127-127

152-157: Review the constructor changes in MockConfigFile.

The updated constructor in MockConfigFile now accepts appId along with namespace and configFileFormat, which is essential for testing configurations that are specific to an application ID. This change is well-aligned with the PR's objectives and enhances the specificity of the configuration tests.

206-208: Review the method changes in MockConfigFactory.

The methods create and createConfigFile in MockConfigFactory have been updated to include an appId parameter. This modification is crucial for creating configurations that are specific to an application ID, thus supporting the new functionality introduced in the PR. The implementation appears correct and aligns with the changes described in the PR summary.

Also applies to: 216-218

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (5)

59-59: Refactor: Use of Multimap for Namespace Management

The change to use a Multimap for managing namespaces associated with multiple app IDs is a significant improvement. This structure allows for more flexible and scalable configuration management, especially in environments with multiple applications.

69-70: Refactor: Static Method Overload for Backward Compatibility

The addition of an overloaded addNamespaces method that defaults to using the current app ID is a good practice for maintaining backward compatibility. This allows existing code to function without modification while supporting new functionality.

72-75: Enhancement: Support for Multiple App IDs in Namespace Management

This method enhancement to handle multiple app IDs is aligned with the PR's objectives. It correctly creates a new multimap for each app ID and associates it with the given namespaces, which is crucial for the new functionality.

120-120: Cleanup Operation on APP_NAMESPACE_NAMES

Clearing APP_NAMESPACE_NAMES after initialization is a critical operation to ensure that the state does not persist beyond its intended scope. This is a good practice to prevent potential memory leaks or stale data issues.

172-172: Reset Method Enhancement

The update to the reset method to clear both APP_NAMESPACE_NAMES and AUTO_UPDATE_INITIALIZED_BEAN_FACTORIES is necessary to ensure that all stateful components are correctly reset during testing or reinitialization scenarios.

apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2)

226-226: Approved: Updated test method reflects changes correctly.

The test method testLocalCacheDirWithSystemProperty correctly verifies the behavior of getDefaultLocalCacheDir(someAppId) by ensuring the appId is appended to the cache directory path.

239-243: Approved: Test method accurately reflects OS-specific behavior with appId.

The test method testDefaultLocalCacheDir effectively verifies the behavior of getDefaultLocalCacheDir(someAppId) for both Windows and non-Windows systems, ensuring that the appId is correctly incorporated into the path.

apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java (1)

20-20: Approved: Import and system property setting.

The import of ApolloClientSystemConsts and the dynamic setting of the APP_ID system property are crucial for supporting multiple app IDs. This aligns with the PR's objectives to enhance configuration capabilities.

Ensure that the new system property APP_ID is utilized consistently across the test suite where applicable.

Also applies to: 121-121

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (7)

52-52: Initialization of m_appId

The addition of m_appId as a class member is consistent with the PR's objective to handle multiple app IDs. This change allows the class to manage configurations based on the application identifier effectively.

66-71: Constructor Overloading with appId

The constructors have been overloaded to include appId, which is essential for distinguishing configurations across different applications. This change aligns well with the PR's objectives and enhances the configurability of the system.

88-88: Dynamic Local Cache Directory Based on appId

The method findLocalCacheDir now dynamically determines the cache directory based on appId. This is a crucial enhancement for supporting environments with multiple applications, ensuring that each application's configuration is isolated and managed independently.

133-144: Handling Repository Changes with appId

The method onRepositoryChange has been updated to include appId. This ensures that changes are correctly associated with the specific application, which is vital for accurate configuration management in multi-application environments.

160-160: Loading Properties from Local Cache File

The method loadFromLocalCacheFile now includes appId in its parameters, which is used to construct the cache file name. This modification is necessary to ensure that the cache files are uniquely identified per application, preventing configuration conflicts.

201-201: Persisting Local Cache File with appId

The method persistLocalCacheFile has been updated to include appId, enhancing the specificity of cache file management. This change is crucial for maintaining the integrity and isolation of configuration data across multiple applications.

Also applies to: 239-239

297-300: Assembling Local Cache File Name with appId

The method assembleLocalCacheFile now constructs the file name using appId, which is a necessary change to support unique file naming conventions across different applications. This ensures that configurations are not only isolated by namespace but also by application identifier.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (5)

68-69: Refactor suggestion: Constructor delegation.

The constructor at lines 68-69 delegates to another constructor using null for appId. This is a good use of constructor chaining to maintain a clean and DRY codebase.

78-84: Review: New constructor with appId.

The new constructor introduced at lines 78-84 correctly handles the case where appId is null by fetching the default appId from ConfigUtil. This ensures backward compatibility and flexibility in configuration management.

240-241: Refactor suggestion: Method overloading for backward compatibility.

The method onRepositoryChange at lines 240-241 is overloaded to maintain backward compatibility while supporting the new appId parameter. This is a good practice as it allows existing code to function without modification while enabling new functionality.

Line range hint 243-261: Review: Handling of configuration changes with appId.

The method onRepositoryChange at lines 243-261 now includes handling for the appId. This change is crucial for supporting configurations specific to different applications, enhancing the flexibility of the configuration management system.

274-274: Review: Calculation of property changes.

The method updateAndCalcConfigChanges at line 274 now includes appId in the calculation of property changes. This is an important update as it ensures that changes are accurately tracked and managed per application, aligning with the PR's objectives to support multiple app IDs.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (2)

78-80: Refactor to use ConcurrentHashMap and Table for tracking and notifications.

The transition to using ConcurrentHashMap for m_longPollStarted and Table for m_notifications is a significant improvement. This change enhances the granularity of control and allows for app-specific tracking, which is crucial for the feature of handling multiple app IDs. The use of ConcurrentHashMap ensures thread safety and better performance under concurrent access scenarios.

299-300: Simplify namespace assembly for app-specific configurations.

The assembleNamespaces method has been updated to handle app-specific configurations. The method now correctly assembles namespaces based on the app ID. This change is a straightforward adaptation to support the new multi-app functionality and is implemented correctly.

apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (1)

524-526: Review: getAccessKeySecret(String appId) method implementation.

The method getAccessKeySecret(String appId) retrieves the access key secret for a specific appId using the Foundation class. This is a straightforward implementation that delegates the responsibility to the Foundation.app().getAccessKeySecret(appId) method.

Given the previous comments about integrating this logic into Foundation.app(), it appears this change aligns with those suggestions. Ensure that the Foundation class has been appropriately updated to handle this new method call.

Verification successful

Clarification on getAccessKeySecret Method Implementation

The getAccessKeySecret method is not directly implemented in the Foundation class. Instead, it is part of the ApplicationProvider interface and implemented by classes like DefaultApplicationProvider. Ensure that Foundation.app() correctly delegates to an appropriate provider that implements this method.

  • DefaultApplicationProvider implements getAccessKeySecret(String appId).
  • ApplicationProvider interface declares getAccessKeySecret.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the Foundation class has been updated to handle the new method call.

# Test: Search for the updated Foundation class implementation.
ast-grep --lang java --pattern $'class Foundation {
  $$$
  getAccessKeySecret($_) {
    $$$
  }
  $$$  
}'

Length of output: 108

Script:

#!/bin/bash
# Locate the Foundation class in the codebase
fd -e java -x grep -l 'class Foundation' {}

# Search for the getAccessKeySecret method in the codebase
rg 'getAccessKeySecret' -A 3 --glob '*.java'

Length of output: 8689

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Show resolved Hide resolved
.../src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java Show resolved Hide resolved
.../src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java Show resolved Hide resolved
.../src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java Show resolved Hide resolved
coderabbitai[bot]
coderabbitai bot reviewed Sep 5, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 18

Outside diff range, codebase verification and nitpick comments (6)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java (1)

32-38: Review of the new method addition in RepositoryChangeListener.

The addition of the new method onRepositoryChange(String appId, String namespace, Properties newProperties) is well-documented and aligns with the PR's objectives to enhance configuration management by supporting multiple app IDs. This method allows for more granular control and differentiation of repository changes per application, which is crucial in multi-application environments.

However, it's important to ensure that this change does not break existing implementations. Since this is an interface, adding a new method could break classes that implement this interface unless they are updated accordingly.

Consider providing a default implementation for the new method in the interface to maintain backward compatibility. This can be done using Java 8's default methods in interfaces. Here's a suggested implementation:

default void onRepositoryChange(String appId, String namespace, Properties newProperties) {
    // Default implementation to avoid breaking existing implementations
    onRepositoryChange(namespace, newProperties);
}

This default method simply redirects to the existing onRepositoryChange(String namespace, Properties newProperties) method, ensuring that existing implementations that do not yet handle appId can continue to function without modification.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1)

38-46: Approve the addition of the getAppId() method.

The addition of the getAppId() method as a default method in the ConfigFile interface is a good practice for interface evolution. It allows the interface to be extended without breaking existing implementations. The method is well-documented and includes a version annotation, which is helpful for maintainers.

However, it's important to ensure that implementations that require a specific appId should override this method to return the correct value instead of null.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (1)

74-77: Approved: Use of someAppId in method calls.

The changes to include someAppId in the ConfigChange constructor and config.fireConfigChange method call are well-implemented. This ensures consistent application ID usage across configuration changes.

Consider adding a comment explaining the purpose of someAppId for future maintainability.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (1)

Line range hint 243-261: Enhancement: Extended onRepositoryChange to support appId.

This method extension is crucial for handling configuration changes in a multi-app environment. The method correctly checks for changes before proceeding, which is efficient. However, consider adding more detailed logging to help trace the flow of changes, especially in complex environments.

+ logger.debug("Processing repository change for appId: {}, namespace: {}", appId, namespace);
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (1)

Line range hint 128-154: Review the startLongPolling method with app-specific logic.

The method has been updated to handle app-specific long polling initiation. The use of putIfAbsent to check and set the m_longPollStarted flag is efficient and prevents redundant polling initialization. However, the exception handling within the method could be improved by logging more specific details about the failure context, which would aid in debugging.

Consider enhancing the logging detail in the exception handling:

ApolloConfigException exception =
    new ApolloConfigException("Schedule long polling refresh failed for appId: " + sysAppId, ex);

This addition provides clearer context in the logs regarding which app ID encountered the scheduling issue.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (1)

106-108: Cleanup: Remove commented-out code.

The commented-out code related to PropertySourcesProcessor is unnecessary and clutters the codebase. Removing this code will improve readability and maintainability.

Consider removing the commented-out code unless there is a specific reason to keep it for future reference.

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 132e2b7 and 38469c4.

Files selected for processing (82)
  • CHANGES.md (1 hunks)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1 hunks)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfigFactory.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (7 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEvent.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/JsonConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (8 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepository.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/TxtConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/XmlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YmlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactory.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactoryManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigRegistry.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java (3 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/build/MockInjector.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/integration/ConfigIntegrationTest.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java (30 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepositoryTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepositoryTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java (9 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (15 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/SimpleConfigTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/YamlConfigFileTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (3 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (7 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistryTest.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (29 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderAutoUpdateTest.java (40 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderTest.java (20 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XMLConfigAnnotationTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderAutoUpdateTest.java (25 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderTest.java (5 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/StringUtils.java (1 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java (2 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/NullProvider.java (1 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java (1 hunks)
  • apollo-mockserver/src/main/java/com/ctrip/framework/apollo/mockserver/ApolloTestingServer.java (2 hunks)
  • apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiWhileCacheDirSpecifiedTest.java (1 hunks)
  • changes/changes-2.3.0.md (1 hunks)
  • pom.xml (1 hunks)
Files skipped from review due to trivial changes (4)
  • CHANGES.md
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/build/MockInjector.java
  • pom.xml
Files skipped from review as they are similar to previous changes (16)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java
Additional comments not posted (237)
changes/changes-2.3.0.md (2)

7-13: Review of Change Entries

The entries from line 7 to 13 are well-documented and each includes a direct link to the corresponding pull request, which enhances transparency and traceability. The descriptions are clear and concise, providing a quick overview of the changes made in version 2.3.0.

16-16: Review of Comprehensive Link

The link provided on line 16 to view all issues and pull requests associated with this release is correctly formatted and functional. This is a valuable resource for users looking for a comprehensive view of the development process for version 2.3.0.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/TxtConfigFile.java (2)

Line range hint 27-29: Method getConfigFileFormat remains unchanged.

The method getConfigFileFormat which returns ConfigFileFormat.TXT is unchanged and continues to function as expected. This method is not directly affected by the constructor change.

23-24: Constructor updated to include appId.

The constructor of TxtConfigFile now includes an additional parameter appId, which is passed to the superclass PlainTextConfigFile. This change aligns with the PR's objective to support multiple app IDs and enhances configuration management capabilities. However, it is crucial to ensure that all instantiations of TxtConfigFile across the codebase are updated to reflect this new parameter.

Verification successful

All instantiations of TxtConfigFile updated successfully.

The constructor change to include the appId parameter in TxtConfigFile has been successfully propagated across the codebase. Both the production and test code reflect the new constructor signature, ensuring consistency and alignment with the PR's objectives.

  • DefaultConfigFactory.java: Updated to use the new constructor signature.
  • TxtConfigFileTest.java: Updated to use the new constructor signature.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all instantiations of `TxtConfigFile` are updated to include the new `appId` parameter.

# Test: Search for instantiations of `TxtConfigFile`. Expect: Only occurrences with the new constructor signature.
rg --type java -A 5 $'new TxtConfigFile'

Length of output: 1503

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YmlConfigFile.java (2)

25-26: Constructor signature change is well-implemented.

The addition of the appId parameter to the constructor of YmlConfigFile is correctly implemented. The super call has been appropriately updated to pass this new parameter along with the existing ones. This change supports the PR's objective of enhancing configuration capabilities by allowing multiple app IDs.

25-26: Verify the impact on existing code.

Given the change in the constructor signature, it is crucial to ensure that all existing code that instantiates YmlConfigFile is updated to pass the new appId parameter. This might involve significant changes across the codebase.

Run the following script to verify the usage of YmlConfigFile constructor:

Verification successful

Verification Successful: All instantiations of YmlConfigFile use the new constructor signature.

The instantiation of YmlConfigFile in DefaultConfigFactory.java includes the appId parameter, and no other outdated usages were found in the codebase. The update appears to be correctly applied across the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all instantiations of `YmlConfigFile` to ensure they include the new `appId` parameter.

# Test: Search for the constructor usage. Expect: Only occurrences with the new signature.
rg --type java -A 5 $'new YmlConfigFile'

Length of output: 731

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/XmlConfigFile.java (3)

25-27: Constructor changes are correctly implemented.

The updated constructor now correctly passes the appId, namespace, and configRepository parameters to the superclass constructor. This change is essential for supporting multiple app IDs and aligns with the PR's objectives.

Line range hint 29-31: Config file format method remains correct.

The getConfigFileFormat method correctly returns ConfigFileFormat.XML, which is appropriate for the XmlConfigFile class. No changes were needed here, and the method continues to function as expected.

25-27: Verify the usage of the new constructor across the codebase.

The constructor of XmlConfigFile now includes an appId parameter. It is crucial to ensure that all instantiations of XmlConfigFile across the codebase are updated to pass this new parameter.

Run the following script to verify the constructor usage:

Verification successful

Constructor usage correctly updated across the codebase.

The XmlConfigFile constructor has been updated to include an appId parameter, and all instances of its usage in both test and main code have been correctly updated to reflect this change. No further action is required.

  • XmlConfigFileTest.java shows multiple instances of the updated constructor.
  • DefaultConfigFactory.java also uses the updated constructor.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all instantiations of `XmlConfigFile` include the new `appId` parameter.

# Test: Search for the constructor usage. Expect: Only occurrences with the new signature.
rg --type java -A 5 $'new XmlConfigFile'

Length of output: 6186

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/JsonConfigFile.java (2)

25-27: Constructor change aligns with PR objectives.

The modification to include an appId parameter in the constructor of JsonConfigFile aligns with the PR's objective to support multiple app IDs. This change enhances the configuration management capabilities by allowing configurations to be associated with specific applications.

25-27: Verify the impact of the constructor change on other parts of the system.

The addition of the appId parameter to the constructor is a significant change. It is crucial to ensure that all parts of the system that instantiate JsonConfigFile are updated to pass the new appId parameter. This change should be verified to ensure it does not break existing functionality.

Run the following script to verify the usage of JsonConfigFile constructor across the codebase:

Verification successful

Constructor change verification successful.

The addition of the appId parameter to the JsonConfigFile constructor has been successfully integrated across the codebase. All instances of the constructor usage have been updated to include the new parameter, and the changes are reflected in both test and production code. No issues were found.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all instantiations of `JsonConfigFile` include the new `appId` parameter.

# Test: Search for the constructor usage. Expect: Only occurrences with the new signature.
rg --type java -A 5 $'new JsonConfigFile'

Length of output: 4780

apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfigFactory.java (1)

30-31: Verify the usage of the new method signature across the codebase.

The method createRepositoryConfig now includes an additional parameter appId. It is crucial to ensure that all references to this method in the codebase have been updated to pass the new parameter. This change could potentially break existing functionality if not handled correctly.

Run the following script to verify the method usage:

Verification successful

Verification successful: Method signature update is correctly implemented.

The createRepositoryConfig method's signature change to include the appId parameter has been verified. The method is used consistently with the new signature in the codebase, particularly in the DefaultConfigFactory class. No instances of the old signature were found, indicating that the update has been correctly propagated.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `createRepositoryConfig` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'createRepositoryConfig'

Length of output: 2301

apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java (1)

55-57: Address potential NullPointerException by providing a safer return value.

The method getAccessKeySecret(String appId) currently returns null, which could lead to NullPointerException in the calling code. It's important to handle this case more robustly. Consider implementing one of the following solutions:

  1. Return an empty string if the access key is not available, which avoids NullPointerException and allows calling code to handle the absence of a key gracefully.
  2. Throw a specific exception if the access key cannot be retrieved, which makes the error handling explicit and informs the caller of the issue.

Here are the proposed changes:

default String getAccessKeySecret(String appId) {
-  return null;
+  return ""; // Option 1: Return an empty string
}

Or:

default String getAccessKeySecret(String appId) {
-  return null;
+  throw new UnsupportedOperationException("Access key secret not available"); // Option 2: Throw an exception
}

Likely invalid or redundant comment.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigRegistry.java (2)

33-40: Review of the new register method with appId.

The addition of the appId parameter to the register method is a significant enhancement that aligns with the PR's objectives to support multiple app IDs. This change allows for more granular control over configuration management, especially in environments with multiple applications.

  • Correctness: The method signature and JavaDoc comments are correctly defined.
  • Consistency: This method complements the existing register method by adding an appId parameter, which is consistent with the need for handling multiple applications.
  • Documentation: The JavaDoc is clear and provides adequate information about the parameters and their purpose.

Overall, this is a well-implemented change that enhances the interface's functionality.

50-57: Review of the new getFactory method with appId.

Similar to the register method, the addition of the appId parameter to the getFactory method enhances the interface's capability to handle configurations for multiple applications. This method allows retrieving the configuration factory based on both appId and namespace, which is crucial for environments where configurations are specific to each application.

  • Correctness: The method signature and JavaDoc comments are correctly defined.
  • Consistency: This method complements the existing getFactory method by adding an appId parameter, maintaining consistency in the interface's design.
  • Documentation: The JavaDoc clearly explains the purpose of the parameters and the method's functionality.

This change is well-aligned with the PR's objectives and is implemented correctly.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactory.java (2)

35-42: Approved: New method for app-specific configuration.

The addition of Config create(String appId, String namespace) method is well-implemented and documented. It enhances the flexibility of the configuration system by allowing configurations to be specific to an application ID and namespace.

Ensure that existing implementations that use the old create(String namespace) method are not adversely affected by this change.

51-57: Approved: Enhanced method for creating config files with app context.

The addition of ConfigFile createConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) method is well-implemented and documented. It allows for the creation of configuration files that are specific to an application ID, namespace, and configuration file format, enhancing the system's usability and flexibility.

Ensure that existing implementations that use the old createConfigFile(String namespace, ConfigFileFormat configFileFormat) method are not adversely affected by this change.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEvent.java (2)

44-46: Review of Constructor Changes

The constructor of InterestedConfigChangeEvent has been modified to include an additional parameter appId. This change is consistent with the PR's objective to support multiple app IDs. The updated constructor correctly initializes the superclass with this new parameter, ensuring that the appId is now part of the event context.

This modification enhances the flexibility of the configuration change event handling by allowing events to be associated with specific applications. It is crucial to ensure that all parts of the system that instantiate this class are updated to pass the new appId parameter to avoid runtime errors.

Line range hint 54-56: Review of Method interestedChangedKeys

The method interestedChangedKeys remains unchanged and continues to function as expected. It correctly returns an unmodifiable set of the keys that triggered the change event, which is a good practice to ensure data integrity and prevent unintended modifications.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java (2)

34-34: Approved: Addition of someAppId variable.

The introduction of the someAppId variable is well-aligned with the PR's objectives to support multiple app IDs. It is correctly declared and initialized in the setUp method.

41-41: Approved: Initialization in setUp method.

The initialization of someAppId and someNamespace in the setUp method ensures that each test case starts with a consistent and isolated environment, which is a best practice in unit testing.

apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/NullProvider.java (1)

87-90: Approved: New method getAccessKeySecret(String appId)

The addition of the method getAccessKeySecret(String appId) is consistent with the class's design of returning default values. The implementation correctly adheres to the expected behavior of the interface, enhancing the class's compliance without altering its existing functionality.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepository.java (1)

46-46: Verify integration and impact of the new appId parameter in fireRepositoryChange.

The addition of configFile.getAppId() as a parameter to fireRepositoryChange enhances the granularity of configuration change tracking. However, it is crucial to verify that this change integrates seamlessly with the existing system and does not introduce any unintended side effects.

Run the following script to verify the usage of the new method signature across the codebase:

Verification successful

Integration of appId parameter in fireRepositoryChange is consistent and complete.

The addition of configFile.getAppId() to the fireRepositoryChange method is consistently applied across the codebase, ensuring seamless integration without any unintended side effects.

  • The method is used with the new signature in RemoteConfigRepository, PropertiesCompatibleFileConfigRepository, and LocalFileConfigRepository.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the new `fireRepositoryChange` method signature across the codebase.

# Test: Search for the method usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'fireRepositoryChange'

Length of output: 3269

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (4)

26-26: Clarification needed for the addition of appId.

Based on the previous comment by nobodyiam questioning the absence of a getAppId method, it appears that the addition of the appId field and its corresponding getter method in this PR addresses that concern. However, it would be beneficial to confirm that this addition aligns with the intended design and usage within the broader application context.

50-52: Approval of the new getAppId method.

The addition of the getAppId method is a straightforward implementation that provides access to the appId field. This method enhances the class's interface by allowing external access to the appId, which is crucial for handling configurations specific to different applications.

73-74: Review of toString method updates.

The toString method is updated to include the appId in its output. This change ensures that the string representation of the class instances now accurately reflects the new state of the object, including the appId. This is particularly useful for logging and debugging purposes, where a complete description of the event is necessary.

35-43: Review of constructor changes.

The constructor now includes appId as the first parameter, which is a significant change as it affects how instances of ConfigFileChangeEvent are created throughout the application. This change is aligned with the PR's objective to support multiple app IDs. Ensure that all instantiations of this class in the codebase are updated to reflect this new parameter order.

Verification successful

Constructor changes verified successfully.

The instantiation of ConfigFileChangeEvent in the codebase has been updated to include appId as the first parameter, aligning with the new constructor signature. No other instances were found that require modification.

  • AbstractConfigFile.java: Correct usage of the new constructor signature.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all instantiations of `ConfigFileChangeEvent` are updated to include `appId`.

# Test: Search for the constructor usage. Expect: Only occurrences with the new signature.
rg --type java -A 5 $'new ConfigFileChangeEvent'

Length of output: 774

Script:

#!/bin/bash
# Description: Search for all instantiations of `ConfigFileChangeEvent` to ensure they use the new constructor signature.

# Test: Search for all occurrences of `ConfigFileChangeEvent` instantiation.
rg --type java 'new ConfigFileChangeEvent'

Length of output: 241

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (3)

28-28: Field addition approved.

The addition of the private final String m_appId; field is appropriate for maintaining immutability and encapsulation in the class.

78-84: Method addition approved.

The addition of the getAppId() method is a standard practice for providing external access to private fields in Java. This method correctly returns the m_appId field.

36-38: Verify the impact of constructor parameter order change.

The constructor now includes an additional parameter appId, which is correctly initialized. However, this change in parameter order could impact existing code where this constructor is used.

Run the following script to verify the constructor usage:

Verification successful

Constructor parameter order change verified successfully.

The constructor ConfigChangeEvent is only used in test files, and all instances match the new signature with three parameters. There is no impact on production code.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `ConfigChangeEvent` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'new ConfigChangeEvent'

Length of output: 3495

Script:

#!/bin/bash
# Description: Verify all constructor calls to `ConfigChangeEvent` across the entire codebase to ensure they match the new signature.

# Test: Search for the constructor usage across all Java files. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'new ConfigChangeEvent'

Length of output: 3495

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistryTest.java (2)

66-69: Approved: New create method overload with appId.

The addition of the appId parameter in the create method is correctly implemented and aligns with the PR objectives to enhance configuration capabilities.

76-79: Approved: New createConfigFile method overload with appId.

The addition of the appId parameter in the createConfigFile method is correctly implemented and aligns with the PR objectives to enhance configuration capabilities.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1)

66-69: Review of the Modified fireRepositoryChange Method

The addition of the appId parameter to the fireRepositoryChange method is a significant enhancement that aligns with the PR's objectives to support multiple app IDs. This change allows the method to provide more contextual information about the application associated with the configuration change, which is crucial for systems managing configurations across multiple applications.

Key Observations:

  • The method now iterates over m_listeners and invokes onRepositoryChange on each listener with the new appId parameter.
  • Exception handling within the loop is robust, logging the error and continuing with the next listener, which ensures that a failure in one listener does not halt the notification process for others.

Suggestions:

  • **** Ensure that all implementations of RepositoryChangeListener have been updated to handle the new method signature. This is crucial to prevent runtime method signature mismatches.
  • **** Consider adding more detailed logging at the debug level to trace the values of appId, namespace, and newProperties being passed to each listener. This could be valuable for troubleshooting and verifying that the correct data is being used.
  • **** If there are any concerns about how to update the listeners or if additional testing is required, I can assist with these updates or provide guidance on setting up appropriate tests.
Verification successful

Verification of onRepositoryChange Method Signature Update

The implementations of RepositoryChangeListener have been updated to handle the new onRepositoryChange method signature with the appId parameter. The presence of both method signatures in the RepositoryChangeListener interface ensures backward compatibility. Test files have been updated to verify the new functionality.

  • Implementations Updated: LocalFileConfigRepository, AbstractConfigFile, SimpleConfig, DefaultConfig.
  • Tests Updated: JsonConfigFileTest, XmlConfigFileTest, DefaultConfigTest, SimpleConfigTest, RemoteConfigRepositoryTest, and others.

The changes align with the PR's objectives to support multiple app IDs, and the backward compatibility is maintained. No further action is required.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all implementations of RepositoryChangeListener handle the new method signature.

# Test: Search for implementations of RepositoryChangeListener. Expect: Updated method signatures.
rg --type java -A 5 $'onRepositoryChange'

Length of output: 63127

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1)

73-78: Well-documented addition of multipleConfigs() method.

The addition of the multipleConfigs() method is well-documented and clearly explains its purpose and non-participation in the bootstrap process. The use of the @since tag is a good practice, helping track the introduction of new features. The default value being an empty array ensures backward compatibility.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesConfigFile.java (1)

39-41: Review the modified constructor with the new appId parameter.

The addition of the appId parameter to the constructor is a significant change that aligns with the PR's objectives to support multiple app IDs. This change allows for more granular control over configurations per application. Ensure that:

  • The superclass AbstractConfigFile has been modified to accept this new parameter.
  • All instantiations of PropertiesConfigFile throughout the codebase are updated to include the appId parameter.

Run the following script to verify the superclass modification and usage of the new constructor:

Verification successful

Superclass AbstractConfigFile supports the new appId parameter.

The AbstractConfigFile constructor has been updated to accept the appId parameter, ensuring compatibility with the changes made to the PropertiesConfigFile constructor. The codebase has been updated to use the new constructor signature where necessary.

  • The AbstractConfigFile constructor now includes appId, namespace, and configRepository parameters.
  • Instantiations of PropertiesConfigFile have been updated to pass the appId parameter.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the superclass and usage of the new constructor.

# Test: Search for the superclass constructor modification.
ast-grep --lang java --pattern $'class AbstractConfigFile {
  $$$
  AbstractConfigFile($_, $_, $_) {
    $$$
  }
  $$$  
}'

# Test: Search for the usage of the new constructor.
rg --type java -A 5 $'new PropertiesConfigFile'

Length of output: 7018

Script:

#!/bin/bash
# Description: Verify the implementation of AbstractConfigFile to check for appId support.

# Search for the AbstractConfigFile class definition and its constructor.
ast-grep --lang java --pattern $'class AbstractConfigFile {
  $$$
  AbstractConfigFile($$$) {
    $$$
  }
  $$$  
}'

Length of output: 117

Script:

#!/bin/bash
# Description: Locate the AbstractConfigFile.java file and inspect its constructor.

# Find the AbstractConfigFile.java file and display its contents.
fd -e java -x bash -c 'echo "File: {}"; cat {}' | grep -A 10 'class AbstractConfigFile'

Length of output: 747

Script:

#!/bin/bash
# Description: Search for the constructor of AbstractConfigFile to verify its parameters.

# Find the AbstractConfigFile.java file and search for its constructor.
fd -e java -x bash -c 'echo "File: {}"; cat {}' | grep -A 10 'AbstractConfigFile('

Length of output: 767

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (2)

39-40: Proper Error Handling in tryTransformToProperties

The method tryTransformToProperties demonstrates good error handling practices by catching exceptions, logging them appropriately, and returning a boolean status. This ensures that the application can gracefully handle errors during the properties transformation process.

39-40: Constructor Signature Change: Ensure Compatibility

The constructor of YamlConfigFile now includes an appId parameter. This is a significant change that enhances the class's functionality by allowing it to handle configurations specific to an application ID. Ensure that all instantiations of YamlConfigFile across the codebase are updated to pass this new parameter.

Run the following script to verify the constructor usage:

Verification successful

Constructor Signature Change Verified

The constructor of YamlConfigFile has been successfully updated to include the appId parameter across the codebase. All instances of YamlConfigFile creation, including those in test files and the main source file DefaultConfigFactory.java, have been correctly modified to use the new constructor signature. No further action is required.

  • Instances in AbstractSpringIntegrationTest.java and YamlConfigFileTest.java confirm the update in test scenarios.
  • The update in DefaultConfigFactory.java confirms the change in production code.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `YamlConfigFile` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'new YamlConfigFile'

Length of output: 7131

apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiWhileCacheDirSpecifiedTest.java (1)

60-60: Review: Updated constructor call for LocalFileConfigRepository.

The change to the constructor of LocalFileConfigRepository from a single argument to two arguments (someAppId, someNamespace) is consistent with the PR's objective to support multiple app IDs. This update is crucial for ensuring that the configuration repository can handle configurations specific to an application ID alongside the namespace.

However, it's essential to verify that this change integrates well with the rest of the system, especially since it affects how configurations are loaded and managed. The test should ensure that the new functionality does not disrupt existing functionalities and that it aligns with the overall system architecture.

Verification successful

Verified: Consistent use of the new constructor for LocalFileConfigRepository.

The constructor change to LocalFileConfigRepository(someAppId, someNamespace) is consistently applied across the codebase, including both main and test files. This indicates that the new functionality is well-integrated and adequately tested, aligning with the PR's objective to support multiple app IDs.

  • Files with updated constructor usage:
    • ApolloTestingServer.java
    • ApolloMockServerApiWhileCacheDirSpecifiedTest.java
    • LocalFileConfigRepositoryTest.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the new constructor is used consistently across the project.

# Test: Search for the constructor usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'new LocalFileConfigRepository'

Length of output: 8309

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java (3)

41-41: Approved: Introduction of someAppId.

The addition of someAppId enhances the flexibility of the test setup by allowing dynamic configuration of the app ID, aligning with the PR's objectives.

Also applies to: 46-46

58-58: Approved: Correct usage of someAppId in enabled file caching scenario.

The dynamic passing of someAppId to createLocalConfigRepository is correctly implemented and verified. Consider verifying the integration of this change with other parts of the system to ensure overall compatibility.

Also applies to: 61-62

70-70: Approved: Correct usage of someAppId in disabled file caching scenario.

The dynamic passing of someAppId to createRemoteConfigRepository is correctly implemented and verified. Consider verifying the integration of this change with other parts of the system to ensure overall compatibility.

Also applies to: 74-74

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (2)

45-45: Approved: Addition of someAppId variable.

The addition of the someAppId variable aligns with the PR's objective to support multiple app IDs and enhances maintainability by centralizing the app ID value.

Line range hint 45-77: Summary: Well-integrated changes.

The changes made in the InterestedConfigChangeEventTest class are well-integrated and align with the PR's objectives to support multiple app IDs. The use of someAppId enhances the flexibility and maintainability of the test configurations.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepositoryTest.java (3)

43-43: Approved: Addition of someAppId variable.

The addition of the someAppId variable is consistent with the PR's objective to enhance configuration capabilities by supporting multiple app IDs.

51-53: Approved: Changes in the setUp method.

The initialization of someAppId and the update to the when clause for configFile.getAppId() are well-implemented to support the new functionality of handling multiple app IDs in the configuration.

135-135: Approved: Changes in the testOnChange method.

The modification to include someAppId in the onRepositoryChange method call is correctly implemented to test the new behavior of handling multiple app IDs.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java (4)

Line range hint 29-48: Setup method is correctly implemented.

The setUp method properly initializes the test environment with necessary mocks and listener setups.

Line range hint 95-99: Property source addition and listener registration are correctly tested.

The testAddPropertySource method correctly verifies the addition of property sources and the registration of listeners.

Line range hint 101-120: First property source addition and listener registration are correctly tested.

The testAddFirstPropertySource method correctly tests the addition of a property source at the beginning and ensures that listeners are correctly added.

85-85: Verify the updated onChange method invocation.

The change to pass three null parameters in the onChange method needs verification to ensure it aligns with the intended functionality and does not alter the expected behavior of the test.

Run the following script to verify the method signature and its usage:

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java (6)

Line range hint 42-51: Setup method correctly initializes someAppId.

The introduction of someAppId in the setUp method is correctly implemented and crucial for testing the new functionality.

67-67: Correct usage of updated constructor in testWhenHasContent.

The test method testWhenHasContent correctly uses the updated JsonConfigFile constructor with the new someAppId parameter.

80-80: Correct usage of updated constructor in testWhenHasNoContent.

The test method testWhenHasNoContent correctly uses the updated JsonConfigFile constructor with the new someAppId parameter.

90-90: Correct usage of updated constructor in testWhenConfigRepositoryHasError.

The test method testWhenConfigRepositoryHasError correctly uses the updated JsonConfigFile constructor with the new someAppId parameter.

Line range hint 110-121: Correct usage of updated method signature in testOnRepositoryChange.

The test method testOnRepositoryChange correctly uses the updated onRepositoryChange method with the new someAppId parameter.

139-145: Correct usage of updated constructor and method in testWhenConfigRepositoryHasErrorAndThenRecovered.

The test method testWhenConfigRepositoryHasErrorAndThenRecovered correctly uses the updated JsonConfigFile constructor and onRepositoryChange method with the new someAppId parameter.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (5)

48-48: Constructor and Field Initialization Approved

The addition of the m_appId field and its initialization in the constructor are correctly implemented to support multiple app IDs as per the PR's objectives.

Also applies to: 61-63

85-88: New Method getAppId() Approved

The implementation of the getAppId() method is correct and provides a necessary accessor for the m_appId field.

99-100: Incorporation of Suggested Change

The change suggested by nobodyiam has been successfully incorporated into the new onRepositoryChange method.

99-100: Modified Method onRepositoryChange Approved

The changes to the onRepositoryChange method correctly incorporate the application ID into configuration change events. It is recommended to verify the integration of this method with other components that handle configuration changes.

Also applies to: 102-125

Verification successful

Integration of onRepositoryChange Method Verified

The onRepositoryChange method, with the new appId parameter, is well-integrated and tested across various components in the codebase. The test cases confirm its correct functionality in different scenarios. No further action is required.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify integration of the new `onRepositoryChange` method with other components.

# Test: Search for method usage in other components. Expect: Proper handling of the new method signature.
rg --type java -A 5 $'onRepositoryChange'

Length of output: 63127

Line range hint 48-125: Overall Changes Approved

The modifications in the AbstractConfigFile class are well-integrated and consistent with the PR's objectives to handle multiple app IDs. It is recommended to conduct further testing to ensure robustness and compatibility.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java (1)

46-46: Addition of someAppId variable.

The introduction of the someAppId variable aligns with the PR's objective to handle multiple app IDs. This variable is used effectively across the test configurations and method signatures to simulate a multi-app environment.

Also applies to: 54-54

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/SimpleConfigTest.java (5)

52-52: Addition of someAppId instance variable.

The addition of the someAppId variable is consistent with the PR's objective to support multiple app IDs. This change is crucial for the new functionality and is well-integrated into the existing test setup.

62-62: Initialization of someAppId in the setUp method.

The initialization of someAppId in the setUp method ensures that it is available for all tests, supporting the new constructor signature of SimpleConfig. This is a necessary change to accommodate the new functionality.

91-91: Updated constructor calls to include someAppId.

The constructor of SimpleConfig has been updated across multiple test methods (testGetProperty, testLoadConfigFromConfigRepositoryError, testOnRepositoryChange) to include the new someAppId parameter. This change is necessary to test the new functionality introduced in the PR and ensures that the SimpleConfig class can handle configurations for specific applications.

Also applies to: 104-104, 138-138

147-147: Updated onRepositoryChange method to pass someAppId.

The onRepositoryChange method now correctly passes someAppId as an argument, reflecting the updated constructor requirements. This change is crucial for ensuring that the configuration changes are correctly propagated and handled within the application context.

151-151: Updated assertions to verify someAppId.

The assertions in the testOnRepositoryChange method have been updated to verify that the changeEvent correctly reflects the new someAppId value. This is an important update to ensure that the tests accurately check the functionality related to handling multiple app IDs.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java (4)

47-47: Approved: Introduction of someAppId variable.

The introduction of the someAppId variable centralizes the application ID, enhancing maintainability and reducing the risk of hardcoded strings. This change aligns well with the PR's objectives.

111-112: Approved: Consistent use of someAppId.

The consistent use of someAppId in the ConfigChange and ConfigChangeEvent objects across different test methods supports the PR's objective and enhances configuration flexibility.

156-158: Approved: Consistent use of someAppId.

The consistent use of someAppId in the ConfigChange and ConfigChangeEvent objects across different test methods supports the PR's objective and enhances configuration flexibility.

68-72: Approved: Use of someAppId in test method.

The use of someAppId in creating ConfigChange and ConfigChangeEvent objects, and the new call to fireConfigChange enhance flexibility and maintain consistency. Ensure that the new method signature for fireConfigChange is correctly implemented across the codebase.

Verification successful

Verified: Consistent usage of fireConfigChange method signature.

The fireConfigChange method with the new signature is used consistently across the codebase, and the use of someAppId in the test method aligns with the defined method signature. No issues were found.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the new method signature for `fireConfigChange` is used consistently.

# Test: Search for the method usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'fireConfigChange'

Length of output: 11103

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (5)

53-54: Addition of someAppId constant.

The introduction of a constant for someAppId is a good practice as it avoids hardcoding the same string multiple times across the test methods. This change enhances maintainability and readability.

58-59: Setting someAppId as a system property in setUp.

Setting the appId as a system property is crucial for the tests that depend on this configuration. This setup ensures that the environment is correctly prepared for the tests to run under the conditions that mimic the actual usage of the application with the specified appId.

Line range hint 81-107: Enhanced test cases with someAppId.

The modifications in the testInitializePropertySources method to include someAppId in the configuration and assertions are aligned with the new functionality of handling multiple app IDs. These changes ensure that the tests are robust and accurately reflect the expected behavior when different app IDs are used.

  • The use of someAppId in mockConfig calls ensures that the configuration is correctly mocked with respect to the application ID.
  • The assertions have been updated to check for the correct formation of property source names, which now incorporate the application ID.

This thorough testing approach helps in validating the functionality introduced in the PR.

113-116: Testing application event handling with someAppId.

The changes in the testApplicationEvent method to include someAppId in the configuration and event handling tests are appropriate. This ensures that the application events are correctly processed when different app IDs are used, which is crucial for the new feature's functionality.

  • The mockConfig call with someAppId ensures that the configuration is correctly set up for the test.
  • The handling of the ConfigChangeEvent and the publishing of the ApolloConfigChangeEvent are critical to ensure that the system reacts appropriately to configuration changes.

These tests are essential for verifying that the application's event system works correctly with multiple app IDs.

161-161: Assertion on system properties override.

The assertion in the testOverrideSystemProperties method that checks the name of the first property source ensures that the system properties are correctly overridden as specified by the configuration. This is an important aspect of the configuration system that needs to be tested to ensure that the application behaves as expected under different configuration settings.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (9)

67-68: Refactor: Simplify method delegation.

The method create(String namespace) now delegates to create(String appId, String namespace) using the appId fetched from ConfigUtil. This is a clean implementation that maintains backward compatibility by using the default appId.

Line range hint 70-91: Review: Core configuration creation logic with appId.

The method create(String appId, String namespace) has been refactored to include the appId parameter. This change allows for more granular control over configurations per application. The logic inside the method correctly handles different ConfigFileFormat types and delegates to the appropriate repository creation methods based on the format compatibility.

93-95: Refactor: Simplify method delegation for ConfigFile creation.

The method createConfigFile(String namespace, ConfigFileFormat configFileFormat) now delegates to createConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) using the appId fetched from ConfigUtil. This maintains backward compatibility and simplifies the API for clients that do not need to specify an appId.

98-117: Review: Enhanced ConfigFile creation with appId.

The method createConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) has been updated to handle different file formats and create the appropriate ConfigFile instances using the appId. This change ensures that configuration files are correctly associated with their respective applications, enhancing the system's ability to manage configurations in a multi-application environment.

123-127: Review: ConfigRepository creation logic with appId.

The method createConfigRepository(String appId, String namespace) has been updated to decide between local and remote repositories based on the property file cache setting. This method now correctly uses the appId to create the appropriate repository, ensuring that configurations are managed per application.

133-144: Review: LocalFileConfigRepository creation with appId.

The method createLocalConfigRepository(String appId, String namespace) has been updated to include the appId in its signature and logic. This change is crucial for ensuring that local configurations are correctly associated with the specified application, especially in environments where Apollo is running in local mode.

147-148: Review: RemoteConfigRepository creation with appId.

The method createRemoteConfigRepository(String appId, String namespace) now correctly uses the appId to create a remote configuration repository. This change is essential for ensuring that remote configurations are managed per application, aligning with the overall goal of enhancing configuration management in multi-application environments.

152-153: Review: PropertiesCompatibleFileConfigRepository creation with appId.

The method createPropertiesCompatibleFileConfigRepository(String appId, String namespace, ConfigFileFormat format) now includes the appId in its logic, ensuring that the properties-compatible configuration files are correctly associated with the specified application. This method correctly handles the namespace formatting based on the file format and application ID, enhancing the flexibility and accuracy of configuration management.

172-172: Review: Namespace trimming with appId.

The method trimNamespaceFormat(String appId, String namespaceName, ConfigFileFormat format) has been updated to include the appId in its logic. This change ensures that the namespace is correctly formatted per application, which is crucial for maintaining consistency and accuracy in configuration file naming and management.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java (7)

Line range hint 51-60: Initialization of someAppId is correct.

The setup method correctly initializes someAppId, which is essential for the tests to accurately reflect the new constructor parameter.

85-85: Test method update is correct.

The update to include someAppId in the PropertiesConfigFile constructor call is correctly implemented in the testWhenHasContent method.

97-97: Test method update is correct.

The update to include someAppId in the PropertiesConfigFile constructor call is correctly implemented in the testWhenHasNoContent method.

107-107: Test method update is correct.

The update to include someAppId in the PropertiesConfigFile constructor call is correctly implemented in the testWhenConfigRepositoryHasError method.

123-123: Test method update is correct.

The update to include someAppId in the PropertiesConfigFile constructor call is correctly implemented in the testOnRepositoryChange method.

162-162: Test method update is correct.

The update to include someAppId in the PropertiesConfigFile constructor call is correctly implemented in the testWhenConfigRepositoryHasErrorAndThenRecovered method.

182-182: Test method updates are correct.

The updates to include someAppId in the PropertiesConfigFile constructor calls are correctly implemented in the testIfCompatibleWithProperties and testIfCompatibleWithEmptyProperties methods.

Also applies to: 197-197

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (2)

59-59: Refactor: Use of Multimap for Namespace Management

The introduction of APP_NAMESPACE_NAMES as a Multimap to manage namespaces associated with multiple app IDs is a significant improvement. This change aligns with the PR's objective to support multiple app IDs and enhances the flexibility of namespace management.

172-172: Consistency Maintained in Reset Method

The update to the reset method to clear APP_NAMESPACE_NAMES ensures that the new data structure is properly reset, maintaining consistency across the class.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderTest.java (6)

39-39: Introduction of someAppId variable.

The introduction of the someAppId variable is a positive change as it centralizes the application ID, making the tests more maintainable and adaptable to changes in configuration. This aligns with the PR's objective to handle multiple app IDs.

66-66: Proper use of someAppId in mockConfig.

The replacement of the hardcoded namespace with someAppId in the mockConfig call is correctly implemented and enhances the flexibility of the configuration.

74-74: Consistent use of someAppId in mockConfig.

Using someAppId in the mockConfig method call maintains consistency and supports the PR's goal of flexible configuration management.

88-88: Correct implementation of someAppId in mockConfig.

The use of someAppId in the mockConfig call is correctly implemented, enhancing the test's adaptability to configuration changes.

101-106: Flexible use of someAppId across different namespaces.

The use of someAppId for different namespaces within the same test method effectively demonstrates the enhanced flexibility and adaptability of the configuration system.

117-122: Consistent and flexible use of someAppId in preparation method.

The use of someAppId in the prepare method for different namespaces is consistent with its usage in other test methods, supporting the PR's objectives of enhanced configuration flexibility.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepositoryTest.java (5)

122-122: Approved: Constructor updated to include someAppId.

The update to include someAppId in the constructor call aligns with the PR objectives. Consider adding specific tests to verify the behavior when someAppId is different or not set.

138-138: Approved: Constructor updated to include someAppId with fallback repository.

The update to include someAppId in the constructor call aligns with the PR objectives. Consider adding specific tests to verify the behavior when someAppId is different or not set, especially in the presence of a fallback repository.

150-150: Approved: Constructor updated to include someAppId for scenarios without a local file.

The update to include someAppId in the constructor call aligns with the PR objectives. Consider adding specific tests to verify the behavior when someAppId is different or not set, particularly when there is no local file.

164-164: Approved: Constructor updated to include someAppId for multiple access scenarios.

The updates to include someAppId in the constructor calls align with the PR objectives. Consider adding specific tests to verify the behavior when someAppId is different or not set, especially when accessing the local file multiple times.

Also applies to: 171-171

187-187: Approved: Constructor and method updated to include someAppId for repository change scenarios.

The updates to include someAppId in the constructor call and onRepositoryChange method align with the PR objectives. Consider adding specific tests to verify the behavior when someAppId is different or not set, particularly when the repository changes.

Also applies to: 204-204

apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (1)

226-226: Ensure consistency in cache directory path construction.

The test testLocalCacheDirWithSystemProperty correctly checks if the local cache directory path includes the appId. However, it's important to ensure that the path construction is consistent across different environments and does not lead to issues with path delimiters on different operating systems.

Consider adding a utility method to handle path constructions or ensure that File.separator is consistently used across the application to avoid hardcoding path delimiters.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java (4)

Line range hint 52-61: Initialization of test variables is well-implemented.

The setup method correctly initializes someAppId and someNamespace, which are crucial for the tests that follow. This ensures that each test can operate with its own set of parameters, enhancing test reliability and isolation.

88-88: Consistent use of the new constructor across test methods.

All instances of XmlConfigFile instantiation in the test methods have been updated to include the new appId parameter. This change is consistent with the modifications described in the PR summary and ensures that the new functionality is being tested correctly.

Also applies to: 100-100, 110-110, 126-126, 162-162, 199-199, 235-235

143-143: Correct adaptation of the onRepositoryChange method to include appId.

The onRepositoryChange method calls have been correctly updated to include the appId parameter. This adaptation is crucial for ensuring that the method aligns with the changes made to the XmlConfigFile class, reflecting the new requirement to handle configurations based on the application ID.

Also applies to: 240-240

162-162: Potential issue with method call in testOnRepositoryChangeWithContentAdded.

The call to onRepositoryChange in the testOnRepositoryChangeWithContentAdded method does not include the appId parameter. This seems to be an oversight and could lead to test failures or incorrect behavior since the method signature expects the appId as the first parameter.

Consider updating the method call to include appId:

- configFile.onRepositoryChange(someNamespace, anotherProperties);
+ configFile.onRepositoryChange(someAppId, someNamespace, anotherProperties);

Likely invalid or redundant comment.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/YamlConfigFileTest.java (7)

42-42: Setup of someAppId and someNamespace is correct.

The initialization of someAppId and someNamespace in the setUp method is correctly done. This setup is crucial for the tests that follow, ensuring that the YamlConfigFile instances are correctly instantiated with these parameters.

Also applies to: 55-55

89-89: Correct instantiation of YamlConfigFile.

The YamlConfigFile is correctly instantiated with the new someAppId parameter along with someNamespace and configRepository. This change aligns with the PR objectives to handle configurations based on application context.

115-115: Correct instantiation of YamlConfigFile with ordered properties.

The instantiation of YamlConfigFile in the testWhenHasContentWithOrder method correctly includes the someAppId parameter. This ensures that the test reflects the new functionality introduced in the PR.

129-129: Correct instantiation of YamlConfigFile in no-content scenario.

The instantiation of YamlConfigFile in the testWhenHasNoContent method correctly includes the someAppId parameter, ensuring that the test accurately tests scenarios where no content is available.

152-152: Correct instantiation of YamlConfigFile in invalid YAML content scenario.

The instantiation of YamlConfigFile in the testWhenInvalidYamlContent method correctly includes the someAppId parameter. This ensures that the test accurately tests scenarios with invalid YAML content.

171-171: Correct instantiation of YamlConfigFile in error scenario.

The instantiation of YamlConfigFile in the testWhenConfigRepositoryHasError method correctly includes the someAppId parameter. This ensures that the test accurately tests scenarios where the config repository encounters an error.

203-203: Correct handling of YamlConfigFile in repository change scenarios.

The instantiation and method calls in the testOnRepositoryChange and testWhenConfigRepositoryHasErrorAndThenRecovered methods correctly include the someAppId parameter. This ensures that the tests accurately reflect the new functionality for handling repository changes based on the application ID.

Also applies to: 215-215, 238-238, 245-245

apollo-mockserver/src/main/java/com/ctrip/framework/apollo/mockserver/ApolloTestingServer.java (1)

179-179: Verify the impact of using someAppId on configuration loading.

The introduction of someAppId as an argument in LocalFileConfigRepository is a significant change. It's crucial to verify that this modification does not affect the existing functionality of configuration loading and that it correctly supports the new feature of handling multiple app IDs.

Run the following script to verify the impact on configuration loading:

Verification successful

Verified: Usage of someAppId in ApolloTestingServer.java

The usage of someAppId as an argument in LocalFileConfigRepository is consistent with its role as a placeholder for testing purposes. This change does not impact the configuration loading process in a production environment. The static declaration of someAppId ensures that it remains a fixed value, aligning with the testing objectives.

  • ApolloTestingServer.java: someAppId is declared and used as a static string.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the impact of using `someAppId` on configuration loading.

# Test: Search for the usage of `LocalFileConfigRepository` with `someAppId`. Expect: Correct instantiation and usage.
rg --type java -A 5 $'new LocalFileConfigRepository(someAppId, $_)'

Length of output: 68

Script:

#!/bin/bash
# Description: Search for the declaration and usage of `someAppId` in the codebase.

# Find the declaration of `someAppId`.
rg --type java 'someAppId'

# Find all usages of `someAppId` to understand its context.
rg --type java '\bsomeAppId\b'

Length of output: 167870

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (6)

68-68: Refactor: Use Table for CONFIG_REGISTRY.

The change from a Map to a Table allows for a more structured storage of configurations, associating both an application ID and a namespace with each configuration object. This is a positive change that aligns with the PR's objectives to support multiple app IDs.

94-101: Update: prepareConfig method signature and logic.

The addition of the appId parameter to the prepareConfig method is consistent with the PR's goal of supporting multiple app IDs. The method now correctly uses the appId when creating a SimpleConfig instance and when mocking the config. This change enhances the flexibility and specificity of configuration management within the test framework.

122-130: Update: prepareYamlConfigFile method signature and logic.

The method now requires an appId as an argument, which is used to create and mock a YamlConfigFile. This change is necessary for the support of multiple app IDs and ensures that configuration files are fetched correctly based on the new key format.

170-171: Refactor: mockConfig and mockConfigFile methods to support multiple app IDs.

The methods have been updated to include appId in their signatures and logic. This is crucial for correctly storing and retrieving configurations based on both the app ID and namespace, supporting the new Table structure in CONFIG_REGISTRY and the modified key format in CONFIG_FILE_REGISTRY.

Also applies to: 178-180

219-220: Refactor: Default appId handling in MockConfigManager.

The MockConfigManager class now defaults to using a specific appId ("someAppId") when only the namespace is provided. This change ensures backward compatibility with existing tests that may not specify an appId. However, it's important to ensure that this default behavior is clearly documented to avoid confusion.

Consider adding documentation or comments in the code to explain the default behavior of using "someAppId" when appId is not specified.

Also applies to: 233-234

223-228: Update: getConfig and getConfigFile methods in MockConfigManager.

These methods have been updated to handle the new appId parameter, allowing them to retrieve configurations and configuration files based on the new registry structure. The implementation ensures that configurations are fetched correctly based on both the app ID and namespace, which is essential for the new functionality introduced in this PR.

Also applies to: 237-238

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XMLConfigAnnotationTest.java (2)

53-53: Addition of someAppId constant.

The addition of the someAppId constant is a good practice for maintaining consistency across test cases. This ensures that all tests are aligned with the new feature of handling multiple app IDs.

60-61: Updated mockConfig method calls to include someAppId.

The changes to the mockConfig method calls across various test methods are consistent with the PR's objective to support multiple app IDs. By adding someAppId as the first parameter, the tests now reflect the updated method signature and are aligned with the new configuration handling capabilities.

It's important to ensure that these changes are reflected in the actual implementation of the mockConfig method to avoid any runtime errors or misconfigurations. Additionally, the consistency of these changes across different test methods helps maintain uniformity in testing scenarios.

Also applies to: 74-74, 84-85, 139-139, 148-148, 158-159

Verification successful

Verification Successful: mockConfig Method Updated

The mockConfig method has been updated to accept three parameters, including someAppId, as confirmed by its definition in AbstractSpringIntegrationTest.java. This aligns with the review comment and supports the changes made in the test files to handle multiple app IDs.

  • Location of mockConfig method definition:
    • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the `mockConfig` method has been updated to accept three parameters.

# Test: Search for the `mockConfig` method definition. Expect: Method definition with three parameters.
rg --type java -A 5 $'mockConfig'

Length of output: 95736

Script:

#!/bin/bash
# Use ast-grep to find the definition of the `mockConfig` method and verify its parameters.
ast-grep --lang java --pattern $'void mockConfig($_, $_, $_) { $$$ }'

Length of output: 70

Script:

#!/bin/bash
# Use rg to search for any method named `mockConfig` to verify its parameters.
rg --type java 'void mockConfig' -A 3

Length of output: 3955

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (7)

62-62: Initialization of someAppId

The initialization of someAppId with "someAppId" is straightforward and aligns with the PR's objective to handle multiple app IDs. This setup is crucial for the tests that follow, ensuring they operate under the correct application context.

191-204: Use of appIdAndNamespace helper method in checkNamespaceName

The introduction of the appIdAndNamespace method suggests a future integration of the appId into namespace handling. Currently, it returns only the namespace, but this setup indicates potential enhancements. It's important to monitor this method for future changes that might incorporate the appId more directly into the logic.

84-84: Modification to createConfigRepository method call

The method createConfigRepository now requires an appId along with the namespace. This change is consistent with the PR's goal to support multiple app IDs. It's important to ensure that all calls to this method across the codebase have been updated to pass the appId as this could break existing functionality if overlooked.

Verification successful

Verification Successful: All createConfigRepository Calls Updated

All instances of the createConfigRepository method in the codebase have been updated to include the appId parameter, ensuring consistency with the updated method signature. No issues were found.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all calls to `createConfigRepository` include the `appId`.

# Test: Search for the method usage. Expect: Only occurrences with two parameters.
rg --type java -A 5 $'createConfigRepository'

Length of output: 5181

117-117: Modification to createPropertiesCompatibleFileConfigRepository method call

The method now includes an additional parameter for the appId, which is in line with the changes needed to support multiple app IDs. This adjustment is critical and should be checked across the codebase to ensure consistency and avoid runtime errors.

Verification successful

Verification Successful: All calls to createPropertiesCompatibleFileConfigRepository include the appId parameter. The codebase is consistent with the changes needed to support multiple app IDs, as described in the review comment. No further action is required.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all calls to `createPropertiesCompatibleFileConfigRepository` include the `appId`.

# Test: Search for the method usage. Expect: Only occurrences with three parameters.
rg --type java -A 5 $'createPropertiesCompatibleFileConfigRepository'

Length of output: 2599

136-138: Repeated modifications to createLocalConfigRepository method call

The method is called multiple times with different namespaces but now includes the appId. This repetition confirms the need to handle multiple configurations simultaneously, aligning with the PR's objectives. It's essential to ensure that these changes are reflected wherever this method is used.

Verification successful

Consistent usage of createLocalConfigRepository method with appId parameter

The createLocalConfigRepository method is consistently used with the appId parameter across the codebase, including in test files. This confirms that the changes are reflected as intended. No further action is needed.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify repeated calls to `createLocalConfigRepository` include the `appId`.

# Test: Search for the method usage. Expect: Multiple occurrences with two parameters.
rg --type java -A 5 $'createLocalConfigRepository'

Length of output: 6773

216-216: Modification to trimNamespaceFormat method call

The method now includes someAppId as a parameter, which is necessary for the new functionality to handle multiple app IDs. This change is crucial and should be verified across the project to ensure that it doesn't introduce any regressions.

Verification successful

Verification Successful: All calls to trimNamespaceFormat include appId

The method trimNamespaceFormat is consistently called with the appId parameter across the codebase, as required by the recent changes. No regressions are introduced by this modification.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all calls to `trimNamespaceFormat` include the `appId`.

# Test: Search for the method usage. Expect: Only occurrences with three parameters.
rg --type java -A 5 $'trimNamespaceFormat'

Length of output: 2363

99-99: Modification to createLocalConfigRepository method call

This change reflects the addition of someAppId to the method signature, which is necessary for the new multi-app ID support. It's crucial to verify that this method's usage throughout the project has been updated accordingly.

Verification successful

All usages of createLocalConfigRepository have been updated correctly. The method is consistently called with two parameters, appId and namespace, across the codebase, confirming the update for multi-app ID support. No further action is needed.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all calls to `createLocalConfigRepository` include the `appId`.

# Test: Search for the method usage. Expect: Only occurrences with two parameters.
rg --type java -A 5 $'createLocalConfigRepository'

Length of output: 6773

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (3)

109-109: Enhancement: Support for multiple app IDs.

The use of StringUtils.defaultIfBlank ensures that a default appId is used if none is specified in the annotation. This change supports the PR's objective to handle multiple app IDs effectively.

111-111: Correct use of environment placeholders.

Resolving placeholders for both appId and namespace ensures that the configuration can dynamically adapt to different environments, which is crucial for applications that may operate under varying configurations.

113-113: Update to ConfigService.getConfig call.

The method now correctly handles multiple configurations by accepting both resolvedAppId and resolvedNamespace. This change is essential for the flexibility required in multi-application environments.

apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/StringUtils.java (1)

343-345: Review of the defaultIfBlank method.

The method defaultIfBlank is correctly implemented and aligns with the PR's objective to enhance configuration capabilities by allowing a default value for blank strings. The use of isBlank to check the string condition is appropriate and leverages existing functionality effectively.

  • Correctness: The method correctly checks if the string s is blank and returns appId if true, otherwise returns s.
  • Logic: The logic is straightforward and efficient, using a ternary operator for a concise return statement.
  • Performance: The method is efficient as it uses existing logic from isBlank and involves minimal computation.
  • Integration: This method integrates well with the existing utility class and follows the established pattern of utility methods.

Overall, this addition is a valuable enhancement to the StringUtils class, providing a useful utility method for handling blank strings in configurations.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (3)

68-69: Refactor: Simplified constructor delegation.

The constructor now delegates to the more general constructor using null for appId. This is a good use of constructor chaining to avoid code duplication.

240-241: Refactor: Method Overloading for onRepositoryChange.

The method now supports handling changes with an appId, which aligns with the new multi-app ID feature. This change ensures that the correct app context is maintained when processing repository changes.

274-274: Refactor: Calculation of property changes.

The method calcPropertyChanges is now correctly scoped to handle appId and namespace, which is essential for accurate configuration management in environments with multiple apps. Ensure that this method is robust against potential edge cases where properties might not change but the environment does.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5)

75-75: Addition of m_appId field.

The addition of the m_appId field is consistent with the PR's objective to handle multiple app IDs. This change allows the class to store the application ID, which is crucial for the new functionality.

160-160: Update to fireRepositoryChange method call.

The method now includes m_appId as an argument, which is necessary for the enhanced functionality of handling multiple app IDs. This change ensures that the application ID is considered when firing repository changes.

191-194: Use of m_appId in loadApolloConfig method.

The method now directly uses m_appId instead of calling m_configUtil.getAppId(). This change is crucial for ensuring that the correct application ID is used in configuration retrieval processes, especially in environments with multiple applications.

336-336: Modification in scheduleLongPollingRefresh method.

The method now passes m_appId along with m_namespace to the remoteConfigLongPollService.submit method. This update is essential for maintaining the functionality of long polling in the context of multiple app IDs.

93-97: Constructor modification to include appId.

The constructor now requires an appId parameter, which is a significant change. This modification aligns with the PR's goal to support multiple app IDs. It's important to ensure that all instantiations of this class across the project are updated to pass the appId parameter.

Verification successful

Constructor usage updated successfully.

All instances of the RemoteConfigRepository constructor across the codebase have been updated to include the appId parameter, as intended. No further action is required.

  • Instances found in RemoteConfigRepositoryTest.java and DefaultConfigFactory.java confirm the update.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all constructor calls to `RemoteConfigRepository` match the new signature.

# Test: Search for the constructor usage. Expect: Only occurrences of the new signature.
rg --type java -A 5 $'new RemoteConfigRepository'

Length of output: 8134

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (10)

60-61: Introduction of someAppId constant.

The addition of the someAppId constant is a positive change, promoting better maintainability and readability by centralizing the application ID used in tests. This aligns with the PR's objective to handle multiple app IDs.

96-96: Proper use of someAppId in configuration setup.

The use of someAppId in the mockConfig method call correctly reflects the PR's intent to enhance configuration flexibility by supporting multiple app IDs.

140-141: Effective use of someAppId for multiple namespace configurations.

The use of someAppId for configuring multiple namespaces in the test setup is a clear demonstration of the enhanced flexibility provided by the PR. This is a crucial aspect of supporting multiple app IDs.

176-180: Consistent use of someAppId in YAML configuration setup.

The introduction of someAppId in the preparation of YAML configuration files and its consistent use in configuring multiple namespaces enhances the test's configurability and aligns well with the PR's goals.

218-218: Correct application of someAppId in failed conditional test setup.

The use of someAppId in the configuration setup for a test scenario where the condition fails is appropriate and demonstrates the PR's intent to enhance configurability across different test scenarios.

250-250: Appropriate use of someAppId in YAML file preparation for conditional off scenario.

The use of someAppId to prepare a YAML configuration file for a test scenario with conditions turned off is consistent with the PR's goals and enhances test configurability.

284-284: Proper application of someAppId in conditional off test setup.

The use of someAppId in the configuration setup for a test scenario with conditions turned off is appropriate and demonstrates the PR's intent to enhance configurability across different test scenarios.

414-414: Effective use of someAppId in eager load enabled test setup.

The use of someAppId in the configuration setup for a test scenario with eager load enabled is appropriate and demonstrates the PR's intent to enhance configurability across different test scenarios.

353-353: Correct application of someAppId in bootstrap disabled and conditional on test setup.

The use of someAppId in the configuration setup for a test scenario where bootstrap is disabled and conditions are on is appropriate and demonstrates the PR's intent to enhance configurability across different test scenarios.

382-382: Proper application of someAppId in bootstrap disabled and conditional off test setup.

The use of someAppId in the configuration setup for a test scenario where bootstrap is disabled and conditions are off is appropriate and demonstrates the PR's intent to enhance configurability across different test scenarios.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (2)

78-80: Review the initialization of ConcurrentHashMap and Maps for tracking long polling and namespaces.

The use of ConcurrentHashMap for m_longPollStarted and Maps.newConcurrentMap() for m_longPollNamespaces is appropriate given the need for thread-safe operations in a potentially concurrent environment. This change aligns with the PR's goal to handle multiple app IDs effectively.

299-300: Review the assembleNamespaces method adaptation for multi-app support.

The method has been adapted to handle multiple app IDs by fetching namespaces specific to an app ID. This change is crucial for ensuring that the long polling URLs are correctly assembled with the appropriate namespaces for each app. The implementation is straightforward and aligns well with the overall enhancements made for multi-app support.

apollo-client/src/test/java/com/ctrip/framework/apollo/integration/ConfigIntegrationTest.java (1)

374-374: Approved change in timeout duration, suggest verifying test performance impact.

The increase in timeout duration from 5000 to 10000 milliseconds in the longPollFinished.get() method call is approved as it likely accommodates slower network conditions or server responses. However, it's important to verify that this change does not negatively impact the overall test performance or its effectiveness in catching issues within a reasonable time frame.

Run the following script to verify the impact on test performance:

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (1)

272-272: Verify: Ensure correct parameters in onRepositoryChange method.

The onRepositoryChange method is called with someAppId and someNamespace as parameters. Verify that these parameters are correctly used within the method and that the method's implementation aligns with the new requirements for handling multiple app IDs.

Also applies to: 321-321

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (2)

457-465: Review of fireConfigChange method changes:

The addition of the appId parameter to the fireConfigChange method aligns with the PR's objectives to support multiple app IDs. The method correctly passes the appId to the InterestedConfigChangeEvent.

Suggestion:
Ensure that the appId is correctly integrated and utilized in other parts of the system where this method is called.

Line range hint 570-605: Review of calcPropertyChanges method changes:

The method now includes an appId parameter and uses it when creating ConfigChange objects. This change supports the PR's goal of handling configurations for multiple apps and ensures that changes are associated with the correct app ID.

Suggestion:
Verify that the appId is being used correctly across all instances where ConfigChange objects are created or processed.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderAutoUpdateTest.java (14)

44-44: Good practice: Centralizing configuration values.

The introduction of the someAppId constant is a positive change, enhancing maintainability by avoiding hardcoded values throughout the test cases.

Line range hint 56-68: Correct usage of the new constant in test scenarios.

The method testAutoUpdateWithOneNamespace correctly uses the someAppId constant, aligning with the PR's objectives to centralize configuration values. This change enhances the readability and maintainability of the test code.

Line range hint 91-103: Consistent application of the new constant.

The method testAutoUpdateDisabled consistently uses the someAppId constant in its configuration setup and repository change calls. This consistency is crucial for maintaining the integrity of the test suite.

123-125: Effective demonstration of configuration flexibility.

The method testAutoUpdateWithMultipleNamespaces effectively uses the someAppId constant to demonstrate the new configuration's flexibility across different namespaces. This is a key enhancement in the context of the PR's objectives.

Line range hint 168-181: Robust testing of complex scenarios.

The method testAutoUpdateWithMultipleNamespacesWithSameProperties uses the someAppId constant to robustly test the scenario where multiple namespaces are updated with the same properties. This ensures that the new configuration approach can handle complex updates effectively.

Line range hint 198-212: Proper testing of new properties integration.

The method testAutoUpdateWithNewProperties correctly uses the someAppId constant to test the integration of new properties. This aligns with the PR's objectives and demonstrates the test's adaptability to configuration changes.

Line range hint 233-247: Testing robustness against irrelevant property changes.

The method testAutoUpdateWithIrrelevantProperties effectively uses the someAppId constant to test the system's robustness against irrelevant property changes. This is crucial for ensuring that the configuration system is resilient.

Line range hint 263-274: Effective handling of property deletions.

The method testAutoUpdateWithDeletedProperties uses the someAppId constant to effectively test the configuration system's handling of property deletions. This ensures that the system can adapt to changes in configuration without issues.

293-295: Robust testing of property deletions across multiple namespaces.

The method testAutoUpdateWithMultipleNamespacesWithSamePropertiesDeleted uses the someAppId constant to robustly test the scenario where properties are deleted across multiple namespaces. This ensures that the new configuration approach can handle complex updates effectively.

Line range hint 323-334: Testing handling of deletions without default values.

The method testAutoUpdateWithDeletedPropertiesWithNoDefaultValue uses the someAppId constant to test the configuration system's handling of property deletions without default values. This scenario is important for ensuring robustness in more dynamic configurations.

Line range hint 352-364: Testing handling of type mismatches in properties.

The method testAutoUpdateWithTypeMismatch uses the someAppId constant to test the configuration system's handling of type mismatches in properties. This is crucial for ensuring that the system can adapt to incorrect data types without causing failures.

Line range hint 382-394: Highlighting limitations with constructor-injected values.

The method testAutoUpdateWithValueInjectedAsConstructorArgs uses the someAppId constant but importantly highlights a limitation of the current system where updates for constructor-injected values are not supported. This is a crucial observation for future enhancements.

Line range hint 413-425: Effective handling of both value and property updates.

The method testAutoUpdateWithValueAndProperty uses the someAppId constant to effectively test the configuration system's handling of both value and property updates. This ensures that the system can adapt to changes in configuration without issues.

Line range hint 472-501: Comprehensive testing of updates across all data types.

The method testAutoUpdateWithAllKindsOfDataTypes uses the someAppId constant to comprehensively test the configuration system's handling of updates across all data types. This is crucial for ensuring that the system can adapt to diverse configuration needs.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (2)

595-600: Implementation of getAccessKeySecret in MockConfigUtil.

The new method getAccessKeySecret in the MockConfigUtil class is designed to return a secret based on the provided appId. This is a critical addition for testing access control based on application identifiers.

The implementation checks if the provided appId matches someAppId and returns someSecret if true, otherwise returns null. This logic is straightforward and aligns with the requirements for differentiating access based on app IDs. Ensure that this method is covered by unit tests to verify its behavior under different conditions.

149-149: Updated method signatures in test cases to include someAppId.

The method submit now correctly includes someAppId as part of its signature in all test cases, aligning with the changes in the RemoteConfigLongPollService class. This is crucial for ensuring that the tests reflect the new functionality of handling multiple app IDs.

It's important to verify that all instances where submit is called have been updated to pass someAppId. Additionally, ensure that the new parameter is being used correctly within the method implementations.

Also applies to: 200-200, 262-262, 333-333, 336-336, 404-404, 405-405, 465-465

Verification successful

Verification Successful: Updated method signatures include someAppId.

The submit method in RemoteConfigLongPollService correctly includes someAppId in its signature and uses it appropriately within the method implementation. All instances where submit is called have been updated to pass someAppId, aligning with the changes in the RemoteConfigLongPollService class.

  • RemoteConfigLongPollService.java: Lines 110-126
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all calls to `submit` include `someAppId` and check its usage within the method.

# Test: Search for the method usage. Expect: Only occurrences with `someAppId`.
rg --type java -A 5 $'submit'

Length of output: 17743

Script:

#!/bin/bash
# Extract the implementation of the `submit` method from `RemoteConfigLongPollService` to verify the usage of `someAppId`.
ast-grep --lang java --pattern $'class RemoteConfigLongPollService {
  $$$
  public boolean submit(String appId, String namespace, RemoteConfigRepository remoteConfigRepository) {
    $$$
  }
  $$$
}'

Length of output: 201

Script:

#!/bin/bash
# Adjust the pattern to more flexibly capture the `submit` method implementation in `RemoteConfigLongPollService`.
ast-grep --lang java --pattern $'public boolean submit(String appId, String namespace, RemoteConfigRepository remoteConfigRepository) {
  $$$
}'

Length of output: 2670

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderTest.java (21)

63-63: Introduction of someAppId constant.

The introduction of the someAppId constant is a positive change as it centralizes the application ID, enhancing maintainability and readability. This change aligns with the PR's objective to support multiple app IDs.

74-74: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

82-82: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

95-95: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

111-111: Refactor to include someAppId in mockConfigFile.

The modification to include someAppId as an argument in mockConfigFile is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

127-127: Refactor to include someAppId in mockConfigFile.

The modification to include someAppId as an argument in mockConfigFile is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

139-139: Refactor to include someAppId in mockConfig for multiple namespaces.

The modification to include someAppId as an argument in mockConfig for both ConfigConsts.NAMESPACE_APPLICATION and FX_APOLLO_NAMESPACE is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID for multiple namespaces.

Also applies to: 143-143

161-161: Refactor to include someAppId in mockConfigFile and mockConfig.

The modification to include someAppId as an argument in both mockConfigFile and mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID for multiple configurations.

Also applies to: 165-165

180-180: Refactor to include someAppId in mockConfig for multiple namespaces.

The modification to include someAppId as an argument in mockConfig for both ConfigConsts.NAMESPACE_APPLICATION and FX_APOLLO_NAMESPACE is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID for multiple namespaces.

Also applies to: 184-184

199-199: Refactor to include someAppId in mockConfig for multiple namespaces.

The modification to include someAppId as an argument in mockConfig for both ConfigConsts.NAMESPACE_APPLICATION and FX_APOLLO_NAMESPACE is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID for multiple namespaces.

Also applies to: 203-203

217-217: Refactor to include someAppId in mockConfig for multiple namespaces.

The modification to include someAppId as an argument in mockConfig for both ConfigConsts.NAMESPACE_APPLICATION and FX_APOLLO_NAMESPACE is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID for multiple namespaces.

Also applies to: 221-221

235-235: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

254-254: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

276-276: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

297-297: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

315-315: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

338-338: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

360-360: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

378-378: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

409-409: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

428-428: Refactor to include someAppId in mockConfig.

The modification to include someAppId as an argument in mockConfig is consistent with the PR's objectives and enhances the test's clarity by explicitly specifying the app ID.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java (4)

74-74: Addition of someAppId variable.

The addition of the someAppId variable aligns with the PR's objective to handle multiple app IDs. This change is crucial for testing configurations specific to different applications.

95-95: Initialization of someAppId and someNamespace.

Proper initialization of someAppId and someNamespace in the setUp method ensures that these variables are correctly set up before each test. This is a necessary change to support the new functionality.

142-142: File path construction using someAppId and someNamespace.

The construction of file paths using both someAppId and someNamespace is a significant change that supports the feature of handling configurations for multiple apps. This approach allows for more granular management of configuration files.

719-719: Modification in ConfigChangeEvent constructor.

The update to include someAppId in the ConfigChangeEvent constructor is crucial for tracking configuration changes per app ID. This change supports the PR's goal of enhancing configuration management by allowing more detailed tracking and management of changes.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (19)

81-81: Introduction of someAppId variable.

The introduction of the someAppId static variable is a key part of supporting multiple app IDs. This change aligns with the PR's objectives to enhance configuration capabilities.

116-117: Correct use of someAppId in configuration mocking.

The method correctly uses the someAppId variable to mock configurations, ensuring that the configurations are associated with the correct application ID. This is a crucial part of supporting multiple app IDs.

Also applies to: 119-119

135-135: Consistent use of someAppId for specific application ID testing.

The method correctly uses the someAppId variable to mock configurations for testing configurations with a wrong field type, aligning with the PR's objectives.

145-147: Proper use of someAppId in inheritance testing.

The method correctly uses the someAppId variable to mock configurations in a scenario involving inheritance, demonstrating the flexibility and robustness of the new feature.

161-164: Effective use of someAppId in expression resolution testing.

The method effectively uses the someAppId variable to mock configurations for testing the resolution of expressions, aligning with the PR's objectives to enhance configuration capabilities.

Line range hint 176-185: Accurate use of someAppId in system property expression resolution testing.

The method accurately uses the someAppId variable to mock configurations for testing the resolution of expressions from system properties, demonstrating the robustness of the new feature in handling complex scenarios.

197-198: Proper handling of someAppId in unresolved value testing.

The method properly uses the someAppId variable to mock configurations for testing the handling of unresolved values, aligning with the PR's objectives to enhance configuration capabilities.

212-213: Effective use of someAppId in configuration change listener testing.

The method effectively uses the someAppId variable to mock configurations and set up listeners for testing the configuration change listener functionalities, demonstrating the robustness of the new feature in handling dynamic scenarios.

266-266: Consistent use of someAppId for specific application ID testing in error scenarios.

The method correctly uses the someAppId variable to mock configurations for testing configurations with a wrong parameter type, aligning with the PR's objectives.

275-275: Consistent use of someAppId for specific application ID testing in error scenarios.

The method correctly uses the someAppId variable to mock configurations for testing configurations with a wrong parameter count, aligning with the PR's objectives.

285-286: Proper use of someAppId in inheritance testing for configuration change listeners.

The method correctly uses the someAppId variable to mock configurations and set up listeners in a scenario involving inheritance, demonstrating the flexibility and robustness of the new feature.

342-343: Effective use of someAppId in configuration change listener testing with interested keys.

The method effectively uses the someAppId variable to mock configurations and set up listeners for testing the configuration change listener functionalities with interested keys, demonstrating the robustness of the new feature in handling dynamic scenarios.

374-374: Accurate use of someAppId in configuration change listener testing with interested key prefixes.

The method accurately uses the someAppId variable to mock configurations for testing the configuration change listener functionalities with interested key prefixes, aligning with the PR's objectives to enhance configuration capabilities.

400-407: Effective use of someAppId in dynamic testing of configuration change listeners with interested key prefixes.

The method effectively uses the someAppId variable to mock configurations and set up listeners for testing the configuration change listener functionalities with interested key prefixes in a dynamic scenario, demonstrating the robustness of the new feature in handling changes.

Line range hint 439-450: Accurate use of someAppId in configuration change listener testing with a YAML file.

The method accurately uses the someAppId variable to prepare a YAML configuration file and set up listeners for testing the configuration change listener functionalities with a YAML file, aligning with the PR's objectives to enhance configuration capabilities.

464-467: Effective use of someAppId in expression resolution testing for configuration change listeners.

The method effectively uses the someAppId variable to mock configurations for testing the resolution of expressions in configuration change listeners, demonstrating the robustness of the new feature in handling complex scenarios.

502-508: Effective use of someAppId in configuration change listener testing with comma-separated namespaces.

The method effectively uses the someAppId variable to mock configurations for multiple namespaces, demonstrating the robustness of the new feature in handling scenarios involving multiple configurations.

527-533: Accurate use of someAppId in configuration change listener testing with comma-separated namespaces merged with ones in value.

The method accurately uses the someAppId variable to mock configurations for multiple namespaces, aligning with the PR's objectives to enhance configuration capabilities in scenarios involving complex configurations.

548-553: Accurate use of someAppId in system property expression resolution testing for configuration change listeners.

The method accurately uses the someAppId variable to mock configurations for testing the resolution of expressions from system properties in configuration change listeners, aligning with the PR's objectives to enhance configuration capabilities.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderAutoUpdateTest.java (16)

55-55: Introduction of someAppId constant.

The introduction of the someAppId constant is a positive change as it centralizes the application ID, enhancing maintainability and reducing the risk of errors associated with hardcoded strings. This change aligns well with the PR's objective to support multiple app IDs.

74-74: Consistent use of someAppId in testAutoUpdateWithOneNamespace.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 129-129

101-101: Consistent use of someAppId in testAutoUpdateWithOneYamlFile.

The method correctly uses the someAppId constant in the prepareYamlConfigFile call, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 161-161

129-129: Consistent use of someAppId in testAutoUpdateWithValueAndXmlProperty.

The method correctly uses the someAppId constant in the prepareConfig call, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 199-199

229-229: Consistent use of someAppId in testAutoUpdateWithMultipleNamespaces.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 241-241

270-270: Consistent use of someAppId in testAutoUpdateWithMultipleNamespacesWithSameProperties.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 283-283

298-298: Consistent use of someAppId in testAutoUpdateWithMultipleNamespacesWithSamePropertiesWithYamlFile.

The method correctly uses the someAppId constant in both prepareYamlConfigFile and prepareConfig calls, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 303-303

328-328: Consistent use of someAppId in testAutoUpdateWithNewProperties.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 340-340

354-354: Consistent use of someAppId in testAutoUpdateWithNewPropertiesWithYamlFile.

The method correctly uses the someAppId constant in the prepareYamlConfigFile call, aligning with the PR's objectives and enhancing code maintainability.

385-385: Consistent use of someAppId in testAutoUpdateWithIrrelevantProperties.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 397-397

413-413: Consistent use of someAppId in testAutoUpdateWithDeletedProperties.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 424-424

437-437: Consistent use of someAppId in testAutoUpdateWithDeletedPropertiesWithYamlFile.

The method correctly uses the someAppId constant in the prepareYamlConfigFile call, aligning with the PR's objectives and enhancing code maintainability.

Also applies to: 447-447

465-465: Consistent use of someAppId in testAutoUpdateWithMultipleNamespacesWithSamePropertiesDeleted.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

494-494: Consistent use of someAppId in testAutoUpdateWithDeletedPropertiesWithNoDefaultValue.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

523-523: Consistent use of someAppId in testAutoUpdateWithTypeMismatch.

The method correctly uses the someAppId constant in both prepareConfig and onRepositoryChange calls, aligning with the PR's objectives and enhancing code maintainability.

549-549: Consistent use of someAppId in testAutoUpdateWithTypeMismatchWithYamlFile.

The method correctly uses the someAppId constant in the prepareYamlConfigFile call, aligning with the PR's objectives and enhancing code maintainability.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactoryManager.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java Show resolved Hide resolved
...ient/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java Outdated Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java Show resolved Hide resolved
nobodyiam
nobodyiam requested changes Sep 14, 2024
View reviewed changes
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java Outdated Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
...ient/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java Outdated Show resolved Hide resolved
coderabbitai[bot]
coderabbitai bot reviewed Sep 30, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🧹 Outside diff range and nitpick comments (3)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (3)

106-126: Optimize Iteration Over APP_NAMESPACE_NAMES

In the initializePropertySources method, the nested loops over orders, appIds, and namespaces could be optimized for readability and performance.

Consider simplifying the iteration:

for (Map.Entry<Integer, Multimap<String, String>> entry : APP_NAMESPACE_NAMES.entrySet()) {
    int order = entry.getKey();
    Multimap<String, String> appMultimap = entry.getValue();
    for (Map.Entry<String, String> appNamespaceEntry : appMultimap.entries()) {
        String appId = appNamespaceEntry.getKey();
        String namespace = appNamespaceEntry.getValue();
        Config config = ConfigService.getConfig(appId, namespace);
        composite.addPropertySource(configPropertySourceFactory.getConfigPropertySource(
            appId + ConfigConsts.CLUSTER_NAMESPACE_SEPARATOR + namespace, config));
    }
}

This approach reduces the number of iterations and may improve performance.

178-178: Consistent Clearing of Static Collections in reset Method

Ensure that the reset method clears all relevant static collections to avoid unintended state retention during tests.

Consider confirming that all static collections are cleared:

 public static void reset() {
     APP_NAMESPACE_NAMES.clear();
     AUTO_UPDATE_INITIALIZED_BEAN_FACTORIES.clear();
+    // Any other static collections should be cleared here
 }

This helps maintain a clean state between test runs.

Line range hint 23-50: Remove Unused Imports

There are several unused import statements which can be removed to clean up the code.

Consider removing the following unused imports:

  • import java.util.HashMap; (line 35)
  • import org.springframework.util.CollectionUtils; (line 50)

This helps in maintaining code cleanliness.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 38469c4 and bd959e6.

📒 Files selected for processing (2)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (6 hunks)
🔇 Additional comments (1)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (1)

126-126: Verify Safe Clearing of APP_NAMESPACE_NAMES

Clearing APP_NAMESPACE_NAMES after initialization might lead to issues if addNamespaces is called afterward. Ensure that addNamespaces is not intended to be used post-initialization.

Run the following script to check for any calls to addNamespaces after initializePropertySources:

✅ Verification successful

Safe Clearing of APP_NAMESPACE_NAMES Confirmed

No invocations of addNamespaces were found after initializePropertySources, ensuring that clearing APP_NAMESPACE_NAMES does not lead to unintended namespace additions post-initialization.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find calls to addNamespaces after initializePropertySources.
# Expected Result: No calls to addNamespaces after initializePropertySources.

rg --type java -A 5 -B 5 "initializePropertySources" | awk '/initializePropertySources/,0' | rg "addNamespaces"

Length of output: 107

Script:

#!/bin/bash
# Description: Search for invocations of addNamespaces within 10 lines after initializePropertySources in Java files.
# Expected Result: No invocations of addNamespaces after initializePropertySources.

rg --type java "initializePropertySources" -A 10 | rg "addNamespaces"

Length of output: 67

...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
nobodyiam
nobodyiam requested changes Oct 1, 2024
View reviewed changes
Copy link
Member

@nobodyiam nobodyiam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your hard work on the pull request; I believe it's nearing approval. Please see my comments below.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java Outdated Show resolved Hide resolved
...-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated
Comment on lines 118 to 119
if(repositoryMultimap == null){
repositoryMultimap = Multimaps.synchronizedSetMultimap(HashMultimap.<String, RemoteConfigRepository>create());
m_longPollNamespaces.put(appId, repositoryMultimap);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to consider a race condition here. For example, two threads submitting different namespaces with the same appid.

apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java Show resolved Hide resolved
...ient/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java Outdated Show resolved Hide resolved
...ient/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java Outdated Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
@nobodyiam
Copy link
Member

I have changed the Email for submitting code to [email protected], and changed the name to TerryLam2010. Have not submitted open source request merge before,help me please....

emm...You may first backup the local repo and try the following:

1. git checkout main
2. git checkout -b 20240703-apollo-multiple-appid-new
3. git merge --squash 20240703-apollo-multiple-appid
4. git commit -m "some commit message"
5. git push origin 20240703-apollo-multiple-appid-new:20240703-apollo-multiple-appid

I noticed the CLA check failed again, and it seems the original commits are back. Is there some mistaken operation on the branch?

image

coderabbitai[bot]
coderabbitai bot reviewed Oct 16, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 30

🧹 Outside diff range and nitpick comments (61)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/XmlConfigFile.java (1)

25-27: LGTM! Consider adding Javadoc for the new parameter.

The addition of the appId parameter to the constructor is well-implemented and aligns with the PR objective of supporting multiple app IDs. The change is correct and follows good practices.

Consider adding Javadoc to document the new appId parameter:

+/**
+ * Constructs a new XmlConfigFile.
+ *
+ * @param appId The ID of the application
+ * @param namespace The namespace for the configuration
+ * @param configRepository The configuration repository
+ */
 public XmlConfigFile(String appId, String namespace,
                      ConfigRepository configRepository) {
   super(appId, namespace, configRepository);
 }
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/JsonConfigFile.java (1)

25-27: LGTM! Consider adding a brief Javadoc comment.

The constructor change looks good and aligns with the PR objective of adding support for multiple app IDs. The implementation is correct and consistent.

Consider adding a brief Javadoc comment to explain the purpose of the appId parameter:

/**
 * Constructs a new JsonConfigFile.
 *
 * @param appId The ID of the application this config file belongs to
 * @param namespace The namespace of the config file
 * @param configRepository The repository to fetch configurations from
 */
public JsonConfigFile(String appId, String namespace,
                      ConfigRepository configRepository) {
    super(appId, namespace, configRepository);
}
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java (1)

32-38: LGTM! The new method signature enhances functionality while maintaining backward compatibility.

The addition of the onRepositoryChange(String appId, String namespace, Properties newProperties) method aligns well with the PR objectives of supporting multiple app IDs. This change allows for more granular control over repository changes by including the appId parameter.

Consider adding a brief explanation in the Javadoc about when this new method would be called instead of the existing one. This could help implementers understand the use cases for each method. For example:

/**
 * Invoked when config repository changes for a specific app ID.
 * This method is called when the change is associated with a particular application.
 * @param appId the appId of this repository change
 * @param namespace the namespace of this repository change
 * @param newProperties the properties after change
 */
apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigRegistry.java (1)

50-57: LGTM: New getFactory method with appId parameter.

The new getFactory method with appId parameter is well-implemented and documented. It aligns with the PR objectives of supporting multiple app IDs and extends the existing functionality in a consistent manner.

Consider adding a @since tag to the Javadoc to indicate the version in which this method was introduced. This can help users understand when this functionality became available. For example:

/**
 * Get the registered config factory for the namespace.
 *
 * @param appId the appId
 * @param namespace the namespace
 * @return the factory registered for this appId and namespace
 * @since 2.4.0
 */
ConfigFactory getFactory(String appId, String namespace);
apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactory.java (1)

51-57: Approve with minor documentation update needed.

The addition of this method aligns well with the PR objective of supporting multiple app IDs. The method signature is consistent with the existing interface. However, the Javadoc comment needs to be updated to include information about the configFileFormat parameter.

Please update the Javadoc comment to include all parameters:

/**
 * Create the config file instance for the appId and namespace.
 * @param appId the appId
 * @param namespace the namespace
 * @param configFileFormat the format of the config file
 * @return the newly created config file instance
 */
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (2)

52-57: Approved with a minor suggestion for the JavaDoc.

The new appId parameter is well-implemented and aligns with the PR objectives. It provides the desired functionality for supporting multiple app IDs while maintaining backward compatibility with the default empty string.

Consider slightly rewording the JavaDoc for clarity:

 /**
- * Apollo appId for the config, if not specified then default to the global appid
+ * Apollo appId for the config. If not specified, defaults to the global appId.
  *
  * @since 2.4.0
  */

Line range hint 20-38: Enhance class-level JavaDoc to explain the relationship between appId and value.

The addition of the appId parameter alongside the existing value parameter provides powerful configuration capabilities. To help users understand how to use these parameters together effectively, consider updating the class-level JavaDoc.

Add an explanation of how appId and value work together in the class-level JavaDoc. For example:

/**
 * Use this annotation to inject Apollo Config Instance.
 *
 * <p>Usage example:</p>
 * <pre class="code">
 * //Inject the config for "someNamespace"
 * &#064;ApolloConfig("someNamespace")
 * private Config config;
 * </pre>
 *
 * <p>Usage example with placeholder:</p>
 * <pre class="code">
 * // The namespace could also be specified as a placeholder, e.g. ${redis.namespace:xxx},
 * // which will use the value of the key "redis.namespace" or "xxx" if this key is not configured.
 * &#064;ApolloConfig("${redis.namespace:xxx}")
 * private Config config;
 * </pre>
 *
 * <p>Usage example with appId:</p>
 * <pre class="code">
 * // Inject the config for a specific appId and namespace
 * &#064;ApolloConfig(appId = "someAppId", value = "someNamespace")
 * private Config config;
 * </pre>
 *
 * <p>The `appId` parameter allows you to specify a different Apollo application ID for this particular config.
 * If not provided, it defaults to the global appId. The `value` parameter specifies the namespace within the
 * chosen application. This combination enables fine-grained control over configuration sources.</p>
 *
 * @author Jason Song([email protected])
 */

This addition will help users understand how to leverage both parameters effectively.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java (1)

54-57: LGTM: Updated TxtConfigFile instantiation and appId assertion

The changes in the testWhenHasContent method correctly incorporate the new appId functionality:

  1. The TxtConfigFile constructor now includes someAppId as a parameter.
  2. A new assertion verifies that the appId is correctly set in the TxtConfigFile.

These changes are consistent with the PR objective and improve the test coverage.

As suggested in a previous review, consider adding more comprehensive tests to cover various scenarios and edge cases involving appId. This will ensure robust coverage of the new functionality. Would you like assistance in drafting additional test cases?

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (1)

34-40: Approve with suggestions for improvement

The addition of this method aligns well with the PR objectives to support multiple app IDs. However, there are a couple of minor improvements we can make:

  1. The method documentation can be enhanced for clarity. Consider using the following format:
/**
 * Get the config instance for the namespace and appId specified.
 * @param appId the appId
 * @param namespace the namespace
 * @return the config instance for the appId and namespace
 */
  1. There's a minor spacing inconsistency in the method signature. Add a space after the comma for better readability:
Config getConfig(String appId, String namespace);
apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (1)

78-84: The getAppId() method is correctly implemented.

The new method is well-structured and consistent with the class design. However, there's a minor improvement that can be made to the JavaDoc comment.

Consider updating the JavaDoc comment to accurately reflect the method's purpose:

 /**
- * Get the appId of this change event.
- * @return the namespace
+ * Get the appId associated with this change event.
+ * @return the appId
  */
 public String getAppId() {
   return m_appId;
 }
apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistryTest.java (2)

66-69: LGTM! Consider adding a comment for clarity.

The addition of this method aligns with the PR objective of supporting multiple app IDs. The implementation is correct for a mock object in a test class.

Consider adding a comment to explain why this method returns null, for example:

 @Override
 public Config create(String appId, String namespace) {
+  // Return null for mock implementation
   return null;
 }

76-79: LGTM! Consider adding a comment for clarity.

The addition of this method aligns with the PR objective of supporting multiple app IDs. The implementation is correct for a mock object in a test class.

Consider adding a comment to explain why this method returns null, for example:

 @Override
 public ConfigFile createConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) {
+  // Return null for mock implementation
   return null;
 }
apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (1)

Line range hint 89-99: Consider updating the toString() method

The toString() method has not been updated to include the new appId field. Consider adding it to provide a complete string representation of the object.

Here's a suggested update:

 @Override
 public String toString() {
   final StringBuilder sb = new StringBuilder("ConfigChange{");
+  sb.append("appId='").append(appId).append('\'');
+  sb.append(", ");
   sb.append("namespace='").append(namespace).append('\'');
   sb.append(", propertyName='").append(propertyName).append('\'');
   sb.append(", oldValue='").append(oldValue).append('\'');
   sb.append(", newValue='").append(newValue).append('\'');
   sb.append(", changeType=").append(changeType);
   sb.append('}');
   return sb.toString();
 }
apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (2)

Line range hint 1-91: Summary: Good progress on multi-app support, consider broader impact

The changes to PureApolloConfig.java are minimal but significant, adding support for multiple app IDs as required. However, to ensure full implementation of multi-app support, consider reviewing and potentially updating related classes, especially the superclass DefaultConfig and any other classes that interact with app IDs.

It might be beneficial to conduct a broader review of the entire module to ensure consistent handling of multiple app IDs across all relevant classes and methods.

AppId handling missing in superclass methods

The getProperty and getPropertyNames methods in AbstractConfig do not handle the appId parameter. This may affect proper multi-app support. Please update these methods to utilize appId appropriately.

🔗 Analysis chain

Line range hint 54-91: Verify handling of appId in superclass methods

The getProperty and getPropertyNames methods remain unchanged and don't directly use the appId parameter. To ensure proper multi-app support, we should verify that these methods (or their superclass implementations) correctly utilize the appId when retrieving properties.

Please run the following script to check the implementation of these methods in the DefaultConfig class:

If these methods in DefaultConfig don't handle the appId, consider updating them to ensure proper multi-app support.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check the implementation of getProperty and getPropertyNames in DefaultConfig

# Test: Search for getProperty and getPropertyNames methods in DefaultConfig
ast-grep --lang java --pattern $'class DefaultConfig {
  $$$
  getProperty($$$) {
    $$$
  }
  $$$
  getPropertyNames($$$) {
    $$$
  }
  $$$
}'

Length of output: 147

Script:

#!/bin/bash
# Description: Verify the existence of DefaultConfig class and its methods

# Check if DefaultConfig.java exists in the codebase
rg --files --type java 'DefaultConfig\.java'

# If DefaultConfig.java is found, search for getProperty and getPropertyNames methods within it
rg 'public\s+String\s+getProperty\s*\(.*\)' DefaultConfig.java
rg 'public\s+Set<\s*String\s*>\s+getPropertyNames\s*\(.*\)' DefaultConfig.java

# If methods are not found in DefaultConfig, search in its superclass
# First, identify the superclass of DefaultConfig
SUPERCLASS=$(rg 'public\s+class\s+DefaultConfig\s+extends\s+(\w+)' DefaultConfig.java -o | awk '{print $4}')

# If a superclass is identified, search for the methods in the superclass
if [ -n "$SUPERCLASS" ]; then
  SUPERCLASS_FILE=$(rg --files --type java "${SUPERCLASS}\.java")
  if [ -n "$SUPERCLASS_FILE" ]; then
    rg 'public\s+String\s+getProperty\s*\(.*\)' "$SUPERCLASS_FILE"
    rg 'public\s+Set<\s*String\s*>\s+getPropertyNames\s*\(.*\)' "$SUPERCLASS_FILE"
  else
    echo "Superclass file for $SUPERCLASS not found."
  fi
else
  echo "No superclass found for DefaultConfig."
fi

Length of output: 645

Script:

#!/bin/bash
# Description: Locate DefaultConfig class and its methods across the codebase

# Search for the class definition of DefaultConfig in all Java files
rg 'public\s+class\s+DefaultConfig\b' --type java --context 2

# If DefaultConfig class is found, extract the file paths
DEFAULT_CONFIG_FILES=$(rg 'public\s+class\s+DefaultConfig\b' --type java --files-with-matches)

# If DefaultConfig.java files are found, search for the specified methods within them
if [ -n "$DEFAULT_CONFIG_FILES" ]; then
  for file in $DEFAULT_CONFIG_FILES; do
    echo "Searching in $file:"
    rg 'public\s+String\s+getProperty\s*\(.*\)' "$file"
    rg 'public\s+Set<\s*String\s*>\s+getPropertyNames\s*\(.*\)' "$file"
  done
else
  echo "No class named DefaultConfig found in any Java files."
fi

Length of output: 1609

Script:

#!/bin/bash
# Description: Locate AbstractConfig class and verify handling of appId in its methods

# Search for the class definition of AbstractConfig in all Java files
rg 'public\s+abstract\s+class\s+AbstractConfig\b' --type java --context 2

# Extract the file paths containing AbstractConfig class
ABSTRACT_CONFIG_FILES=$(rg 'public\s+abstract\s+class\s+AbstractConfig\b' --type java --files-with-matches)

# If AbstractConfig class is found, search for getProperty and getPropertyNames methods within it
if [ -n "$ABSTRACT_CONFIG_FILES" ]; then
  for file in $ABSTRACT_CONFIG_FILES; do
    echo "Inspecting $file:"
    
    # Extract the getProperty method
    rg -C 5 'public\s+String\s+getProperty\s*\(.*\)' "$file"
    
    # Extract the getPropertyNames method
    rg -C 5 'public\s+Set<\s*String\s*>\s+getPropertyNames\s*\(.*\)' "$file"
    
    # Search for usage of appId within getProperty method
    echo "Checking getProperty method for appId handling:"
    rg 'getProperty\s*\(.*appId.*\)' "$file"
    
    # Search for usage of appId within getPropertyNames method
    echo "Checking getPropertyNames method for appId handling:"
    rg 'getPropertyNames\s*\(.*appId.*\)' "$file"
  done
else
  echo "No class named AbstractConfig found in any Java files."
fi

Length of output: 1974

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java (2)

58-59: LGTM: Updated method calls and verifications

The changes correctly reflect the updated method signatures in DefaultConfigFactory, now including both appId and namespace parameters. The test logic is maintained while accommodating the new parameter.

Consider extracting the someAppId and someNamespace arguments into variables at the beginning of the test method for improved readability and easier maintenance. For example:

@Test
public void testCreateFileEnableConfigRepository() throws Exception {
    String testAppId = someAppId;
    String testNamespace = someNamespace;
    
    LocalFileConfigRepository someLocalConfigRepository = mock(LocalFileConfigRepository.class);
    when(someConfigUtil.isPropertyFileCacheEnabled()).thenReturn(true);
    doReturn(someLocalConfigRepository).when(configFactory)
        .createLocalConfigRepository(testAppId, testNamespace);
    ConfigRepository configRepository = configFactory.createConfigRepository(testAppId, testNamespace);
    assertSame(someLocalConfigRepository, configRepository);
    verify(configFactory, times(1)).createLocalConfigRepository(testAppId, testNamespace);
    verify(configFactory, never()).createRemoteConfigRepository(testAppId, testNamespace);
}

This approach would make it easier to use different test values if needed in the future.

Also applies to: 61-62

70-71: LGTM: Updated method calls and verifications

The changes correctly reflect the updated method signatures in DefaultConfigFactory, now including both appId and namespace parameters. The test logic is maintained while accommodating the new parameter, and the changes are consistent with those made in the testCreateFileEnableConfigRepository method.

As suggested for the testCreateFileEnableConfigRepository method, consider extracting the someAppId and someNamespace arguments into variables at the beginning of this test method as well. This would improve readability and make it easier to use different test values if needed in the future.

Also applies to: 73-74

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (2)

45-46: LGTM with a minor suggestion.

The addition of someAppId aligns with the PR objective of supporting multiple app IDs. However, consider using a more realistic app ID value or making it clear that this is a test value.

You could improve this by using a more descriptive name like TEST_APP_ID and potentially adding a comment explaining its purpose in the test:

private static final String TEST_APP_ID = "test-app-id";
// This represents a sample app ID used for testing multiple app ID support

Line range hint 45-77: Overall LGTM with a suggestion for improved test coverage.

The changes in this file consistently implement support for multiple app IDs, aligning well with the PR objective. The test logic remains intact while incorporating the new app ID parameter.

To further improve the test coverage:

Consider adding a test case that verifies the behavior with multiple different app IDs to ensure the system correctly handles distinct configurations for different applications. This could involve creating multiple ConfigChange objects with different app IDs and verifying that they are processed correctly.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/SimpleConfigTest.java (1)

Line range hint 138-151: LGTM with a minor suggestion: Updates in testOnRepositoryChange

The changes in this method are well-implemented and consistent with the PR objective:

  1. The SimpleConfig constructor call now includes someAppId.
  2. The onRepositoryChange method call has been updated to include someAppId.
  3. A new assertion verifies that the changeEvent contains the correct appId.

These updates ensure that the test case properly handles and verifies the new app ID functionality.

Consider adding a constant for the "someAppId" string to improve maintainability:

private static final String SOME_APP_ID = "someAppId";

Then use SOME_APP_ID instead of the string literal throughout the test class.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java (1)

Line range hint 1-194: Summary of changes and suggestions for next steps

The changes in this file consistently introduce and use the someAppId variable across multiple test methods, which aligns well with the PR objective of adding support for multiple app IDs. This improves the maintainability and consistency of the test code.

Suggestions for next steps:

  1. Verify the fireConfigChange method signature change across the codebase using the provided script.
  2. Consider adding assertions for the new fireConfigChange method call in the testFireConfigChange_cannot_notify method.
  3. Update the class-level or file-level documentation to mention the support for multiple app IDs, if not already done in other files.
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (2)

58-59: LGTM: Setting APP_ID system property

Setting the APP_ID system property in the setUp method ensures consistency across all tests. This change aligns well with the PR objective of supporting multiple app IDs.

Consider adding a tearDown step to clear this system property after tests, ensuring a clean state for other test classes:

@After
public void tearDown() throws Exception {
    System.clearProperty(ApolloClientSystemConsts.APP_ID);
    // ... other tearDown operations
}

81-87: LGTM: Updated test to incorporate app ID in configurations and assertions

The changes in the testInitializePropertySources method correctly integrate the someAppId into the configuration mocking and property source name assertions. This ensures that the tests accurately reflect the new multi-app ID support.

For improved readability, consider extracting the expected property source name construction into a separate method:

private String getExpectedPropertySourceName(String appId, String namespace) {
    return appId + ConfigConsts.CLUSTER_NAMESPACE_SEPARATOR + namespace;
}

Then use it in the assertions:

assertEquals(getExpectedPropertySourceName(someAppId, namespaceName), propertySource.getName());
assertEquals(getExpectedPropertySourceName(someAppId, anotherNamespaceName), anotherPropertySource.getName());

This would make the test more maintainable if the naming convention changes in the future.

Also applies to: 105-107

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepositoryTest.java (5)

122-122: LGTM! Consider adding an assertion for appId.

The change correctly updates the LocalFileConfigRepository constructor to include the someAppId parameter. This aligns with the new signature mentioned in the summary.

Consider adding an assertion to verify that the appId is correctly set in the LocalFileConfigRepository instance. This would enhance the test coverage for the new parameter.

138-138: LGTM! Consider testing appId influence.

The change correctly updates the LocalFileConfigRepository constructor to include the someAppId parameter. This aligns with the new signature mentioned in the summary.

Consider adding a test case that verifies how different appId values affect the behavior of LocalFileConfigRepository. This would ensure that the new parameter is correctly influencing the repository's functionality.

164-165: LGTM! Consider testing with different appId values.

The changes correctly update both LocalFileConfigRepository constructor calls to include the someAppId parameter. This aligns with the new signature mentioned in the summary.

Consider adding a test case that uses different appId values for the two LocalFileConfigRepository instances. This would verify that the appId parameter correctly influences the behavior when loading configurations multiple times.

Also applies to: 171-171

187-188: LGTM! Consider additional assertions for appId handling.

The changes correctly update the LocalFileConfigRepository constructor and onRepositoryChange method calls to include the someAppId parameter. The verification of the listener has also been updated accordingly. These changes align with the new signatures mentioned in the summary.

Consider adding assertions to verify that the appId is correctly propagated through the repository change event. For example, you could check that the Properties object passed to the listener contains any appId-specific configurations.

Also applies to: 204-204, 208-208

Line range hint 1-238: Overall LGTM! Consider enhancing tests for appId functionality.

The changes in this file consistently update the LocalFileConfigRepository constructor calls and relevant method invocations to include the new appId parameter. This aligns well with the goal of supporting multiple app IDs as mentioned in the PR objectives.

To further improve the test coverage and ensure the robustness of the new multi-app ID feature:

  1. Consider adding test cases that use different appId values to verify that configurations are correctly isolated between different apps.
  2. Add assertions to check that the appId is correctly propagated through various operations (loading, updating, repository change events).
  3. Test edge cases, such as empty or null appId values, to ensure proper error handling.
  4. Consider adding a test that verifies the behavior when switching between different appId values within the same LocalFileConfigRepository instance, if applicable.

These enhancements would provide more comprehensive coverage of the new functionality and help catch any potential issues related to the multi-app ID support.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java (1)

Line range hint 1-244: Consider adding tests for app ID-specific scenarios

While the changes to include someAppId are consistent across all test methods, consider adding new test cases that specifically verify the behavior of XmlConfigFile with different app IDs. This could help ensure that the multi-app ID support is thoroughly tested.

apollo-mockserver/src/main/java/com/ctrip/framework/apollo/mockserver/ApolloTestingServer.java (2)

179-179: Approve change with suggestion for improvement

The modification to use someAppId in LocalFileConfigRepository initialization is a step towards supporting multiple app IDs, which aligns with the PR objectives. However, to fully leverage this change and provide maximum flexibility, consider the following improvement:

public Properties loadPropertiesOfNamespace(String appId, String namespace) {
    String filename = String.format("mockdata-%s-%s.properties", appId, namespace);
    // ... (existing code for checking mockdata properties)
    
    return new LocalFileConfigRepository(appId, namespace).getConfig();
}

This approach would allow testing with different app IDs without modifying the someAppId static variable, providing more flexibility in mock scenarios.

Line range hint 1-248: Summary of changes and suggestions for improvement

The modifications to ApolloTestingServer.java introduce support for app ID in the mock server, which aligns with the PR objectives. However, the current implementation using a static someAppId limits the flexibility intended by this change.

To fully realize the goal of supporting multiple app IDs and enhance the mock server's capabilities:

  1. Make someAppId configurable as suggested in the first comment.
  2. Modify methods like loadPropertiesOfNamespace to accept an app ID parameter, allowing for dynamic app ID usage in tests.
  3. Update other relevant methods in this class to support multiple app IDs where applicable.

These enhancements would provide a more robust and flexible mock server implementation, better serving the needs of various testing scenarios.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (6)

84-86: LGTM with suggestion: Update to testCreate method

The changes correctly reflect the updated method signatures to include the someAppId parameter. This is in line with the PR objective of supporting multiple app IDs.

Consider adding an assertion to verify that the created config is associated with the correct app ID. This could be done by exposing the app ID in the DefaultConfig class and asserting it in the test.

99-99: LGTM with suggestion: Update to testCreateLocalConfigRepositoryInLocalDev method

The change correctly reflects the updated method signature to include the someAppId parameter, which is in line with the PR objective.

Consider adding an assertion to verify that the created LocalFileConfigRepository is associated with the correct app ID. This could be done by exposing the app ID in the LocalFileConfigRepository class and asserting it in the test.

117-119: LGTM with suggestion: Update to testCreatePropertiesCompatibleFileConfigRepository method

The changes correctly reflect the updated method signatures to include the someAppId parameter, which is consistent with the PR objective of supporting multiple app IDs.

Consider adding an assertion to verify that the created config is associated with the correct app ID. This could be done by exposing the app ID in the DefaultConfig class and asserting it in the test.

136-138: LGTM with suggestion: Update to testCreateConfigFile method

The changes correctly reflect the updated method signatures to include the someAppId parameter for createLocalConfigRepository calls. This is in line with the PR objective of supporting multiple app IDs.

Consider adding assertions to verify that the created config files are associated with the correct app ID. This could be done by exposing the app ID in the respective config file classes (e.g., PropertiesConfigFile, XmlConfigFile, etc.) and asserting it in the test for each created config file.

206-208: Suggestion: Add TODO comment for appIdAndNamespace method

The appIdAndNamespace method has been introduced, but it currently just returns the namespace unchanged. This appears to be a placeholder for future functionality.

Consider adding a TODO comment to explain the intended future use of this method. For example:

 private String appIdAndNamespace(String namespace){
+  // TODO: Implement logic to combine appId and namespace for multi-app support
   return namespace;
 }

Line range hint 1-231: Overall assessment: Changes align with PR objective, with room for improvement

The changes in this file consistently add support for the someAppId parameter across various test methods, which aligns well with the PR objective of adding support for multiple app IDs.

However, there are a few areas where the test coverage and clarity could be improved:

  1. Consider adding assertions to verify that the created configs and repositories are associated with the correct app ID in various test methods.
  2. Clarify the purpose and future plans for the appIdAndNamespace method and its usage in testTrimNamespaceFormat.
  3. Ensure that the changes in this test class accurately reflect the changes made in the main DefaultConfigFactory class.

As you continue to implement multi-app ID support, consider the following:

  1. Ensure consistent handling of app IDs across all relevant classes in the Apollo client.
  2. Update documentation to reflect the new multi-app ID functionality.
  3. Consider adding integration tests that verify the correct behavior when multiple app IDs are used in a real-world scenario.

These improvements will help ensure that the new functionality is robust and well-tested.

apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/StringUtils.java (1)

343-345: Approve with suggestions for improvement

The defaultIfBlank method is a good addition to the StringUtils class. It provides a useful utility for handling potentially blank strings with a default value. However, there are a few suggestions for improvement:

  1. Consider adding a null check for appId to prevent potential NullPointerExceptions. This could be done by using the existing defaultIfBlank method in a nested manner.

  2. Add method documentation (Javadoc) to explain the purpose, parameters, and return value of the method.

  3. Use a more descriptive name for the s parameter, such as str or input.

Here's a suggested implementation with these improvements:

/**
 * Returns the input string if it is not blank, otherwise returns the default appId.
 * If both the input string and appId are blank or null, returns null.
 *
 * @param input the input string to check
 * @param appId the default appId to return if the input is blank
 * @return the input string if not blank, the appId if input is blank, or null if both are blank or null
 */
public static String defaultIfBlank(String input, String appId) {
    return isBlank(input) ? (isBlank(appId) ? null : appId) : input;
}

This implementation handles the case where both input and appId might be null or blank, returning null in such cases. It also uses more descriptive parameter names and includes documentation.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (1)

Line range hint 1-468: Overall assessment: Consistent and well-structured changes

The modifications in this file demonstrate a systematic approach to introducing support for multiple app IDs in the Apollo Client test suite. Key observations:

  1. The someAppId constant has been consistently added to various method calls across different test scenarios, ensuring comprehensive coverage of the new functionality.
  2. The changes maintain consistency across different test classes and scenarios, including those with YAML configurations and various bootstrap settings.
  3. Some method signatures have been updated to include exception handling, potentially improving robustness in error scenarios.

These changes appear to be part of a larger refactoring effort to enhance the Apollo Client's capabilities. The consistency and thoroughness of the modifications are commendable, suggesting a well-planned implementation of the new feature.

As this change introduces support for multiple app IDs, ensure that:

  1. The documentation is updated to reflect this new capability.
  2. Any client-side code that interacts with the Apollo Client is reviewed for potential impacts.
  3. Performance implications of supporting multiple app IDs are considered and tested, especially in scenarios with a large number of app IDs.
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (2)

151-151: LGTM: Updated RemoteConfigRepository constructor calls.

The RemoteConfigRepository constructor calls have been consistently updated across all test methods to include the someAppId parameter. This change aligns with the modification of the RemoteConfigRepository constructor to accept an additional appId parameter.

Consider refactoring the creation of RemoteConfigRepository instances into a helper method to reduce code duplication:

private RemoteConfigRepository createRemoteConfigRepository() {
    return new RemoteConfigRepository(someAppId, someNamespace);
}

Then replace all instances of new RemoteConfigRepository(someAppId, someNamespace) with createRemoteConfigRepository().

Also applies to: 177-177, 214-214, 227-227, 240-240, 257-257, 293-293, 345-345

423-429: LGTM with suggestion: New getAccessKeySecret method.

The addition of the getAccessKeySecret(String appId) method in MockConfigUtil is consistent with the multi-app ID support. The implementation correctly returns someSecret for the matching appId.

Consider throwing an IllegalArgumentException for unrecognized app IDs instead of returning null. This would make the behavior more explicit and help prevent potential NullPointerExceptions:

@Override
public String getAccessKeySecret(String appId) {
    if (appId.equals(someAppId)) {
        return someSecret;
    }
    throw new IllegalArgumentException("Unrecognized appId: " + appId);
}

This change would require updating the tests to expect this exception for invalid app IDs, which could improve the robustness of your test suite.

apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (3)

311-320: LGTM! Consider adding parameter validation.

The new getDefaultLocalCacheDir(String appId) method correctly implements the functionality to determine the cache directory based on the provided appId. It reuses existing logic and is consistent with the current implementation.

Consider adding a null check for the appId parameter at the beginning of the method:

 public String getDefaultLocalCacheDir(String appId) {
+    if (Strings.isNullOrEmpty(appId)) {
+        throw new IllegalArgumentException("appId must not be null or empty");
+    }
     String cacheRoot = getCustomizedCacheRoot();
     // ... rest of the method
 }

This will prevent potential null pointer exceptions and provide clearer error messages.

524-526: LGTM! Consider adding parameter validation and Javadoc.

The new getAccessKeySecret(String appId) method correctly delegates to Foundation.app().getAccessKeySecret(appId), providing a way to get the access key secret for a specific app ID.

Consider the following improvements:

  1. Add parameter validation:
 public String getAccessKeySecret(String appId){
+    if (Strings.isNullOrEmpty(appId)) {
+        throw new IllegalArgumentException("appId must not be null or empty");
+    }
     return Foundation.app().getAccessKeySecret(appId);
 }
  1. Add Javadoc for better documentation:
/**
 * Get the access key secret for the specified application ID.
 *
 * @param appId the ID of the application
 * @return the access key secret for the specified application, or null if there is no such secret
 * @throws IllegalArgumentException if appId is null or empty
 */
public String getAccessKeySecret(String appId) {
    // ... implementation
}

These changes will improve the robustness and documentation of the method.

Action Required: Update Remaining Method Usages

Several instances of the old methods getDefaultLocalCacheDir() and getAccessKeySecret() remain in the codebase. Please update these to use the new methods with the appId parameter to ensure full support for multiple app IDs.

  • Files to update:
    • apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java
    • apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java
    • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/NullProvider.java
    • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java
    • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java
    • apollo-core/src/test/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProviderTest.java
🔗 Analysis chain

Line range hint 311-526: Overall assessment: Changes look good and align with PR objectives.

The additions to the ConfigUtil class successfully implement support for multiple app IDs as requested in issue #66. The new methods getDefaultLocalCacheDir(String appId) and getAccessKeySecret(String appId) are consistent with existing implementations and correctly use the provided app ID.

To ensure that these changes don't introduce any regressions, please run the following verification script:

This script will help identify any places where the new methods are being used and any potential spots where the old methods might need to be updated to use the new ones with specific app IDs.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the new methods are used consistently across the codebase

# Test: Search for usages of the new methods
echo "Searching for usages of getDefaultLocalCacheDir(String appId):"
rg --type java "getDefaultLocalCacheDir\([^)]+\)" --glob '!**/ConfigUtil.java'

echo "Searching for usages of getAccessKeySecret(String appId):"
rg --type java "getAccessKeySecret\([^)]+\)" --glob '!**/ConfigUtil.java'

# Test: Check for any remaining usages of the old methods that might need updating
echo "Checking for potential places to update to use the new methods:"
rg --type java "getDefaultLocalCacheDir\(\)" --glob '!**/ConfigUtil.java'
rg --type java "getAccessKeySecret\(\)" --glob '!**/ConfigUtil.java'

Length of output: 3914

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (2)

35-36: Assess the synchronization mechanism of m_instances

The use of Tables.synchronizedTable provides thread safety for m_instances. However, this may introduce performance overhead in highly concurrent environments. Evaluate whether a concurrent data structure, such as ConcurrentHashMap combined with appropriate locking mechanisms, might offer better scalability and performance.

48-65: Add unit tests for new methods with appId parameter

The introduction of methods that accept an appId parameter enhances functionality but also adds complexity. To ensure reliability, consider adding unit tests for register(String appId, String namespace, ConfigFactory factory) and getFactory(String appId, String namespace). Testing various scenarios and edge cases will help validate the correctness of these methods.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (1)

101-105: Ensure consistent return values in mock implementations.

In the MockConfigRegistry, the methods create(String appId, String namespace) and createConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) return null. For better test coverage and to avoid potential NullPointerExceptions during tests, consider returning mock objects or meaningful default values.

Also applies to: 111-115

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (3)

Line range hint 172-178: Remove unused parameter appId in trimNamespaceFormat method

The appId parameter in the trimNamespaceFormat method is not utilized within the method body. Keeping unused parameters can lead to confusion and may impact maintainability. Consider removing the appId parameter if it's unnecessary.

Apply this diff to remove the unused parameter:

- String trimNamespaceFormat(String appId, String namespaceName, ConfigFileFormat format) {
+ String trimNamespaceFormat(String namespaceName, ConfigFileFormat format) {
    String extension = "." + format.getValue();
    if (!namespaceName.toLowerCase().endsWith(extension)) {
        return namespaceName;
    }

    return namespaceName.substring(0, namespaceName.length() - extension.length());
}

Ensure to update all calls to trimNamespaceFormat accordingly.

88-89: Include appId in logging statements for better traceability

The debug log currently includes only the namespace. Incorporating the appId into the log message enhances clarity, especially when dealing with multiple application IDs.

Apply this diff to update the logging statement:

- logger.debug("Created a configuration repository of type [{}] for namespace [{}]",
-     configRepository.getClass().getName(), namespace);
+ logger.debug("Created a configuration repository of type [{}] for appId [{}] and namespace [{}]",
+     configRepository.getClass().getName(), appId, namespace);

Line range hint 71-92: Add null checks for appId parameter to prevent potential NullPointerException

To enhance robustness, it's advisable to validate the appId parameter. Adding null checks ensures that the method behaves predictably if a null appId is passed.

Apply this diff to add a null check in the create method:

public Config create(String appId, String namespace) {
+   if (appId == null) {
+     throw new IllegalArgumentException("appId must not be null");
+   }
    ConfigFileFormat format = determineFileFormat(namespace);
    // existing code

Consider adding similar checks to other methods accepting appId.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (1)

77-84: Simplify Map Initialization Using computeIfAbsent

In the addNamespaces(String appId, Collection<String> namespaces, int order) method, consider utilizing computeIfAbsent to simplify the initialization of the Multimap associated with each order. This approach enhances readability and conciseness.

Suggested change:

public static boolean addNamespaces(String appId, Collection<String> namespaces, int order) {
-    Multimap<String, String> multimap = APP_NAMESPACE_NAMES.get(order);
-    if (multimap == null) {
-      multimap = LinkedHashMultimap.create();
-      APP_NAMESPACE_NAMES.put(order, multimap);
-    }
+    Multimap<String, String> multimap = APP_NAMESPACE_NAMES.computeIfAbsent(order, k -> LinkedHashMultimap.create());
    return multimap.putAll(appId, namespaces);
}
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (1)

183-183: Use a Constant for the Repeated "someAppId" String

The string "someAppId" is hardcoded in multiple places throughout the code. Defining it as a constant would improve maintainability and readability.

Declare a static final constant at the beginning of the class:

 public abstract class AbstractSpringIntegrationTest {
+  private static final String DEFAULT_APP_ID = "someAppId";
   private static final Table<String, String, Config> CONFIG_REGISTRY = HashBasedTable.create();
   private static final Map<String, ConfigFile> CONFIG_FILE_REGISTRY = Maps.newHashMap();

Then, replace all occurrences of "someAppId" with DEFAULT_APP_ID:

 protected static void doSetUp() throws Exception {
-  System.setProperty(ApolloClientSystemConsts.APP_ID, "someAppId");
+  System.setProperty(ApolloClientSystemConsts.APP_ID, DEFAULT_APP_ID);
   //...
 }

 private static class MockConfigManager implements ConfigManager {
   //...
   @Override
   public Config getConfig(String namespace) {
-    return getConfig("someAppId", namespace);
+    return getConfig(DEFAULT_APP_ID, namespace);
   }

   @Override
   public ConfigFile getConfigFile(String namespace, ConfigFileFormat configFileFormat) {
-    return this.getConfigFile("someAppId", namespace, configFileFormat);
+    return this.getConfigFile(DEFAULT_APP_ID, namespace, configFileFormat);
   }
 }

 protected static class MockConfigUtil extends ConfigUtil {
   //...
   @Override
   public String getAppId() {
-    return "someAppId";
+    return DEFAULT_APP_ID;
   }
 }

This change enhances code consistency and simplifies future modifications to the default appId.

Also applies to: 214-215, 228-229, 253-256

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (1)

Line range hint 335-349: Consider Using Try-With-Resources for Resource Management

To enhance readability and ensure that the InputStream is properly closed even if an exception occurs during loading, consider using a try-with-resources statement for managing the InputStream.

Apply the following refactor:

private Properties loadFromResource(String appId, String namespace) {
    Properties properties = null;
    String name = String.format("META-INF/config/%s+%s.properties", appId, namespace);

-   InputStream in = ClassLoaderUtil.getLoader().getResourceAsStream(name);
-   if (StringUtils.equals(ApolloInjector.getInstance(ConfigUtil.class).getAppId(), appId)
-       && in == null) {
-     name = String.format("META-INF/config/%s.properties", namespace);
-     in = ClassLoaderUtil.getLoader().getResourceAsStream(name);
-   }
- 
-   if (in != null) {
+   try (InputStream in = getResourceAsStream(appId, name)) {
+     if (in != null) {
        properties = propertiesFactory.getPropertiesInstance();
        properties.load(in);
      }
    } catch (IOException ex) {
      Tracer.logError(ex);
      logger.error("Failed to load resource config for appId {} namespace {}", appId, namespace, ex);
    }
    return properties;
}

+private InputStream getResourceAsStream(String appId, String name) {
+   InputStream in = ClassLoaderUtil.getLoader().getResourceAsStream(name);
+   if (in == null && StringUtils.equals(ApolloInjector.getInstance(ConfigUtil.class).getAppId(), appId)) {
+     String fallbackName = String.format("META-INF/config/%s.properties", m_namespace);
+     in = ClassLoaderUtil.getLoader().getResourceAsStream(fallbackName);
+   }
+   return in;
+}
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (1)

93-95: Enhance Javadoc comment for appId parameter

Consider providing a more descriptive comment for the appId parameter to improve clarity.

Suggested change:

 /**
  * Constructor.
  *
-  * @param appId the appId
+  * @param appId the application ID
   * @param namespace the namespace
   */
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (1)

123-125: Simplify the check for long polling initiation

The check if (m_longPollStarted.get(appId) == null) can be simplified and made thread-safe by using putIfAbsent directly without the additional null check. Since startLongPolling already handles the concurrency control with putIfAbsent, the check in submit may be redundant. Consider removing the check or simplifying it.

Apply this diff if you decide to simplify:

-        if (m_longPollStarted.get(appId) == null) {
+        if (m_longPollStarted.putIfAbsent(appId, true) == null) {
           startLongPolling(appId);
         }
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (2)

99-101: Potential confusion due to overloading onRepositoryChange

Overloading the onRepositoryChange method by adding a new parameter appId may lead to confusion, especially if the method signatures are similar. This could affect maintainability and introduce potential bugs if the wrong method is called unintentionally.

Consider renaming the new method to better reflect its extended functionality or refactoring the design to avoid overloading methods with similar parameters.

Line range hint 102-125: Ensure consistent use of appId parameter within onRepositoryChange

In the onRepositoryChange(String appId, String namespace, Properties newProperties) method, the appId parameter is provided but not consistently used throughout the method. Specifically, m_appId is used when creating the ConfigFileChangeEvent instead of the appId parameter. If there is a possibility that appId differs from m_appId, this could lead to inconsistencies.

Ensure that the appId parameter is used consistently within the method to reflect the intended logic and avoid potential issues.

Apply this diff to use the appId parameter consistently:

         ...

         PropertyChangeType changeType = PropertyChangeType.MODIFIED;

         if (oldValue == null) {
           changeType = PropertyChangeType.ADDED;
         } else if (newValue == null) {
           changeType = PropertyChangeType.DELETED;
         }

-        this.fireConfigChange(new ConfigFileChangeEvent(m_appId, m_namespace, oldValue, newValue, changeType));
+        this.fireConfigChange(new ConfigFileChangeEvent(appId, namespace, oldValue, newValue, changeType));

         Tracer.logEvent("Apollo.Client.ConfigChanges", m_namespace);
       }
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (4)

81-81: Suggestion: Rename someAppId for Clarity

Consider renaming the someAppId constant to something more descriptive, such as defaultAppId, to enhance readability and better reflect its purpose in the tests.

81-81: Consider Documenting the Purpose of someAppId

Adding a comment to explain the role of someAppId in the tests can improve maintainability and help future developers understand its use.

470-471: Remove Unused MockInjector Setup

Lines 470-471 set up a MockConfigUtil instance, but there is no further usage shown in the provided code. Verify if this setup is necessary; if not, consider removing it to clean up the test.

Line range hint 41-44: Organize Import Statements

Consider organizing the import statements to follow a standard convention, such as grouping static imports separately and ordering them alphabetically, to improve code readability.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between bd959e6 and efc4d7f.

📒 Files selected for processing (78)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1 hunks)
  • apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfigFactory.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (7 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEvent.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/JsonConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (8 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepository.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/TxtConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/XmlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YmlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactory.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactoryManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigRegistry.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (6 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/spi/DefaultApolloConfigRegistrarHelper.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/build/MockInjector.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java (4 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java (30 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepositoryTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepositoryTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java (9 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (14 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/SimpleConfigTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/YamlConfigFileTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (3 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (7 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistryTest.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (8 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (29 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderAutoUpdateTest.java (40 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderTest.java (20 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XMLConfigAnnotationTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderAutoUpdateTest.java (25 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderTest.java (5 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java (1 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/StringUtils.java (1 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java (2 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/NullProvider.java (1 hunks)
  • apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java (1 hunks)
  • apollo-mockserver/src/main/java/com/ctrip/framework/apollo/mockserver/ApolloTestingServer.java (2 hunks)
  • apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiWhileCacheDirSpecifiedTest.java (1 hunks)
🧰 Additional context used
📓 Learnings (1)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (2)
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java:64-64
Timestamp: 2024-10-01T03:05:09.661Z
Learning: In the `PropertySourcesProcessor` class, the `APP_NAMESPACE_NAMES` map and its inner `Multimap` instances do not need to be thread-safe because concurrent access is not expected.

Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java:64-64
Timestamp: 2024-10-08T15:31:24.844Z
Learning: In the `PropertySourcesProcessor` class, the `APP_NAMESPACE_NAMES` map and its inner `Multimap` instances do not need to be thread-safe because concurrent access is not expected.
🔇 Additional comments (219)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/TxtConfigFile.java (1)

23-24: LGTM! Verify usage across the codebase.

The constructor change looks good and aligns with the PR objectives of adding support for multiple app IDs. The appId parameter has been correctly added and passed to the superclass constructor.

To ensure that this change doesn't break existing code, please verify all instantiations of TxtConfigFile across the codebase. Run the following script to find all occurrences:

Make sure to update all occurrences to include the appId parameter.

✅ Verification successful

Verified: All instantiations of TxtConfigFile correctly include the new appId parameter. No further action required.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all instantiations of TxtConfigFile to ensure they're updated with the new appId parameter.

# Search for TxtConfigFile instantiations
echo "Searching for TxtConfigFile instantiations:"
rg --type java -n "new TxtConfigFile\s*\("

# Search for references to TxtConfigFile constructor
echo "Searching for references to TxtConfigFile constructor:"
ast-grep --lang java --pattern 'new TxtConfigFile($$$)'

Length of output: 1006

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YmlConfigFile.java (1)

25-26: LGTM. Verify usage across the codebase.

The constructor change looks good and aligns with the PR objective of adding support for multiple app IDs. However, ensure that all instantiations of YmlConfigFile across the codebase have been updated to provide the new appId parameter.

To verify the impact and usage of this change, run the following script:

This script will help identify any locations where YmlConfigFile is instantiated or referenced, allowing you to verify that the appId parameter is correctly provided in all cases.

✅ Verification successful

Verification Successful: All YmlConfigFile Instances Updated

All instances of YmlConfigFile have been updated to include the new appId parameter. No missing usages found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for YmlConfigFile instantiations and ensure they include the appId parameter

# Search for YmlConfigFile instantiations
echo "Searching for YmlConfigFile instantiations:"
rg --type java "new YmlConfigFile\(" -A 2

# Search for references to YmlConfigFile to catch any factory methods or indirect instantiations
echo "\nSearching for YmlConfigFile references:"
rg --type java "YmlConfigFile" -A 2

Length of output: 2945

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/JsonConfigFile.java (2)

Line range hint 29-32: LGTM! Method remains correct and consistent.

The getConfigFileFormat method is unchanged and continues to correctly return ConfigFileFormat.JSON, which is consistent with the purpose of this class.

Line range hint 1-34: Overall, the changes look good and align with the PR objectives.

The addition of the appId parameter to the JsonConfigFile constructor successfully implements support for multiple app IDs as requested in the PR. The changes are clean, consistent, and don't introduce any apparent issues. The file's overall structure and purpose remain intact.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactoryManager.java (1)

31-37: Approve new method, update documentation, and consider implementation impact.

The new method signature getFactory(String appId, String namespace) is correct and aligns with the PR objectives to support multiple app IDs.

However, the documentation needs to be updated to reflect the purpose of the appId parameter. As suggested in the past review comment, please revise the documentation for clarity:

-  /**
-   * Get the config factory for the namespace.
-   *
-   * @param namespace the namespace
-   * @return the config factory for this namespace
-   */
+  /**
+   * Get the config factory for the given application ID and namespace.
+   *
+   * @param appId the application ID
+   * @param namespace the namespace
+   * @return the config factory for the specified application ID and namespace
+   */

Additionally, consider the impact of this new method on existing implementations of the ConfigFactoryManager interface. Ensure that all implementing classes are updated to support this new method.

To verify the impact on implementing classes, run the following script:

✅ Verification successful

Verified: All implementing classes properly implement the new method getFactory(String appId, String namespace) and documentation has been updated as required.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all implementations of ConfigFactoryManager and check if they implement the new method.

# Find all Java files that implement ConfigFactoryManager
implementers=$(rg --type java "class.*implements.*ConfigFactoryManager" -l)

# Check each implementer for the new method
for file in $implementers; do
  echo "Checking $file"
  if ! rg "getFactory\(String appId, String namespace\)" "$file" > /dev/null; then
    echo "WARNING: $file may need to be updated to implement the new method"
  fi
done

Length of output: 1041

apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfigFactory.java (1)

30-31: LGTM! Consider addressing backwards compatibility and documentation.

The changes to the createRepositoryConfig method align with the PR objectives of adding support for multiple app IDs. The implementation looks correct and straightforward.

However, there are a few points to consider:

  1. This change might break backwards compatibility for any code directly calling this method. Consider adding an overloaded method with the old signature that uses a default app ID for backwards compatibility.

  2. The class-level documentation should be updated to reflect this significant change in functionality.

Consider adding an overloaded method for backwards compatibility:

@Deprecated
protected Config createRepositoryConfig(String namespace, ConfigRepository configRepository) {
    return createRepositoryConfig(getDefaultAppId(), namespace, configRepository);
}

private String getDefaultAppId() {
    // Implement logic to get the default app ID
}

Let's verify the impact of this change on other parts of the codebase:

This script will help identify any potential areas that might need to be updated due to this change.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PlainTextConfigFile.java (2)

27-28: Verify appId usage in superclass and consider method updates

While the constructor change is correct, it's important to ensure that the appId is being utilized effectively in the superclass AbstractConfigFile. Additionally, consider if any of the existing methods (getContent(), hasContent(), update(Properties)) should be updated to make use of the appId in their logic.

To verify the usage of appId in the superclass, please run the following script:

This will allow us to review how appId is being used in the superclass and determine if any further changes are needed in PlainTextConfigFile.

✅ Verification successful

AppId usage in superclass is correctly handled

The appId is appropriately utilized within the AbstractConfigFile superclass. All necessary methods effectively leverage appId, ensuring that PlainTextConfigFile functions as intended without requiring further modifications.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check the implementation of AbstractConfigFile for appId usage

# Test: Display the content of AbstractConfigFile
fd -t f AbstractConfigFile.java | xargs cat

Length of output: 5899

27-28: LGTM! Constructor updated as suggested.

The constructor has been correctly updated to include the appId parameter, which aligns with the PR objectives of supporting multiple app IDs. The super call has also been appropriately modified to pass the new parameter.

To ensure consistent usage across the codebase, please run the following script:

This will help identify any locations where PlainTextConfigFile is instantiated, allowing us to verify that all calls have been updated with the new appId parameter.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/MultipleConfig.java (4)

1-20: LGTM: File header and package declaration are correct.

The license header, package declaration, and import statement are all present and correct. This follows best practices for Java file organization.

21-30: Improve the Javadoc for the MultipleConfig annotation.

While the current Javadoc provides basic information, it could be enhanced for clarity and completeness. Consider updating it as follows:

/**
 * This annotation is used as a supplement to @EnableApolloConfig to fill in
 * multiple appId.
 *
 * @author Terry.Lam
 * @since 2.4.0
 */

This change provides a more concise and grammatically correct description of the annotation's purpose.

31-51: Enhance Javadoc for annotation elements.

The Javadoc comments for the annotation elements could be more descriptive. Consider the following improvements:

  1. For the appId() method:
/**
 * Specifies multiple application IDs.
 * @return A string containing comma-separated application IDs.
 */
String appId();
  1. For the namespaces() method:
/**
 * Specifies the namespaces to be loaded for the application IDs.
 * @return An array of namespace names.
 */
String[] namespaces();
  1. For the secret() method:
/**
 * Configures the secret key corresponding to the appId.
 * This is optional and can be omitted if no key is required.
 * The secret can also be specified using a placeholder, e.g., ${apollo.multiple.shop.secret}
 * @return The secret key or a placeholder string.
 */
String secret() default "";

These improvements provide more context and clarity about the purpose and usage of each element.

1-51: Overall assessment: The implementation meets the PR objectives.

The MultipleConfig annotation has been successfully implemented, addressing the feature request in issue #66. It provides the capability to specify multiple app IDs and their corresponding namespaces, which enhances the configuration management in Apollo.

The code structure is sound, and the annotation is properly defined. The suggested improvements are primarily focused on enhancing the documentation for better clarity and usability.

Great job on implementing this feature! Once the documentation improvements are made, this will be ready for merging.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigRegistry.java (2)

33-40: LGTM: New register method with appId parameter.

The new register method with appId parameter is well-implemented and documented. It aligns with the PR objectives of supporting multiple app IDs and extends the existing functionality in a consistent manner.

Line range hint 1-57: Verify implementation and usage of the updated interface.

The changes to the ConfigRegistry interface successfully introduce support for multiple app IDs, aligning with the PR objectives. The new methods complement the existing ones without breaking current functionality, maintaining backward compatibility.

To ensure a smooth integration:

  1. Verify that all implementing classes of ConfigRegistry are updated to support the new methods.
  2. Check for any usage of ConfigRegistry across the project that might benefit from the new app ID-specific methods.
  3. Consider updating relevant documentation and examples to showcase the new functionality.

Run the following script to identify implementing classes and usages of ConfigRegistry:

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/ConfigFactory.java (2)

35-42: LGTM: New method for creating Config with appId and namespace.

The addition of this method aligns well with the PR objective of supporting multiple app IDs. The method signature and documentation are clear and consistent with the existing interface.

Line range hint 1-57: Overall assessment: Changes align well with PR objectives.

The additions to the ConfigFactory interface successfully implement support for multiple app IDs as outlined in the PR objectives. The new methods are consistent with the existing interface design and improve the flexibility of configuration management. With the minor documentation update suggested earlier, these changes are ready for integration.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloConfig.java (1)

Line range hint 1-62: Summary: Implementation successfully adds support for multiple app IDs

The changes to ApolloConfig.java effectively implement the feature request from issue #66, allowing for the specification of multiple app IDs. The new appId parameter is well-integrated into the existing annotation, maintaining backward compatibility while providing the desired new functionality.

Key points:

  1. The new appId parameter is correctly implemented with appropriate documentation.
  2. Backward compatibility is maintained through the use of default values.
  3. The changes align with the PR objectives and address the feature request.

Minor suggestions for documentation improvements have been made to enhance clarity for users. Overall, this implementation successfully achieves the goals outlined in the PR objectives.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEvent.java (1)

44-47: LGTM! Verify usage across the codebase.

The addition of the appId parameter to the constructor and its inclusion in the superclass constructor call are correct and align with the PR objective of supporting multiple app IDs. This change enhances the configuration management capabilities as intended.

To ensure that this change doesn't break existing code, please run the following script to check for any usages of the InterestedConfigChangeEvent constructor that might need updating:

This will help identify any locations where the constructor is called and might need to be updated to include the new appId parameter.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/TxtConfigFileTest.java (2)

34-34: LGTM: Addition of someAppId variable

The addition of the someAppId variable is consistent with the PR objective of adding support for multiple app IDs. The variable is correctly declared as private, following good encapsulation practices.

41-41: LGTM: Initialization of someAppId in setUp method

The initialization of someAppId in the setUp method is appropriate. It ensures that each test starts with a clean, known state, which is a good practice in unit testing.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/ConfigManager.java (2)

50-57: LGTM: New method aligns with PR objectives

The addition of this method is well-implemented and aligns perfectly with the PR objectives to support multiple app IDs. The method signature is correct, the documentation is comprehensive, and the spacing is consistent. Great job!

Line range hint 1-57: Summary: Implementation aligns with PR objectives, minor improvements suggested

The changes to the ConfigManager interface successfully introduce support for multiple app IDs, addressing the feature request in issue #66. The new methods are well-implemented and documented.

To ensure consistency across the codebase:

Please run the following script to check for any other occurrences of getConfig or getConfigFile methods that might need similar updates:

This will help identify any other places where we might need to add support for the appId parameter.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigFile.java (1)

38-46: LGTM! Well-implemented default method.

The addition of the getAppId() method is well-executed:

  • It provides a default implementation returning null, ensuring backward compatibility.
  • The @since 2.4.0 annotation correctly indicates the version where this method was introduced.
  • The Javadoc comment is clear and concise.

This implementation addresses the concerns raised in previous reviews and follows good practices for interface evolution.

apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/NullProvider.java (1)

87-90: LGTM! Verify interface updates.

The new getAccessKeySecret(String appId) method is consistent with the class's null behavior and naming conventions. It's a good addition that likely corresponds to interface updates.

To ensure consistency across the codebase, please run the following script to verify the interface updates:

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepository.java (1)

46-46: LGTM! Verify consistency across the codebase.

The change to include configFile.getAppId() in the fireRepositoryChange method call aligns with the PR objective of adding support for multiple app IDs. This modification enhances the method's capability to handle configurations for specific applications.

To ensure consistency across the codebase, please run the following script:

This script will help us verify that:

  1. All calls to fireRepositoryChange now include the app ID.
  2. The method signature in the ConfigRepository interface or abstract class has been updated to include the app ID parameter.

Please review the output to ensure consistency across the codebase.

✅ Verification successful

Verified: Consistency across the codebase confirmed.

All instances of fireRepositoryChange now include the appId parameter, and the method signatures align correctly in the relevant classes.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for consistency in fireRepositoryChange method calls

# Search for all occurrences of fireRepositoryChange
echo "Searching for fireRepositoryChange method calls:"
rg --type java -A 2 'fireRepositoryChange\('

# Search for ConfigRepository interface or abstract class to verify method signature
echo "Searching for ConfigRepository interface or abstract class:"
rg --type java -A 10 'interface ConfigRepository|abstract class .*ConfigRepository'

Length of output: 4806

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigFileChangeEvent.java (5)

26-26: LGTM: Addition of appId field

The addition of the appId field is consistent with the PR objectives to support multiple app IDs. The field is correctly declared as private for encapsulation and final for immutability.

35-35: LGTM: Constructor updated to include appId

The constructor has been correctly updated to include the appId parameter. The Javadoc has been properly updated to reflect this change, and the appId field is correctly initialized in the constructor.

Also applies to: 41-43

50-52: LGTM: Addition of getAppId() method

The getAppId() method has been correctly added, providing access to the new appId field. This addresses the concern raised in the previous review comment about the absence of this method.

73-74: LGTM: toString() method updated to include appId

The toString() method has been correctly updated to include the appId field in the string representation of the object.

Line range hint 1-81: LGTM: Comprehensive updates to support appId

The changes to the ConfigFileChangeEvent class are comprehensive and consistent with the PR objectives to support multiple app IDs. All necessary updates have been made to incorporate the new appId field, maintaining the consistency of the class.

To ensure that these changes are properly integrated across the codebase, please run the following verification script:

This script will help identify any locations where the ConfigFileChangeEvent constructor or getAppId() method are used, ensuring that they have been updated to match the new signature and functionality.

✅ Verification successful

: The updates to ConfigFileChangeEvent and the integration of the appId field have been successfully verified across the codebase. All usages of the constructor and getAppId() method are consistent with the changes, ensuring comprehensive support for multiple app IDs.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of ConfigFileChangeEvent constructor and methods

# Test: Search for usages of ConfigFileChangeEvent constructor
echo "Usages of ConfigFileChangeEvent constructor:"
rg --type java -n "new ConfigFileChangeEvent\(" --context 2

# Test: Search for usages of getAppId() method
echo "Usages of getAppId() method:"
rg --type java -n "\.getAppId\(\)" --context 2

# Test: Search for potential missed updates in related classes
echo "Potential missed updates in related classes:"
rg --type java -n "ConfigFileChangeEvent" --context 2

Length of output: 45177

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java (4)

28-28: LGTM! The m_appId field has been correctly added.

The new field follows the class's naming convention and is properly declared as private and final. This change aligns with the suggestion from the previous review and enhances the class to support multiple app IDs.

36-38: The constructor has been correctly updated to include the appId parameter.

The changes to the constructor are well-implemented:

  1. The signature has been updated to include the appId parameter.
  2. The m_appId field is properly initialized.
  3. The order of parameters is logical and consistent with the class structure.

These changes effectively support the new multi-app ID feature.

Line range hint 1-85: Summary: The changes effectively implement the multi-app ID feature.

The modifications to the ConfigChangeEvent class successfully address the feature request outlined in issue #66. The implementation:

  1. Adds a new m_appId field to store the application ID.
  2. Updates the constructor to accept the appId parameter.
  3. Introduces a new getAppId() method to access the application ID.

These changes are well-integrated into the existing class structure and maintain the overall functionality while adding the new feature. The code style and conventions are consistent with the rest of the class.

To ensure a smooth integration of this feature:

  1. Update the JavaDoc comment for the getAppId() method as suggested.
  2. Verify and update all usages of the ConfigChangeEvent constructor across the codebase to include the new appId parameter.

Once these minor points are addressed, the implementation will be ready for merging.

36-37: Verify the usage of the updated constructor across the codebase.

The constructor signature has changed from two parameters to three parameters. While this change is correct and necessary for the new feature, it's important to ensure that all existing code using this class is updated accordingly.

Run the following script to identify potential areas that need updating:

Please review the results and update any code that instantiates ConfigChangeEvent to include the new appId parameter.

✅ Verification successful

All ConfigChangeEvent constructor usages have been updated to include the new appId parameter. No issues were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find usages of ConfigChangeEvent constructor that might need updating

# Search for ConfigChangeEvent instantiations
echo "Potential ConfigChangeEvent instantiations that might need updating:"
rg --type java "new ConfigChangeEvent\s*\(" -g '!ConfigChangeEvent.java'

# Search for methods that return ConfigChangeEvent
echo "\nMethods that return ConfigChangeEvent and might need updating:"
rg --type java "ConfigChangeEvent\s+\w+\s*\([^)]*\)\s*\{" -g '!ConfigChangeEvent.java'

Length of output: 2321

apollo-client/src/test/java/com/ctrip/framework/apollo/build/MockInjector.java (1)

76-77: LGTM: Restoration of the previous implementation.

The changes in the getInstance method of the InjectCustomizer class have been restored to the previous version as requested. The introduction of the local variable instance slightly improves readability without changing the functional behavior.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1)

66-69: LGTM! Verify impact on subclasses and callers.

The changes to the fireRepositoryChange method look good and align with the PR objectives to support multiple app IDs. The new appId parameter is correctly passed to all listeners.

To ensure the change doesn't break existing implementations, please run the following script to check for any subclasses or callers that might need updates:

✅ Verification successful

Verification Successful!

All callers of the fireRepositoryChange method have been appropriately updated to include the new appId parameter. No subclasses of AbstractConfigRepository were found, ensuring that the change is consistent and does not affect other parts of the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for subclasses of AbstractConfigRepository and callers of fireRepositoryChange

# Find subclasses of AbstractConfigRepository
echo "Subclasses of AbstractConfigRepository:"
ast-grep --lang java --pattern 'class $_ extends AbstractConfigRepository { $$ }'

# Find callers of fireRepositoryChange
echo "\nCallers of fireRepositoryChange:"
rg --type java 'fireRepositoryChange\s*\(' -A 3

Length of output: 2436

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/EnableApolloConfig.java (2)

72-78: LGTM! The new attribute aligns well with the PR objectives.

The addition of the multipleConfigs attribute successfully implements the support for multiple app IDs as outlined in the PR objectives. The implementation follows the suggestions from previous review comments, including:

  1. Using MultipleConfig[] as the attribute type.
  2. Setting a default empty array.
  3. Adding a clear Javadoc comment with version information.

This change enhances the EnableApolloConfig annotation's flexibility, allowing users to specify additional appId and namespace configurations.

72-78: Verify impact on monitoring metrics and update documentation

While the implementation of multipleConfigs looks good, there are a couple of points to consider:

  1. As mentioned in the PR comments, this change might impact monitoring metrics. It's important to ensure that the metrics system can handle multiple app IDs correctly.

  2. The broader implications of this feature should be documented, possibly in the class-level Javadoc or in separate documentation.

To address these points, please:

  1. Confirm that the monitoring metrics have been adjusted to support multiple app IDs.
  2. Update the class-level Javadoc or relevant documentation to explain how to use the new multipleConfigs attribute effectively.

Here's a script to check for any existing documentation that might need updating:

This will help identify files that might need to be updated to reflect the new functionality.

✅ Verification successful

Impact on Monitoring Metrics Verified and Documentation Updated

After reviewing the codebase, the addition of multipleConfigs does not impact the monitoring metrics system. The usage of multipleConfigs is confined to configuration setup and testing, with no direct interaction with the metrics components.

To ensure clarity, please update the class-level Javadoc or relevant documentation to include information about the new multipleConfigs attribute, detailing its purpose and usage.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for documentation files that might need updating
echo "Searching for documentation files..."
fd -e md -e txt | xargs rg -i "apollo.*config"

echo "Searching for other occurrences of EnableApolloConfig..."
rg "EnableApolloConfig"

Length of output: 15852

Script:

#!/bin/bash
# Search for monitoring and metrics related references in the codebase
echo "Searching for monitoring and metrics related references..."
rg -i "monitoring" .
rg -i "metric" .
rg -i "MultipleConfig" .
rg -i "multipleConfigs" .

Length of output: 4730

apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChange.java (4)

27-27: LGTM: Addition of appId field

The addition of the appId field is consistent with the PR objectives to support multiple app IDs. The field is correctly declared as final, which is good for immutability.

36-42: LGTM: Updated constructor documentation

The constructor documentation has been appropriately updated to include a description for the new appId parameter. The description is clear and concise.

43-45: LGTM: Updated constructor signature and implementation

The constructor has been correctly updated to include the appId parameter, and the appId field is properly initialized. The placement of appId as the first parameter follows common conventions.

80-82: LGTM: Addition of getAppId() method

The getAppId() method has been correctly implemented, providing proper encapsulation for the appId field. This addition addresses the previous concern about the lack of a getter for this field.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/PropertiesConfigFile.java (1)

39-41: LGTM: Constructor updated to support multiple app IDs.

The addition of the appId parameter to the constructor signature and its usage in the superclass constructor call are correct and align with the PR objective of supporting multiple app IDs.

To ensure this change doesn't break existing code, let's verify all instantiations of PropertiesConfigFile:

✅ Verification successful

Verified: All instantiations of PropertiesConfigFile include the new appId parameter.

All instances where PropertiesConfigFile is instantiated have been correctly updated to include the appId parameter, ensuring consistency and preventing potential issues.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all instantiations of PropertiesConfigFile to ensure they're updated with the new appId parameter.

# Test: Search for PropertiesConfigFile instantiations
rg --type java -A 5 'new PropertiesConfigFile\('

Length of output: 6895

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (1)

39-40: LGTM! Verify usage across the codebase.

The constructor change looks good and aligns with the PR objective of adding support for multiple app IDs. The appId parameter is correctly passed to the superclass constructor.

To ensure all YamlConfigFile instantiations have been updated, please run the following script:

This will help identify any locations where YamlConfigFile is instantiated and ensure they've been updated to include the appId parameter.

✅ Verification successful

Verified: All instances of YamlConfigFile have been correctly updated to include the appId parameter.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all instantiations of YamlConfigFile have been updated with the new appId parameter.

# Test: Search for YamlConfigFile instantiations. Expect: Only occurrences with three parameters (appId, namespace, configRepository).
rg --type java -A 5 'new YamlConfigFile\('

Length of output: 7133

apollo-client-config-data/src/main/java/com/ctrip/framework/apollo/config/data/internals/PureApolloConfig.java (1)

42-52: LGTM! New constructor added as requested.

The new constructor with appId parameter has been implemented correctly. It aligns with the PR objective of adding support for multiple app IDs. The original constructor has been retained, maintaining backward compatibility as suggested in the previous review.

The Javadoc for the new constructor is clear and informative.

apollo-mockserver/src/test/java/com/ctrip/framework/apollo/mockserver/ApolloMockServerApiWhileCacheDirSpecifiedTest.java (1)

60-60: LGTM! Consider verifying test completeness.

The update to the LocalFileConfigRepository constructor aligns with the PR objective of adding support for multiple app IDs. The change is correct and consistent with the test setup.

To ensure the test remains comprehensive after this change, please verify:

  1. If any additional assertions are needed to test the multi-app ID functionality.
  2. If this change affects any other parts of the test that might need adjustment.

You can use the following script to check for other usages of LocalFileConfigRepository in test files:

This will help identify if similar changes are needed in other test files.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryFileCachePropertyTest.java (3)

41-41: LGTM: Addition of someAppId variable

The introduction of the someAppId variable aligns with the PR objective of supporting multiple app IDs. It's appropriately placed alongside other test-related variables.

46-46: LGTM: Initialization of someAppId

The initialization of someAppId in the setUp method is consistent with the test setup pattern and uses a reasonable placeholder value for testing purposes.

Line range hint 1-82: Overall assessment: Changes successfully implement multiple app ID support

The modifications to this test class successfully implement support for multiple app IDs, aligning with the PR objectives. The changes are consistent throughout the file, maintaining the original test structure and logic while improving test coverage by including the new appId parameter.

Key points:

  1. A new someAppId variable is introduced and properly initialized.
  2. All relevant method calls and verifications are updated to include the appId parameter.
  3. The changes ensure that the DefaultConfigFactory is tested with both appId and namespace parameters.

These updates enhance the test suite's ability to verify the correct behavior of the DefaultConfigFactory class with the new multiple app ID support feature.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/InterestedConfigChangeEventTest.java (2)

74-76: LGTM! Correct implementation of app ID support.

The addition of someAppId as the first parameter in the ConfigChange constructor calls correctly implements the support for multiple app IDs. This change aligns with the PR objective and maintains the original test logic.

77-77: LGTM! Correct propagation of app ID to fireConfigChange method.

The addition of someAppId as the first parameter in the fireConfigChange method call correctly implements the support for multiple app IDs and ensures proper propagation of the app ID through the configuration change event.

To ensure complete implementation, let's verify the fireConfigChange method signature in the AbstractConfig class:

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesCompatibleFileConfigRepositoryTest.java (4)

43-43: LGTM: Addition of someAppId variable

The introduction of the someAppId variable aligns with the PR objective of adding support for multiple app IDs. The variable is correctly declared as private, adhering to good encapsulation practices.

51-53: LGTM: Updates to setUp method

The changes in the setUp method appropriately initialize the someAppId variable and mock the getAppId() method of the configFile object. These modifications support the new multi-app ID functionality being tested and ensure that the test has control over the app ID value used in the test scenarios.

135-135: LGTM: Update to testOnChange method

The modification to the onRepositoryChange method verification in the testOnChange method is appropriate. By including someAppId as the first parameter, the test now correctly verifies that the repository change notification includes the app ID. This change ensures that the new multi-app ID functionality is properly tested and that the onRepositoryChange method is called with all necessary parameters.

Line range hint 1-137: Overall assessment: Changes are well-implemented and align with PR objectives

The modifications to PropertiesCompatibleFileConfigRepositoryTest.java consistently support the addition of multi-app ID functionality. The changes are well-structured, maintain good testing practices, and effectively cover the new functionality. No issues or potential improvements were identified during this review.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java (8)

42-42: LGTM: Addition of someAppId field

The addition of the someAppId field is consistent with the PR objective of adding support for multiple app IDs. This change lays the groundwork for the subsequent modifications in the test methods.

51-51: LGTM: Initialization of someAppId in setUp

The initialization of someAppId in the setUp method is appropriate. This ensures that each test method has access to a valid appId value, maintaining consistency across all tests.

67-67: LGTM: Updated JsonConfigFile constructor call in testWhenHasContent

The JsonConfigFile constructor call has been correctly updated to include someAppId. This change aligns with the new constructor signature while preserving the original test logic.

80-80: LGTM: Updated JsonConfigFile constructor call in testWhenHasNoContent

The JsonConfigFile constructor call has been appropriately updated to include someAppId. This change maintains consistency with the new constructor signature while preserving the original test's purpose.

90-90: LGTM: Updated JsonConfigFile constructor call in testWhenConfigRepositoryHasError

The JsonConfigFile constructor call has been correctly updated to include someAppId. This change aligns with the new constructor signature while maintaining the original test logic and assertions.

110-110: LGTM: Updated method calls in testOnRepositoryChange

Both the JsonConfigFile constructor call and the onRepositoryChange method call have been correctly updated to include someAppId. These changes align with the new method signatures while preserving the original test logic and assertions.

Also applies to: 121-121

139-139: LGTM: Updated method calls in testWhenConfigRepositoryHasErrorAndThenRecovered

The JsonConfigFile constructor call and the onRepositoryChange method call have been appropriately updated to include someAppId. These changes maintain consistency with the new method signatures while preserving the original test logic, structure, and assertions.

Also applies to: 145-145

Line range hint 1-151: Overall assessment: Changes are consistent and well-implemented

The modifications to JsonConfigFileTest.java consistently incorporate the new appId parameter across all relevant method calls and constructor invocations. These changes align well with the PR objective of adding support for multiple app IDs. The integrity of the existing tests has been maintained, with only the necessary adjustments made to accommodate the new parameter.

A few points to consider:

  1. The changes are uniform across all test methods, which is good for consistency.
  2. The original test logic and assertions remain intact, ensuring that the existing functionality is still being tested.
  3. The someAppId value is appropriately initialized in the setUp method, making it available for all tests.

To ensure that all necessary changes have been made, please run the following verification script:

This script will help ensure that all necessary updates have been made and that someAppId is used consistently throughout the file.

✅ Verification successful

Verification Successful: All constructor and method calls correctly include someAppId

The shell script outputs confirm that all instances of JsonConfigFile constructor and onRepositoryChange method calls have been updated to include the new someAppId parameter. The usage of someAppId is consistent throughout the JsonConfigFileTest.java file, ensuring that the changes align with the PR objective and maintain the integrity of the existing tests.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all JsonConfigFile constructor calls and onRepositoryChange method calls include the new appId parameter

# Test: Search for JsonConfigFile constructor calls
echo "Checking JsonConfigFile constructor calls:"
rg --type java 'new JsonConfigFile\(' apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java

# Test: Search for onRepositoryChange method calls
echo "Checking onRepositoryChange method calls:"
rg --type java '\.onRepositoryChange\(' apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java

# Test: Verify that someAppId is used consistently
echo "Checking someAppId usage:"
rg --type java 'someAppId' apollo-client/src/test/java/com/ctrip/framework/apollo/internals/JsonConfigFileTest.java

Length of output: 1955

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/SimpleConfigTest.java (5)

52-52: LGTM: Addition of someAppId variable

The addition of the someAppId variable is consistent with the PR objective of adding support for multiple app IDs. It's appropriately placed with other test-related variables.

62-62: LGTM: Initialization of someAppId in setUp method

The initialization of someAppId with the value "someAppId" is consistent with the test setup pattern and provides a reasonable placeholder for testing purposes.

91-91: LGTM: Updated SimpleConfig constructor call in testGetProperty

The SimpleConfig constructor call has been correctly updated to include someAppId, reflecting the new constructor signature and aligning with the PR objective of incorporating app ID in the configuration.

104-104: LGTM: Updated SimpleConfig constructor call in testLoadConfigFromConfigRepositoryError

The SimpleConfig constructor call has been correctly updated to include someAppId, maintaining consistency with the changes in other test methods and ensuring that the error handling test case uses the new constructor signature.

Line range hint 1-172: Overall assessment: Changes are well-implemented and consistent

The modifications to SimpleConfigTest.java effectively incorporate the new someAppId parameter across various test methods. These changes align well with the PR objective of adding support for multiple app IDs. The updates include:

  1. Addition of a someAppId variable
  2. Initialization of someAppId in the setUp method
  3. Updates to SimpleConfig constructor calls in multiple test methods
  4. Modification of the onRepositoryChange method call to include someAppId
  5. Addition of an assertion to verify the appId in the changeEvent

All changes are consistent and contribute to comprehensive testing of the new app ID functionality. A minor suggestion was made to improve code maintainability by using a constant for the "someAppId" string.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java (3)

47-48: LGTM: Addition of someAppId variable

The introduction of the someAppId static variable is a good practice. It centralizes the app ID value used in tests, improving maintainability and reducing the risk of inconsistencies across test cases.

68-69: LGTM with a question: Use of someAppId and new method call

The changes consistently use the new someAppId variable, which is good for maintainability. However, I have a question about the additional fireConfigChange method call on line 72:

  1. Is this new method call intended to test a new or modified fireConfigChange method signature?
  2. If so, should we add assertions to verify the behavior of this new method call?

Also applies to: 72-72

111-112: LGTM: Consistent use of someAppId

The changes in this test method consistently use the new someAppId variable, which improves maintainability and aligns with the PR objective of supporting multiple app IDs.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (4)

53-54: LGTM: Addition of someAppId constant

The addition of the someAppId constant is a good practice. It centralizes the definition of the app ID used in tests, making it easier to maintain and update if needed.

113-116: LGTM: Updated testApplicationEvent to use app ID in configuration mocking

The changes in the testApplicationEvent method correctly incorporate the someAppId into the configuration mocking process. This ensures consistency with the other tests and accurately reflects the new multi-app ID support.

161-161: LGTM: Improved assertion in testOverrideSystemProperties

The order of arguments in the assertEquals call has been reversed. This is a good practice in JUnit tests as it puts the expected value first, which leads to more meaningful error messages if the test fails.

Line range hint 1-162: Overall assessment: Changes successfully implement multi-app ID support in tests

The modifications to PropertySourcesProcessorTest.java consistently integrate the new someAppId variable throughout the test methods. These changes align well with the PR objective of adding support for multiple app IDs and ensure that the new functionality is properly tested.

Key points:

  1. The addition of the someAppId constant improves maintainability.
  2. Setting the APP_ID system property in setUp ensures consistency across tests.
  3. Test methods have been updated to incorporate the app ID in configurations and assertions.
  4. The changes maintain good coding practices and improve test reliability.

Minor suggestions for improvement have been made, but overall, the changes are well-implemented and ready for merging.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java (9)

51-51: LGTM: Addition of someAppId variable.

The addition of the someAppId variable is consistent with the changes described in the summary and follows good practices for test class organization.

60-60: LGTM: Initialization of someAppId in setUp method.

Initializing someAppId in the setUp method ensures a clean state before each test, which is a good practice in unit testing.

85-85: LGTM: Updated PropertiesConfigFile constructor call.

The constructor call has been correctly updated to include the new someAppId parameter, maintaining consistency with the changes to the PropertiesConfigFile class.

97-97: LGTM: Updated PropertiesConfigFile constructor call in testWhenHasNoContent.

The constructor call has been correctly updated to include the new someAppId parameter, maintaining consistency across test methods.

107-107: LGTM: Updated PropertiesConfigFile constructor call in testWhenConfigRepositoryHasError.

The constructor call has been correctly updated to include the new someAppId parameter, maintaining consistency across different test scenarios.

123-123: LGTM: Updated PropertiesConfigFile constructor call in testOnRepositoryChange.

The constructor call has been correctly updated to include the new someAppId parameter, ensuring consistency in testing the repository change scenario.

162-162: LGTM: Updated PropertiesConfigFile constructor call in testWhenConfigRepositoryHasErrorAndThenRecovered.

The constructor call has been correctly updated to include the new someAppId parameter, maintaining consistency in the error recovery test scenario.

182-182: LGTM: Updated PropertiesConfigFile constructor calls in compatibility tests.

The constructor calls in both testIfCompatibleWithProperties and testIfCompatibleWithEmptyProperties methods have been correctly updated to include the new someAppId parameter, ensuring consistency across all test scenarios.

Also applies to: 197-197

51-51: Summary: Consistent implementation of someAppId parameter across all test methods.

The changes in this file consistently add the someAppId parameter to all PropertiesConfigFile constructor calls, aligning with the updated constructor signature. The new parameter is properly initialized in the setUp method, ensuring a clean state for each test. These changes improve the test coverage by including the new appId functionality in all relevant test scenarios.

To ensure that all PropertiesConfigFile constructor calls have been updated, run the following script:

Also applies to: 60-60, 85-85, 97-97, 107-107, 123-123, 162-162, 182-182, 197-197

✅ Verification successful

Verification Successful: All PropertiesConfigFile constructor calls include the someAppId parameter.

The executed shell script found 7 instances of PropertiesConfigFile being instantiated with the someAppId, someNamespace, and configRepository parameters. This confirms that the changes have been consistently applied across the reviewed test methods. No instances of missing someAppId were detected.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all PropertiesConfigFile constructor calls include someAppId

# Test: Search for PropertiesConfigFile constructor calls
# Expect: All calls should have three parameters (someAppId, someNamespace, configRepository)
rg --type java 'new PropertiesConfigFile\(' apollo-client/src/test/java/com/ctrip/framework/apollo/internals/PropertiesConfigFileTest.java

Length of output: 896

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderTest.java (7)

39-39: LGTM: Addition of someAppId constant

The addition of the someAppId constant is appropriate and aligns with the PR objective of supporting multiple app IDs. This constant will be used consistently across the test methods, improving code readability and maintainability.

66-66: LGTM: Updated mockConfig call in testPropertySourceWithNoNamespace

The mockConfig call has been correctly updated to include the someAppId parameter. This change is consistent with the PR objective of supporting multiple app IDs and maintains the correct order of parameters.

74-74: LGTM: Updated mockConfig call in testPropertySourceWithNoConfig

The mockConfig call has been correctly updated to include the someAppId parameter. This change is consistent with the PR objective of supporting multiple app IDs and maintains the correct order of parameters.

88-88: LGTM: Updated mockConfig call in testApplicationPropertySource

The mockConfig call has been correctly updated to include the someAppId parameter. This change is consistent with the PR objective of supporting multiple app IDs and maintains the correct order of parameters.

101-101: LGTM: Updated mockConfig calls in testMultiplePropertySources

Both mockConfig calls have been correctly updated to include the someAppId parameter. These changes are consistent with the PR objective of supporting multiple app IDs and maintain the correct order of parameters. The use of the same someAppId for different namespaces is appropriate in this test context.

Also applies to: 106-106

117-117: LGTM: Updated mockConfig calls in prepare method

Both mockConfig calls in the prepare method have been correctly updated to include the someAppId parameter. These changes are consistent with the PR objective of supporting multiple app IDs and maintain the correct order of parameters. The use of the same someAppId for different namespaces is appropriate in this test context.

Also applies to: 122-122

Line range hint 1-238: Overall assessment: Changes are well-implemented and consistent

The modifications in this file consistently implement the new someAppId parameter in all relevant mockConfig calls. These changes align well with the PR objective of supporting multiple app IDs. The test coverage appears to be maintained, and the implementation is consistent across all modified methods.

However, to ensure comprehensive testing, consider the following suggestions:

  1. Add a new test case that explicitly verifies the behavior with multiple different app IDs.
  2. Update the test method names to reflect that they now test with a specific app ID.

To verify the completeness of the changes, please run the following script:

✅ Verification successful

Verification Successful: All mockConfig calls include the someAppId parameter

The executed scripts confirm that every mockConfig call in XmlConfigPlaceholderTest.java includes the someAppId parameter. No instances of mockConfig without someAppId were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all mockConfig calls in the file include the someAppId parameter

# Test: Search for mockConfig calls without someAppId. Expect: No results.
rg 'mockConfig\([^,]+,' apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderTest.java

# Test: Search for mockConfig calls with someAppId. Expect: All mockConfig calls in the file.
rg 'mockConfig\(someAppId,' apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderTest.java

Length of output: 1201

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepositoryTest.java (1)

150-151: LGTM! Constructor update is correct.

The change correctly updates the LocalFileConfigRepository constructor to include the someAppId parameter. This aligns with the new signature mentioned in the summary, and the test logic remains appropriately unchanged.

apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2)

226-226: LGTM: Correctly updated to use new method signature

The change correctly updates the getDefaultLocalCacheDir method call to include the someAppId parameter, which is consistent with the updated method signature. This ensures that the test accurately reflects the new behavior of appending the app ID to the cache directory path.

239-243: LGTM: Correctly updated to use new method signature, but consider addressing hardcoded paths

The changes correctly update the getDefaultLocalCacheDir method calls to include the someAppId parameter, which is consistent with the updated method signature. This ensures that the test accurately reflects the new behavior of appending the app ID to the cache directory path for both Windows and non-Windows systems.

However, as noted in a previous review comment, the use of hardcoded paths (C:\\opt\\data\\ for Windows and /opt/data/ for non-Windows) in these tests may lead to brittleness. Consider using a configuration setting or environment variable to define base paths, making the tests more adaptable to different environments.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/XmlConfigFileTest.java (7)

52-52: LGTM: Addition of someAppId variable

The addition of the someAppId variable is consistent with the changes in the XmlConfigFile constructor calls and aligns with the existing code structure.

61-61: LGTM: Initialization of someAppId in setUp method

The initialization of someAppId follows the existing pattern for test setup in this class and uses an appropriate placeholder value for testing.

88-88: LGTM: Updated XmlConfigFile constructor call in testWhenHasContent

The XmlConfigFile constructor call has been correctly updated to include the someAppId parameter, maintaining consistency with the new constructor signature while preserving the original test logic.

100-100: LGTM: Updated XmlConfigFile constructor call in testWhenHasNoContent

The XmlConfigFile constructor call has been correctly updated to include the someAppId parameter, maintaining consistency with the new constructor signature while preserving the original test logic for the no-content scenario.

110-110: LGTM: Updated XmlConfigFile constructor call in testWhenConfigRepositoryHasError

The XmlConfigFile constructor call has been correctly updated to include the someAppId parameter, maintaining consistency with the new constructor signature while preserving the original test logic for the error scenario.

235-235: LGTM: Updated XmlConfigFile usage in testWhenConfigRepositoryHasErrorAndThenRecovered

The XmlConfigFile constructor and onRepositoryChange method calls have been correctly updated to include the someAppId parameter, maintaining consistency with the new signatures while preserving the original test logic for the error recovery scenario.

Also applies to: 240-240

126-126: LGTM: Updated XmlConfigFile usage in testOnRepositoryChange

The XmlConfigFile constructor and onRepositoryChange method calls have been correctly updated to include the someAppId parameter, maintaining consistency with the new signatures while preserving the original test logic for the repository change scenario.

Please verify that the onRepositoryChange method signature in the XmlConfigFile class has been updated to include the appId parameter. Run the following script to check:

Also applies to: 143-143

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/YamlConfigFileTest.java (8)

42-42: LGTM: Addition of someAppId field

The addition of the someAppId field is consistent with the changes in the YamlConfigFile constructor. This is a good practice for declaring test variables that will be reused across multiple test methods.

55-55: LGTM: Initialization of someAppId in setUp method

The initialization of someAppId in the setUp method is consistent with the new field addition. This is a good practice for setting up test variables that will be used across multiple test methods.

89-89: LGTM: Updated YamlConfigFile constructor call in testWhenHasContent

The YamlConfigFile constructor call has been correctly updated to include the new someAppId parameter. This change is consistent with the updated constructor signature, and the test logic remains intact.

115-115: LGTM: Updated YamlConfigFile constructor call in testWhenHasContentWithOrder

The YamlConfigFile constructor call has been correctly updated to include the new someAppId parameter. This change is consistent with the updated constructor signature, and the test logic for checking the order of properties remains intact.

129-129: LGTM: Updated YamlConfigFile constructor call in testWhenHasNoContent

The YamlConfigFile constructor call has been correctly updated to include the new someAppId parameter. This change is consistent with the updated constructor signature, and the test logic for checking the behavior when there's no content remains intact.

152-152: LGTM: Updated YamlConfigFile constructor call in testWhenInvalidYamlContent

The YamlConfigFile constructor call has been correctly updated to include the new someAppId parameter. This change is consistent with the updated constructor signature, and the test logic for handling invalid YAML content remains intact.

171-171: LGTM: Updated YamlConfigFile constructor and onRepositoryChange calls

The YamlConfigFile constructor calls have been correctly updated to include the new someAppId parameter in the testWhenConfigRepositoryHasError, testOnRepositoryChange, and testWhenConfigRepositoryHasErrorAndThenRecovered methods. Additionally, the onRepositoryChange method call has been updated to include someAppId. These changes are consistent with the updates in the YamlConfigFile class, and the test logic remains intact in all cases.

Also applies to: 203-203, 215-215, 238-238, 245-245

Line range hint 1-252: Overall assessment: Changes are consistent and well-implemented

The modifications to YamlConfigFileTest consistently update all YamlConfigFile constructor calls to include the new someAppId parameter. The onRepositoryChange method call has also been correctly updated. These changes align with the new appId parameter implementation in the YamlConfigFile class.

The test logic remains intact across all methods, ensuring that the existing functionality is still properly tested while accommodating the new appId parameter. This update maintains the integrity of the test suite and provides coverage for the new feature.

No issues or potential problems were identified during this review. The changes appear to be well-implemented and ready for integration.

apollo-mockserver/src/main/java/com/ctrip/framework/apollo/mockserver/ApolloTestingServer.java (1)

55-55: ⚠️ Potential issue

Consider making someAppId configurable

The someAppId variable is currently hardcoded with a static value. For better flexibility and to accommodate different testing scenarios, consider making this value configurable. This could be achieved through environment variables, system properties, or a configuration file.

Example implementation:

private static String someAppId = System.getProperty("apollo.mock.appId", "someAppId");

This approach allows setting a custom appId via system property while maintaining a default value.

apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java (3)

20-20: LGTM: Import statement for ApolloClientSystemConsts added.

The addition of this import is consistent with the PR objective of adding support for multiple app IDs. It allows the use of system constants related to the Apollo client in this test class.

145-145: LGTM: App ID system property cleared in tearDown method.

This addition ensures proper cleanup after each test by clearing the APP_ID system property. It prevents potential side effects between tests and is consistent with the addition in the setUp method.

121-121: LGTM: App ID system property set in setUp method.

This addition ensures that the app ID is correctly set for the integration tests, which is in line with the PR objective of supporting multiple app IDs.

To ensure proper cleanup, let's verify that this property is cleared in the tearDown method:

✅ Verification successful

Verified: APP_ID system property is cleared in the tearDown method.

The tearDown method correctly clears the APP_ID system property, ensuring no side effects for other tests.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify APP_ID system property is cleared in tearDown method
rg --type java "System\.clearProperty\(ApolloClientSystemConsts\.APP_ID\)" apollo-client/src/test/java/com/ctrip/framework/apollo/BaseIntegrationTest.java

Length of output: 215

apollo-core/src/main/java/com/ctrip/framework/foundation/internals/provider/DefaultApplicationProvider.java (1)

120-126: Approve implementation with suggestions for improvement

The new getAccessKeySecret(String appId) method successfully implements support for multiple app IDs, aligning with the PR objectives. However, there are a few areas for improvement:

  1. Consider adding error handling or logging when the property is not found. Returning an empty string silently could lead to difficult-to-debug issues.

  2. It's advisable to validate the input appId to prevent potential security issues.

  3. Other parts of the system that deal with access key secrets might need to be updated to utilize this new method.

Here's a suggested implementation addressing these points:

@Override
public String getAccessKeySecret(String appId) {
    if (appId == null || appId.trim().isEmpty()) {
        throw new IllegalArgumentException("appId must not be null or empty");
    }
    
    if (Objects.equals(appId, m_appId)) {
        return getAccessKeySecret();
    }
    
    String key = "apollo.accesskey." + appId + ".secret";
    String secret = System.getProperty(key);
    
    if (secret == null || secret.isEmpty()) {
        logger.warn("Access key secret not found for appId: {}", appId);
    }
    
    return secret != null ? secret : "";
}

This implementation includes input validation, logging, and maintains the current behavior of returning an empty string if the property is not found.

To ensure this change doesn't break existing functionality and is properly utilized, you may want to run the following verification:

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XMLConfigAnnotationTest.java (8)

53-54: LGTM: Addition of someAppId constant

The addition of the someAppId constant is in line with the PR objective of supporting multiple app IDs. The constant is correctly defined as private and final, following good Java practices.

60-61: LGTM: Updated mockConfig calls in testApolloConfig

The mockConfig calls have been correctly updated to include the someAppId parameter. This change aligns with the PR objective of supporting multiple app IDs and ensures that the test cases now consider the app ID when mocking configurations.

74-74: LGTM: Updated mockConfig call in testApolloConfigWithWrongFieldType

The mockConfig call has been correctly updated to include the someAppId parameter, maintaining consistency with the PR objective and previous changes.

84-85: LGTM: Updated mockConfig calls in testApolloConfigChangeListener

The mockConfig calls have been correctly updated to include the someAppId parameter. These changes maintain consistency with the PR objective and previous modifications while preserving the original test logic.

139-139: LGTM: Updated mockConfig call in testApolloConfigChangeListenerWithWrongParamType

The mockConfig call has been correctly updated to include the someAppId parameter, maintaining consistency with the PR objective and previous changes. The test's purpose and expected behavior remain intact.

148-148: LGTM: Updated mockConfig call in testApolloConfigChangeListenerWithWrongParamCount

The mockConfig call has been correctly updated to include the someAppId parameter, maintaining consistency with the PR objective and previous changes. The test's purpose and expected behavior remain intact.

158-159: LGTM: Updated mockConfig calls in testApolloConfigChangeListenerWithInterestedKeys

The mockConfig calls have been correctly updated to include the someAppId parameter. These changes maintain consistency with the PR objective and previous modifications while preserving the original test logic and assertions.

Line range hint 1-300: Summary: Successful implementation of multiple app ID support in XMLConfigAnnotationTest

The changes in this file consistently implement support for multiple app IDs across all relevant test methods. The modifications are minimal and focused, aligning well with the PR objective. The addition of the someAppId constant and its usage in all mockConfig calls ensures that the tests now consider app-specific configurations.

These changes enhance the test coverage for the new multiple app ID feature without altering the existing test logic or expected outcomes. This approach minimizes the risk of introducing unintended side effects while ensuring that the new functionality is properly tested.

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java (3)

62-64: LGTM: Initialization of someAppId

The addition of someAppId initialization is consistent with the PR objective of adding support for multiple app IDs. This change provides a test value for the new app ID parameter used throughout the test class.

216-216: LGTM: Update to checkNamespaceName method

The change correctly reflects the updated method signature of trimNamespaceFormat to include the someAppId parameter. This is consistent with the PR objective of supporting multiple app IDs.

191-204: Clarification needed: Purpose of appIdAndNamespace wrapper

The appIdAndNamespace wrapper has been introduced in the checkNamespaceName method calls. However, the current implementation of appIdAndNamespace simply returns the namespace unchanged.

Could you please clarify the purpose of this wrapper? Is it a placeholder for future functionality related to app ID and namespace combination? If so, consider adding a TODO comment to explain the intended future use.

✅ Verification successful

Verification Successful: appIdAndNamespace Usage Confirmed

The appIdAndNamespace method is defined and used solely within DefaultConfigFactoryTest.java as observed. There are no TODO comments or indications of it being a placeholder for future functionality.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if there are any TODO comments related to appIdAndNamespace
grep -n "TODO.*appIdAndNamespace" apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryTest.java

Length of output: 124

Script:

#!/bin/bash
# Find the implementation of appIdAndNamespace
rg 'appIdAndNamespace\s*\(' .

Length of output: 2534

Script:

#!/bin/bash
# List all usages of appIdAndNamespace
rg 'appIdAndNamespace' .

Length of output: 2527

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/BootstrapConfigTest.java (11)

60-61: LGTM: Addition of someAppId constant

The addition of the someAppId constant is appropriate for testing purposes. It's correctly defined as private and static, which aligns with best practices for test constants.

140-141: LGTM: Consistent use of someAppId in mockConfig calls

The modifications to include someAppId in both mockConfig calls are consistent with the earlier changes. This approach correctly uses the same app ID for different namespaces, which aligns with the expected behavior in a multi-namespace configuration scenario.

179-180: LGTM: Consistent use of someAppId in mockConfig calls

The modifications to include someAppId in both mockConfig calls are consistent with the earlier changes. This approach correctly uses the same app ID for different namespaces, maintaining consistency with the pattern observed in other test classes.

218-218: LGTM: Updated mockConfig call with someAppId

The modification to include someAppId in the mockConfig call is consistent with the earlier changes. This update maintains consistency across different test scenarios, ensuring that the app ID is properly used in all relevant test cases.

250-250: LGTM: Consistent use of someAppId in prepareYamlConfigFile call

The modification to include someAppId in the prepareYamlConfigFile call is consistent with the earlier changes. This update maintains consistency across different test scenarios that use YAML configuration files, ensuring that the app ID is properly used in all relevant test cases.

284-284: LGTM: Updated mockConfig call with someAppId

The modification to include someAppId in the mockConfig call is consistent with the earlier changes. This update maintains consistency across different test scenarios, including cases where conditional properties are turned off, ensuring that the app ID is properly used in all relevant test cases.

317-317: LGTM: Consistent use of someAppId in prepareYamlConfigFile call

The modification to include someAppId in the prepareYamlConfigFile call is consistent with the earlier changes. This update maintains consistency across different test scenarios that use YAML configuration files, including cases where conditional properties are turned off, ensuring that the app ID is properly used in all relevant test cases.

353-353: LGTM: Updated mockConfig call with someAppId

The modification to include someAppId in the mockConfig call is consistent with the earlier changes. This update maintains consistency across different test scenarios, including cases where bootstrap is disabled, ensuring that the app ID is properly used in all relevant test cases.

176-176: LGTM: Updated prepareYamlConfigFile call with someAppId

The modification to include someAppId in the prepareYamlConfigFile call is consistent with the earlier changes. This update suggests that the prepareYamlConfigFile method signature has been modified to include an app ID parameter.

To ensure consistency across the codebase, let's verify the prepareYamlConfigFile method signature:

#!/bin/bash
# Search for the prepareYamlConfigFile method definition
rg --type java "static void prepareYamlConfigFile\(" apollo-client/src/test/java/

406-406: LGTM with suggestions: Updated mockConfig call and method signatures

The modifications in this test class are consistent with earlier changes:

  1. The mockConfig call now includes someAppId, maintaining consistency with other test classes.
  2. The beforeClass and afterClass method signatures have been updated to include exception clauses.

These changes suggest that the methods may now throw exceptions due to modifications in their implementation or the methods they call.

To ensure these changes are justified, let's verify the implementations of beforeClass and afterClass:

Please review the results to confirm that the exception handling is necessary and appropriate.

Also applies to: 414-414, 418-418

96-96: LGTM: Updated mockConfig call with someAppId

The modification to include someAppId in the mockConfig call is consistent with the earlier addition of the constant. This change suggests an update to the mockConfig method signature to include an app ID parameter.

To ensure consistency across the codebase, let's verify the mockConfig method signature:

✅ Verification successful

Verified: mockConfig method signature includes someAppId

All usages of the mockConfig method correctly include the someAppId parameter, and the method signature has been appropriately updated.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for the mockConfig method definition
rg --type java "static void mockConfig\(" apollo-client/src/test/java/

Length of output: 83

Script:

#!/bin/bash
# Search for all definitions of the mockConfig method across the entire codebase
rg --type java "\\bmockConfig\\s*\\(" .

Length of output: 16559

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java (4)

131-131: LGTM: Initialization of someAppId.

The addition of someAppId initialization in the setUp method is consistent with the changes to support multiple app IDs. This change looks good and necessary for the updated test scenarios.

268-268: LGTM: Updated verify method call for RepositoryChangeListener.

The verify method call for the RepositoryChangeListener has been correctly updated to include someAppId. This change ensures that the correct app ID is being verified in the test, which is consistent with the updates to support multiple app IDs.

Also applies to: 317-317

Line range hint 1-468: Overall assessment: Well-implemented changes for multi-app ID support.

The changes made to RemoteConfigRepositoryTest.java consistently implement support for multiple app IDs across various test methods and utility classes. The modifications are necessary and align well with the goal of enhancing the configuration capabilities to handle multiple app IDs.

Key points:

  1. RemoteConfigRepository constructor calls have been updated consistently.
  2. Verification methods have been adjusted to include app ID checks.
  3. A new method for app-specific access key secrets has been added.

The suggested improvements, if implemented, would further enhance the code quality and test robustness. Great job on maintaining consistency throughout the changes!

42-42: 💡 Codebase verification

Unnecessary import detected.

The PropertySourcesProcessor import is present but not used in the RemoteConfigRepositoryTest.java file. Please remove this unused import to clean up the codebase.

🔗 Analysis chain

Verify the necessity of the new import.

The PropertySourcesProcessor import has been added, but it doesn't appear to be used in the visible code. Please ensure this import is necessary for the test class, or remove it if unused.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for usage of PropertySourcesProcessor in the test file
rg --type java "PropertySourcesProcessor" apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigRepositoryTest.java

Length of output: 212

⛔ Skipped due to learnings 
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java:64-64
Timestamp: 2024-10-01T03:05:09.661Z
Learning: In the `PropertySourcesProcessor` class, the `APP_NAMESPACE_NAMES` map and its inner `Multimap` instances do not need to be thread-safe because concurrent access is not expected.

Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java:64-64
Timestamp: 2024-10-08T15:31:24.844Z
Learning: In the `PropertySourcesProcessor` class, the `APP_NAMESPACE_NAMES` map and its inner `Multimap` instances do not need to be thread-safe because concurrent access is not expected.
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/XmlConfigPlaceholderAutoUpdateTest.java (7)

44-45: LGTM: Addition of someAppId constant

The introduction of the someAppId constant aligns with the PR objective of adding support for multiple app IDs. Using a constant instead of hardcoding the value improves code maintainability.

56-56: LGTM: Consistent use of someAppId in testAutoUpdateWithOneNamespace

The changes in this method consistently apply the new someAppId parameter to both prepareConfig and onRepositoryChange method calls. This modification aligns with the PR objective of supporting multiple app IDs.

Also applies to: 68-68

91-91: LGTM: Consistent use of someAppId in testAutoUpdateDisabled

The changes in this method consistently apply the new someAppId parameter to both prepareConfig and onRepositoryChange method calls. This modification aligns with the PR objective of supporting multiple app IDs.

Also applies to: 103-103

123-125: LGTM: Consistent use of someAppId in testAutoUpdateWithMultipleNamespaces

The changes in this method consistently apply the new someAppId parameter to prepareConfig method calls for both application and FX Apollo configs. This modification aligns with the PR objective of supporting multiple app IDs across multiple namespaces.

168-169: LGTM: Consistent use of someAppId in testAutoUpdateWithMultipleNamespacesWithSameProperties

The changes in this method consistently apply the new someAppId parameter to prepareConfig method calls for both application and FX Apollo configs, as well as the onRepositoryChange method call. This modification aligns with the PR objective of supporting multiple app IDs across multiple namespaces and repository change events.

Also applies to: 181-181

198-198: LGTM: Consistent use of someAppId across all test methods

The changes consistently apply the new someAppId parameter to all prepareConfig and onRepositoryChange method calls across the remaining test methods. This modification aligns with the PR objective of supporting multiple app IDs and ensures consistency throughout the test suite.

Also applies to: 212-212, 233-233, 247-247, 263-263, 274-274, 293-295, 323-323, 334-334, 352-352, 364-364, 382-382, 394-394, 413-413, 425-425, 472-472, 501-501

Line range hint 1-624: Summary: Successful implementation of multiple app ID support in test suite

The changes in this file consistently implement support for multiple app IDs across all test methods. The introduction of the someAppId constant and its usage in prepareConfig and onRepositoryChange method calls align with the PR objective. These modifications enhance the test suite's capability to verify the multi-app ID feature without altering the existing test logic or structure.

Some observations:

  1. The changes are consistent across all test methods.
  2. The existing test logic remains intact, ensuring that previous functionality is still covered.
  3. The modifications provide a foundation for potential future tests specific to multi-app ID scenarios.

Overall, these changes effectively adapt the test suite to support the new multiple app ID feature.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (6)

87-89: LGTM: Improved test setup.

The initialization of someAppId and someCluster in the setUp method is a good practice. It centralizes the setup and ensures consistency across all test methods.

193-193: LGTM: Consistent update of method call signature.

The submit method call has been correctly updated to include someAppId as the first parameter, maintaining consistency with other test methods.

255-256: LGTM: Updated method call, but verify timeout change.

The submit method call has been correctly updated to include someAppId as the first parameter, consistent with other test methods.

However, the timeout for onNotified.get() has been increased from 5000 to 50000 milliseconds. This significant increase might indicate that the test was failing due to timing issues. Please verify if this change is necessary and consider adding a comment explaining the reason for the increased timeout.

326-326: LGTM: Consistent updates to method call signatures.

Both submit method calls have been correctly updated to include someAppId as the first parameter, maintaining consistency with other test methods.

Also applies to: 329-329

587-593: LGTM: New method added, but verify null return behavior.

The new getAccessKeySecret(String appId) method has been correctly implemented to return someSecret when the provided appId matches someAppId. This addition supports app-specific access key secrets, which is consistent with the test setup.

However, please verify if returning null for other appIds is the intended behavior in the main implementation. Consider adding a comment explaining this behavior or throwing an exception for unknown appIds if that's more appropriate.

142-142: LGTM: Updated method call signature.

The submit method call has been correctly updated to include someAppId as the first parameter, consistent with changes in other test methods. This reflects an update in the RemoteConfigLongPollService.submit method signature.

✅ Verification successful

Further Verification Required: 'submit' method not found in the specified location.

The previous search did not locate the submit method in RemoteConfigLongPollService.java. Please run the following script to search for all implementations of the submit method across the codebase to verify its signature and location.

Further Verification Needed: Adjusting search pattern for submit method.

The previous search did not locate the submit method with the specified signature. Please run the following script to search for all implementations of the submit method across the codebase with a more flexible pattern to identify its exact signature and location.

Further Verification Required: Unable to locate submit method with existing patterns.

The previous searches did not locate the submit method in RemoteConfigLongPollService.java with the specified patterns. Please run the following script to perform a more flexible search for the submit method across the entire Java codebase, disregarding return types and parameter counts.

Further Verification Needed: Unable to locate submit method with previous search patterns.

The previous searches did not find the submit method in RemoteConfigLongPollService.java using the specified patterns. Please run the following script to perform a broader search for the submit method across the entire Java codebase to identify its signature and location.

Verified: submit method signature matches correctly.

The submit method in RemoteConfigLongPollService.java exists with the signature public boolean submit(String appId, String namespace, RemoteConfigRepository remoteConfigRepository). The test invocation correctly matches this signature.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check the signature of the submit method in RemoteConfigLongPollService
rg --type java "public.*submit\(" apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java

Length of output: 187

Script:

#!/bin/bash
# Search for all 'submit' method declarations in the Java codebase using ast-grep
ast-grep --lang java --pattern $'public void submit($_, $_, $_) { $$$ }' .

Length of output: 75

Script:

#!/bin/bash
# Search for all 'submit' method declarations in the Java codebase using ast-grep with a flexible pattern
ast-grep --lang java --pattern $'public $_ submit($_, $_, $_) { $$$ }' .

Length of output: 73

Script:

#!/bin/bash
# Search for all 'submit' method declarations in the Java codebase using ast-grep with a highly flexible pattern
ast-grep --lang java --pattern $'public $_ submit($_) { $$$ }' .

Length of output: 65

Script:

#!/bin/bash
# Broad search for 'submit' method declarations in Java codebase using ripgrep with context
rg --type java "submit\(" --context 2 .

Length of output: 10082

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderTest.java (11)

63-63: LGTM: New constant for app ID.

The addition of the someAppId constant is a good practice. It centralizes the app ID value used in tests, making it easier to maintain and update if needed.

74-74: LGTM: Updated mock configuration with app ID.

The inclusion of someAppId in the mockConfig call ensures that the test correctly simulates an environment with a specific app ID, improving the test's accuracy.

82-82: LGTM: Consistent use of app ID in mock configuration.

The addition of someAppId to the mockConfig call maintains consistency with other tests and accurately represents a scenario with a specific app ID but no configuration.

95-95: LGTM: App ID added to application property source test.

The inclusion of someAppId in this test ensures consistency across different property source scenarios and improves the test's relevance to real-world configurations.

111-111: LGTM: App ID added to properties-compatible config file test.

The addition of someAppId to the mockConfigFile call ensures that the test for properties-compatible sources also considers the app ID, maintaining consistency across different configuration types.

127-127: LGTM: Consistent app ID usage in non-normalized case test.

The addition of someAppId to this test case maintains consistency and ensures that the app ID is considered even when testing non-normalized property names.

139-143: LGTM: App ID consistently applied to multiple property sources.

The addition of someAppId to both mockConfig calls ensures that the test accurately represents a scenario where multiple property sources are used for the same application. This change improves the test's relevance to real-world multi-source configurations.

161-165: LGTM: App ID consistently applied in multiple properties-compatible sources test.

The addition of someAppId to both mockConfigFile and mockConfig calls ensures that the test accurately represents scenarios with multiple properties-compatible sources for the same application. This change improves the test's comprehensiveness.

180-184: LGTM: App ID consistently applied in overlapping property sources test.

The addition of someAppId to both mockConfig calls ensures that the test accurately represents scenarios where multiple property sources with overlapping properties are used for the same application. This change enhances the test's relevance to complex configuration scenarios.

199-203: LGTM: App ID consistently applied in mixed property sources test.

The addition of someAppId to both mockConfig calls ensures that the test accurately represents scenarios with multiple property sources, including properties-compatible sources, for the same application. This change improves the test's coverage of diverse configuration scenarios.

Line range hint 217-436: LGTM: Consistent application of app ID across all test methods.

The addition of someAppId to all remaining mockConfig and mockConfigFile calls ensures consistency across the entire test suite. This change:

  1. Improves the accuracy of test simulations by consistently representing a specific application context.
  2. Enhances the test suite's ability to catch potential issues related to app-specific configurations.
  3. Makes the tests more representative of real-world scenarios where each configuration is associated with a specific app ID.

These modifications collectively strengthen the test suite and improve its reliability in validating the Apollo client's behavior across various configuration scenarios.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigPlaceholderAutoUpdateTest.java (9)

55-55: New constant someAppId added

A new constant someAppId has been introduced. This is a good practice for maintaining consistency across the test class.

74-74: Improved flexibility in testAutoUpdateWithOneNamespace

The use of someAppId instead of ConfigConsts.NAMESPACE_APPLICATION in the prepareConfig method call enhances the test's flexibility. This change allows for easier testing with different app IDs.

101-102: Consistent use of someAppId in testAutoUpdateWithOneYamlFile

The prepareYamlConfigFile method now uses someAppId, maintaining consistency with the changes in other methods. This improves the overall coherence of the test class.

129-129: Consistent use of someAppId in testAutoUpdateWithValueAndXmlProperty

The prepareConfig method now uses someAppId, maintaining consistency with the changes in other methods. This enhances the uniformity of the test class.

161-162: Consistent use of someAppId in testAutoUpdateWithYamlFileWithValueAndXmlProperty

The prepareYamlConfigFile method now uses someAppId, aligning with the changes in other methods. This maintains the consistency of the test class.

199-199: Consistent use of someAppId in testAutoUpdateDisabled

The prepareConfig method now uses someAppId, maintaining consistency with the changes in other methods. This enhances the overall coherence of the test class.

229-230: Consistent use of someAppId and new pattern in testAutoUpdateWithMultipleNamespaces

The prepareConfig methods now use someAppId, maintaining consistency with other methods. Additionally, someAppId is now included in the onRepositoryChange method call, which is a new pattern. This change enhances the test's ability to simulate multi-app scenarios more accurately.

Also applies to: 241-241

270-271: Consistent use of someAppId in testAutoUpdateWithMultipleNamespacesWithSameProperties

The prepareConfig methods and onRepositoryChange call now use someAppId, maintaining consistency with the changes in the previous method. This uniform approach enhances the readability and maintainability of the test class.

Also applies to: 283-283

298-303: Consistent implementation of someAppId throughout the test class

The changes across the entire file demonstrate a consistent approach to using the newly introduced someAppId constant. This refactoring improves the test class in several ways:

  1. Increased flexibility: Tests can now be easily configured for different app IDs without modifying multiple locations.
  2. Better maintainability: Using a constant instead of hardcoded strings reduces the risk of typos and makes future changes easier.
  3. Improved readability: The consistent use of someAppId makes the purpose of the value clearer throughout the tests.

These changes align well with best practices for writing maintainable and flexible test code.

Also applies to: 328-328, 340-340, 354-354, 385-385, 397-397, 413-413, 424-424, 437-437, 447-447, 465-466, 494-494, 523-523, 549-549, 577-577, 608-608, 639-639, 670-670, 702-702, 730-730, 759-759, 794-794, 859-859, 894-894, 920-920, 933-933, 947-947, 960-960, 974-974, 987-987

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistry.java (1)

58-59: Verify consistency in getFactory method usage

Similarly, the getFactory(String namespace) method now calls getFactory(String appId, String namespace). Confirm that all usages of getFactory are consistent with this change and that the appId is appropriately managed in different contexts.

To identify all invocations of the getFactory method with a single parameter, run:

✅ Verification successful

getFactory Method Usage is Consistent

All usages of getFactory have been updated to include the appId parameter where necessary. The existing single-parameter usages are confined to test files and align with the current implementation.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Locate all calls to `getFactory` with one argument.

# Search for invocations of `getFactory` with one parameter
rg --type java 'getFactory\s*\(\s*[^,]+\s*\)'

Length of output: 2552

Script:

#!/bin/bash
# Description: Locate all calls to `getFactory` with one argument.

# Search for invocations of `getFactory` with one parameter
rg --type java 'getFactory\s*\(\s*[^,]+\s*\)'

Length of output: 2435

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (4)

35-35: Approved: Added m_configUtil member variable

The addition of m_configUtil is appropriate for accessing configuration utilities such as the appId. This enhances the flexibility of the configuration management.

44-44: Ensure correct appId is used when obtaining factory

The getFactory(String namespace) method now delegates to getFactory(m_configUtil.getAppId(), namespace). Ensure that m_configUtil.getAppId() returns the intended appId, especially in environments where multiple appIds are supported simultaneously.

73-73: Ensure thread-safe access when updating m_factories

When adding entries to m_factories, thread safety must be considered due to the use of HashBasedTable. This is related to the earlier concern about thread safety.

Refer to the previous comment on line 33 regarding making m_factories thread-safe.

50-50: ⚠️ Potential issue

Verify ConfigRegistry supports appId parameter in getFactory method

Confirm that the ConfigRegistry class has been updated to include the getFactory(String appId, String namespace) method. If not, this call may result in a compilation error or runtime issues.

Run the following script to verify if the ConfigRegistry class includes the new method signature:

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (1)

82-84: Addition of overloaded getConfig method aligns with PR objectives

The new method getConfig(String appId, String namespace) extends the functionality to support multiple app IDs, enhancing configuration retrieval capabilities as per the PR objectives.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (5)

42-42: Addition of m_appId field to support multiple application IDs

The introduction of the m_appId field appropriately allows the SimpleConfig class to handle configurations specific to different application IDs.

55-56: Preserving the original constructor for backward compatibility

The original constructor is retained and now delegates to the new constructor using this(null, namespace, configRepository);, ensuring backward compatibility with existing code.

65-69: New constructor facilitates configurable appId with fallback

Adding a new constructor that accepts appId enhances flexibility. The fallback to ConfigUtil.getAppId() when appId is null ensures seamless integration for cases where appId is not explicitly provided.

114-115: Overloading onRepositoryChange to include appId

The overloaded onRepositoryChange method with the appId parameter correctly expands functionality to handle repository changes for multiple application IDs.

Line range hint 125-137: Verify that calcPropertyChanges and fireConfigChange methods accept the appId parameter

To ensure that the methods calcPropertyChanges and fireConfigChange have been updated appropriately to accept the new appId parameter, please run the following script:

apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManagerTest.java (1)

151-155: Clarify method behavior in SomeConfigFactory and AnotherConfigFactory.

The overridden methods with the appId parameter in SomeConfigFactory and AnotherConfigFactory currently return null. If these factories are supposed to provide configuration objects based on appId and namespace, consider implementing them to return appropriate mock configurations or explain why returning null is acceptable in this context.

Also applies to: 160-164, 173-177, 182-186

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigManagerTest.java (2)

46-46: Initialization of someAppId in Test Setup

The addition of the someAppId variable and its initialization in the setUp method is appropriate. It prepares the test environment for multi-app ID support and aligns with the PR's objectives.

Also applies to: 54-54

Line range hint 116-180: Proper Implementation of Multi-App ID Support with Backward Compatibility

The updates to include the appId parameter in the method signatures of getFactory, create, and createConfigFile enhance configurability for multiple app IDs. The inclusion of overloaded methods without the appId parameter that default to someAppId ensures backward compatibility with existing code. This approach maintains existing functionality while extending support for the new feature.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (1)

95-96: Ensure consistency in method delegation for createConfigFile

The method createConfigFile(String namespace, ConfigFileFormat configFileFormat) delegates to createConfigFile with appId. This pattern maintains consistency and centralized handling of appId. Good practice!

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (5)

23-37: Imports Updated Appropriately for New Functionality

The added import statements for ConfigConsts, Maps, Multimaps, and Map are necessary for the introduced changes and ensure that all utilized classes and interfaces are properly referenced.

Also applies to: 48-51

65-65: Effective Management of Namespaces with APP_NAMESPACE_NAMES Map

The introduction of APP_NAMESPACE_NAMES as a Map<Integer, Multimap<String, String>> enhances the management of namespaces by associating them with both their order and appId. This structure supports multiple applications and maintains the necessary mapping efficiently.

75-76: Refactoring for Enhanced Flexibility in addNamespaces Method

By altering the existing addNamespaces(Collection<String> namespaces, int order) method to delegate to the overloaded version that includes appId, you promote code reuse and support the addition of multiple appIds seamlessly.

107-123: Correct Implementation of Namespace Initialization for Multiple App IDs

The revised logic in the initializePropertySources method accurately iterates through each order, appId, and namespace. This ensures that configurations are correctly loaded for each application and namespace combination, aligning with the PR's objective to support multiple appIds.

127-127: Proper Clearing of APP_NAMESPACE_NAMES to Prevent Memory Leaks

Clearing APP_NAMESPACE_NAMES after initialization and within the reset method is appropriate. It ensures that no residual data persists unnecessarily, which could lead to memory leaks in long-running applications.

Also applies to: 179-179

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (1)

122-130: ⚠️ Potential issue

Inconsistent Namespace Usage in prepareYamlConfigFile Method

Similar to prepareConfig, the prepareYamlConfigFile method might be misusing the namespace when initializing YamlConfigFile. Ensure that the correct namespace is used to prevent unexpected behavior.

Update the YamlConfigFile initialization to match the provided namespaceNameWithFormat:

 protected static YamlConfigFile prepareYamlConfigFile(String appId, String namespaceNameWithFormat, Properties properties) {
   ConfigRepository configRepository = mock(ConfigRepository.class);

   when(configRepository.getConfig()).thenReturn(properties);

   // spy it for testing after
-  YamlConfigFile configFile = spy(new YamlConfigFile(appId, namespaceNameWithFormat, configRepository));
+  YamlConfigFile configFile = spy(new YamlConfigFile(appId, namespaceNameWithFormat, configRepository));

   mockConfigFile(appId, namespaceNameWithFormat, configFile);

   return configFile;
 }

Ensure that any discrepancies between the namespace used in YamlConfigFile and the one registered in mockConfigFile are resolved.

Likely invalid or redundant comment.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (1)

297-300: Sanitize inputs when constructing file names

When assembling the local cache file name using appId, cluster, and namespace, ensure that these values do not contain characters that are invalid or unsafe for file names (e.g., slashes, colons). Consider sanitizing these inputs to prevent file system errors or security issues when reading from or writing to the file system.

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/annotation/ApolloAnnotationProcessor.java (2)

109-113: Maintain backward compatibility with existing configurations

By introducing appId into the configuration retrieval process, ensure that existing functionality remains unaffected. Configurations that do not specify an appId should continue to work as before. Testing the changes against existing use cases can help verify backward compatibility.

109-113: ⚠️ Potential issue

Verify the existence and usage of ConfigService.getConfig(String appId, String namespace)

The updated code introduces a call to ConfigService.getConfig(resolvedAppId, resolvedNamespace). Please ensure that the ConfigService class has a method getConfig(String appId, String namespace) implemented. If this method is newly added, make sure it's properly defined and all relevant classes are updated to support multiple appIds.

To confirm the method's existence and usage, you can run the following script:

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (4)

68-70: Constructor Delegation Maintains Backward Compatibility

The default constructor now delegates to the new constructor by passing null as the appId, which ensures backward compatibility while introducing support for multiple appIds.

78-84: Proper Initialization of m_appId and Resource Loading

The new constructor correctly initializes m_appId. If appId is null, it defaults to the value from ConfigUtil, maintaining the existing behavior. The loading of resource properties with the updated appId and namespace parameters ensures that configurations are appropriately fetched for each application.

240-241: Overloaded onRepositoryChange Method Enhances Flexibility

The addition of the overloaded onRepositoryChange method that includes appId allows the configuration to respond to repository changes specific to different applications, enhancing flexibility in handling multiple appIds.

325-335: Resource Loading Logic Preserves Backward Compatibility

The loadFromResource method first attempts to load the resource using the appId+namespace format. If the resource is not found and the provided appId matches the default appId, it falls back to loading the resource using just the namespace. This logic ensures that existing configurations without an appId prefix continue to work after the update, preserving backward compatibility.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5)

75-75: Addition of m_appId field is appropriate

The field m_appId is correctly declared as private final String and follows the existing naming conventions.

191-194: Consistency in using m_appId

Using this.m_appId to retrieve the appId ensures consistency throughout the class.

336-336: ⚠️ Potential issue

Confirm submit method in remoteConfigLongPollService accepts appId

Verify that the submit method of remoteConfigLongPollService has been updated to accept appId as its first parameter. If not, this may cause runtime or compilation issues.

Run the following script to check the submit method signature:

#!/bin/bash
# Find the submit method in RemoteConfigLongPollService
rg --type java 'void submit\(String appId,.*String namespace,.*RemoteConfigRepository repository\)'

96-96: Ensure all instantiations of RemoteConfigRepository are updated

With the addition of appId to the constructor, verify that all places where RemoteConfigRepository is instantiated have been updated to include the new appId parameter.

You can use the following script to locate instantiations:

✅ Verification successful

All instantiations of RemoteConfigRepository have been updated with the appId and namespace parameters.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Find all instantiations of RemoteConfigRepository
rg --type java 'new RemoteConfigRepository\('

Length of output: 1813

160-160: ⚠️ Potential issue

Verify fireRepositoryChange method accepts appId parameter

Ensure that the fireRepositoryChange method has been updated to accept appId as an argument. If it hasn't been modified, this call may lead to compilation errors.

Use the following script to check the method signature:

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (4)

570-570: Ensure all invocations of calcPropertyChanges include the new appId parameter

The method calcPropertyChanges now includes an appId parameter. Please verify that all calls to this method have been updated to include the appId parameter to prevent any potential issues.

Run the following script to find any calls to calcPropertyChanges that may not include the appId parameter:

✅ Verification successful

All invocations of calcPropertyChanges include the new appId parameter.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all method calls to `calcPropertyChanges` with three arguments (missing `appId`).

ast-grep --lang java --pattern $'calcPropertyChanges($_, $_, $_)'

Length of output: 233

Script:

#!/bin/bash
# Description: Find all method calls to `calcPropertyChanges` with three arguments (missing `appId`).

ast-grep --lang java --pattern $'calcPropertyChanges($_, $_, $_)'

Length of output: 66

590-590: Confirm that ConfigChange class constructor accepts appId as the first parameter

In the instantiations of ConfigChange, the appId is passed as the first argument. Please verify that the ConfigChange class constructor has been updated to accept the appId parameter and that all usages of this class throughout the codebase have been updated accordingly.

Run the following script to check the constructor definition of ConfigChange:

Also applies to: 595-595, 605-605

457-457: Ensure all invocations of fireConfigChange include the new appId parameter

The method signature of fireConfigChange has been updated to include an appId parameter. Please verify that all calls to this method throughout the codebase have been updated to pass the appropriate appId value to prevent compilation errors or unexpected behavior.

Run the following script to find any invocations of fireConfigChange that may not have been updated:

465-465: Verify that InterestedConfigChangeEvent constructor supports the appId parameter

In the line InterestedConfigChangeEvent(appId, namespace, changes, interestedChangedKeys);, the InterestedConfigChangeEvent is instantiated with the appId parameter. Please ensure that the constructor of InterestedConfigChangeEvent has been updated to accept the appId parameter and that all usages of this class are consistent with this change.

Run the following script to verify the constructor definition of InterestedConfigChangeEvent:

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (2)

85-89: Addition of getAppId() method enhances functionality

Introducing the getAppId() method provides necessary access to the m_appId field, enhancing the class's functionality. This addition aligns with best practices for encapsulation and data access.

Line range hint 102-125: Verify impact of passing appId to ConfigFileChangeEvent

The constructor of ConfigFileChangeEvent now includes the appId. It's important to verify that all usages of ConfigFileChangeEvent are updated accordingly and that the event handling mechanisms accommodate the new parameter without side effects.

Run the following script to check for other usages of ConfigFileChangeEvent:

✅ Verification successful

Verified: All ConfigFileChangeEvent constructor usages are updated correctly.

All instances of ConfigFileChangeEvent have been updated to include the appId parameter. No other usages without the new parameter were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all instantiations of ConfigFileChangeEvent and verify constructor parameters.

# Test: Search for all 'new ConfigFileChangeEvent' usages.
# Expect: Constructor calls should match the updated signature.

rg --type java --pcre2 '(new\s+ConfigFileChangeEvent\s*\()' -A 3

Length of output: 600

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java (2)

74-74: Approved: Addition of someAppId variable

The declaration and initialization of the someAppId variable are appropriate and align with the changes to support multiple app IDs.

Also applies to: 95-95

150-150: Skip: Past review comments are still applicable

The updates to the DefaultConfig constructor calls have been previously reviewed and the comments are still valid.

Also applies to: 183-183, 202-202, 225-225, 256-256, 288-288, 323-323, 346-346, 369-369, 392-392, 415-415, 438-438, 461-461, 485-485, 521-521, 547-547, 577-577, 596-596, 614-614, 652-652, 719-719, 745-745, 805-805, 840-840, 867-867, 880-880, 900-900, 926-926

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java (5)

116-117: Consistent Use of someAppId in Mock Configurations

The mockConfig method calls have been updated to use someAppId as the appId, improving consistency across the tests. Ensure that all instances where mockConfig is called are updated accordingly to avoid any discrepancies in the test configurations.

Also applies to: 135-135, 145-147, 161-161, 164-164, 176-176, 185-185, 197-198, 212-213, 266-266, 275-275, 285-286, 342-343, 374-374, 400-404, 407-407, 464-467, 470-471, 495-501, 520-526, 541-546, 565-568, 580-580, 586-589, 596-600, 609-618, 627-627, 641-646

653-678: New Test Method testApolloMultipleConfig Verified

The new test method testApolloMultipleConfig effectively validates the functionality of multiple configurations with different appIds. The setup of mocked configurations and assertions appears correct.

1111-1112: Consistency in @ApolloConfig Annotations

In the TestApolloConfigBean5 class, the @ApolloConfig annotation on the multipleConfig field specifies both appId and value. Ensure that this matches the expected annotation parameters and that the configuration is correctly injected.

1097-1106: Correct Usage of @MultipleConfig Annotation

The @EnableApolloConfig annotation now includes the multipleConfigs attribute, utilizing the @MultipleConfig annotation to specify additional appIds and namespaces. Verify that this usage aligns with the framework's implementation of multiple configurations.

#!/bin/bash
# Description: Check the definition of `EnableApolloConfig` to confirm it supports `multipleConfigs`.

# Test: Search for the `EnableApolloConfig` annotation definition.
rg '@interface EnableApolloConfig' -A 20

# Expected Result: The `EnableApolloConfig` definition should include the `multipleConfigs` attribute.

661-664: Verify Namespace Loading for Multiple appIds

Ensure that the namespaces specified for different appIds are correctly loaded and that there are no conflicts or overlaps between them. This is critical when supporting multiple applications.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java Show resolved Hide resolved
apollo-core/src/main/java/com/ctrip/framework/foundation/spi/provider/ApplicationProvider.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/spi/DefaultConfigRegistryTest.java Show resolved Hide resolved
...rc/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/AbstractConfigTest.java Show resolved Hide resolved
...o-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java Outdated Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/DefaultConfigTest.java Show resolved Hide resolved
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/JavaConfigAnnotationTest.java Show resolved Hide resolved
nobodyiam
nobodyiam reviewed Oct 19, 2024
View reviewed changes
...lo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java Outdated Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java Outdated Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java Outdated Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java Outdated
Comment on lines 199 to 201
protected static void doTearDown(){
MockInjector.reset();
CONFIG_REGISTRY.clear();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point.

nobodyiam
nobodyiam reviewed Oct 19, 2024
View reviewed changes
Copy link
Member

@nobodyiam nobodyiam left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here are additional comments as mentioned above.

coderabbitai[bot]
coderabbitai bot reviewed Oct 21, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (7)
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (3)

58-59: LGTM: Test setup improved with app ID and property sources mocking.

The changes in the setUp method enhance the test environment by:

  1. Introducing a consistent someAppId for testing.
  2. Setting the APP_ID system property to mimic a real scenario.
  3. Mocking environment.getPropertySources() for proper interaction testing.

These changes improve the test's ability to simulate real-world conditions.

Consider moving the someAppId declaration to be a class-level constant, as it's used in multiple test methods:

private static final String SOME_APP_ID = "someAppId";

This would improve consistency and make it easier to update the app ID across all tests if needed.

Also applies to: 63-64, 69-69

86-86: LGTM: Test updated to include app ID in configurations and assertions.

The testInitializePropertySources method has been correctly updated to:

  1. Use someAppId in mockConfig calls, reflecting the new multi-app ID support.
  2. Update assertions to check for the correct property source names, now including the app ID.

These changes ensure that the test accurately verifies the new behavior of including app IDs in namespace configurations.

For consistency with the suggested class-level constant, replace the local someAppId declaration with the constant:

- String someAppId = "someAppId";
+ // Use the class-level constant SOME_APP_ID instead

This would eliminate redundancy and ensure consistent use of the app ID across all test methods.

Also applies to: 91-92, 110-110, 112-112

118-118: LGTM: Test updated to include app ID in configuration mocking.

The testApplicationEvent method has been correctly updated to use someAppId in the mockConfig call, maintaining consistency with the multi-app ID support changes.

For consistency with the previous suggestion and to reduce redundancy, replace the local someAppId declaration with the proposed class-level constant:

- String someAppId = "someAppId";
+ // Use the class-level constant SOME_APP_ID instead

This change would ensure consistent use of the app ID across all test methods and improve maintainability.

Also applies to: 121-121

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (3)

31-33: Remove unused import.

The import com.ctrip.framework.apollo.spring.config.PropertySourcesProcessor on line 38 is not used in the visible changes. Consider removing it to keep the imports clean and avoid potential confusion.

Also applies to: 38-38

586-593: LGTM: New method to support multi-app ID feature.

The addition of getAccessKeySecret(String appId) in the MockConfigUtil class correctly supports the new multi-app ID feature. It allows for different access key secrets for different app IDs, which is aligned with the expected behavior.

Consider adding a default return value (e.g., an empty string) instead of null for unknown app IDs to prevent potential null pointer exceptions.

 @Override
 public String getAccessKeySecret(String appId){
   if(appId.equals(someAppId)){
     return someSecret;
   }
-  return null;
+  return "";
 }

Line range hint 1-593: Consider adding tests for edge cases.

The current tests cover the basic functionality of the multi-app ID feature well. However, to improve robustness, consider adding test cases for edge cases such as:

  1. Empty app ID
  2. Null app ID
  3. App ID with special characters
  4. Very long app ID

These additional tests would help ensure the code handles various scenarios correctly and improve overall test coverage.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (1)

82-84: Add JavaDoc comments for the new public method

To maintain consistency and improve code readability, please add JavaDoc comments for the newly added getConfig(String appId, String namespace) method, similar to the existing getConfig methods.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between efc4d7f and 5e3885e.

📒 Files selected for processing (9)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (2 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (6 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (10 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (11 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (7 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (7 hunks)
🧰 Additional context used
📓 Learnings (2)
apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (2)
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java:64-64
Timestamp: 2024-10-01T03:05:09.661Z
Learning: In the `PropertySourcesProcessor` class, the `APP_NAMESPACE_NAMES` map and its inner `Multimap` instances do not need to be thread-safe because concurrent access is not expected.

Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java:64-64
Timestamp: 2024-10-08T15:31:24.844Z
Learning: In the `PropertySourcesProcessor` class, the `APP_NAMESPACE_NAMES` map and its inner `Multimap` instances do not need to be thread-safe because concurrent access is not expected.
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (1)
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java:64-64
Timestamp: 2024-10-01T03:05:09.661Z
Learning: In the `PropertySourcesProcessor` class, the `APP_NAMESPACE_NAMES` map and its inner `Multimap` instances do not need to be thread-safe because concurrent access is not expected.
🔇 Additional comments (40)
apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessorTest.java (3)

19-25: LGTM: Import statements updated appropriately.

The new static imports for JUnit Assert and Mockito methods, as well as the additional imports for Java util and Spring core classes, are appropriate for the changes made in this test class. These imports improve code readability and indicate the use of new functionality in the test cases.

Also applies to: 37-37, 44-48

166-166: LGTM: Minor adjustment in assertion order.

The change in the assertion order for the property source name is a minor adjustment that doesn't affect the test's functionality. It likely improves readability or aligns with a preferred coding style.

Line range hint 1-167: Summary: PropertySourcesProcessorTest.java successfully updated for multi-app ID support

The changes in this file effectively update the test cases to support and verify the new multi-app ID feature. Key points:

  1. Consistent use of someAppId across test methods.
  2. Updated mocking and assertions to include app ID in configurations and property source names.
  3. Maintained existing test coverage while adapting to the new feature.

The suggested improvements (using a class-level constant for someAppId) would further enhance consistency and maintainability. Overall, the changes are well-implemented and provide good coverage for the new functionality.

apollo-client/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java (4)

87-89: LGTM: Good initialization of test variables.

The addition of someAppId and someCluster in the setUp method is a good practice. It centralizes the initialization of these variables, which are likely used across multiple test methods to support the new multi-app ID feature.

142-142: LGTM: Updated method call to support multi-app ID feature.

The submit method call has been correctly updated to include someAppId as the first parameter, aligning with the new multi-app ID feature implementation.

193-193: LGTM: Consistent updates to support multi-app ID feature.

All submit method calls have been consistently updated to include someAppId as the first parameter. This change properly implements the new multi-app ID feature across all relevant test methods, ensuring comprehensive test coverage for the new functionality.

Also applies to: 255-255, 326-326, 329-329, 397-398, 458-458

Line range hint 1-593: Overall, excellent implementation of multi-app ID feature tests.

The changes in this file consistently and effectively implement tests for the new multi-app ID feature. Key points:

  1. All relevant test methods have been updated to include the app ID parameter.
  2. The MockConfigUtil class has been extended to support app ID-specific access key secrets.
  3. The code maintains good structure and follows testing best practices.

The implementation thoroughly covers the new functionality while preserving existing test coverage. Great job on maintaining code quality and test comprehensiveness throughout these changes.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java (1)

31-31: Thread-safety ensured for m_factories

The m_factories variable is now wrapped with Tables.synchronizedTable(), which ensures thread safety in a concurrent environment.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (1)

97-100: Inconsistency in using namespaceFileName in getFactory and createConfigFile

As previously noted, passing namespaceFileName (which includes the file extension) instead of namespace to getFactory and createConfigFile may cause inconsistencies if the factory expects the logical namespace without the file extension.

apollo-client/src/test/java/com/ctrip/framework/apollo/ConfigServiceTest.java (15)

64-64: Update usage of ConfigService.setConfig() to match new constructor parameters

The MockConfig constructor now requires an appId parameter. The invocation of ConfigService.setConfig() correctly reflects this change by passing someAppId and someNamespace.

68-68: Ensure assertions reflect the new key format including appId

The assertion now includes someAppId in the expected property key, which aligns with the updated getProperty method in MockConfig that returns keys formatted with appId and namespace.

79-79: Update test to accommodate new appId inclusion in property keys

In the testHackConfigFactory test method, the assertion has been updated to include someAppId in the expected property key. This change is necessary due to the updated MockConfig behavior that now includes appId in property keys.

91-91: Modify test expectations to include appId in MockConfig property keys

The assertion in testMockConfigFactory correctly updates the expected value by including someAppId, matching the new key format returned by MockConfig.

109-110: Introduce m_appId field to MockConfig

The addition of private final String m_appId; in MockConfig is necessary to store the appId passed to the constructor, enabling the class to use it in property key generation.

112-113: Update MockConfig constructor to accept appId

The constructor now accepts String appId as a parameter, allowing instances of MockConfig to be associated with a specific application ID. This change supports the enhanced configuration management for multiple app IDs.

123-123: Modify getProperty method to include appId in the returned key

The getProperty method now returns a key formatted with m_appId and m_namespace, enhancing the uniqueness of property keys across different applications and namespaces.

139-140: Add m_appId field to MockConfigFile

Introducing private String m_appId; in MockConfigFile allows the class to store the application ID, which is essential for application-specific configuration files.

148-153: Add new constructor to MockConfigFile accepting appId

The new constructor enables MockConfigFile to be instantiated with an appId, namespace, and configFileFormat. This supports application-specific configuration file handling.

165-168: Implement getAppId() method in MockConfigFile

The getAppId() method correctly returns m_appId, ensuring that the application ID can be retrieved from MockConfigFile instances. This change addresses the previous issue where getAppId() returned null.

199-200: Delegate to new create(String appId, String namespace) method

In MockConfigFactory, the existing create(String namespace) method now delegates to the new create(String appId, String namespace) method, ensuring consistency in object creation with the inclusion of appId.

202-204: Add create(String appId, String namespace) method to MockConfigFactory

This new method allows MockConfigFactory to create Config instances with a specific appId and namespace, supporting the enhanced multi-application configuration management.

209-210: Delegate to new createConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) method

The existing createConfigFile(String namespace, ConfigFileFormat configFileFormat) method now calls the new method that includes appId, ensuring that ConfigFile instances are created with the correct application context.

212-214: Add createConfigFile(String appId, String namespace, ConfigFileFormat configFileFormat) method

This method in MockConfigFactory creates MockConfigFile instances with the specified appId, namespace, and configFileFormat, aligning with the application's requirement to support multiple app IDs.

199-214: Verify consistency in factory method overrides

Ensure that all overridden methods in MockConfigFactory correctly handle the addition of appId. The new methods enhance the factory's ability to produce configuration objects that are aware of application IDs.

Run the following script to confirm that all factory methods correctly handle appId:

apollo-client/src/main/java/com/ctrip/framework/apollo/spring/config/PropertySourcesProcessor.java (5)

64-64: LGTM: Introduction of APP_NAMESPACE_NAMES to support multiple app IDs

The change from NAMESPACE_NAMES to APP_NAMESPACE_NAMES appropriately updates the data structure to handle multiple app IDs, aligning with the PR objectives of enhancing configuration capabilities.

74-75: LGTM: Overloaded addNamespaces method delegates correctly

The method addNamespaces(Collection<String> namespaces, int order) correctly delegates to the new overloaded method by obtaining the appId using ConfigUtil and passes it along with the namespaces and order.

77-83: LGTM: Proper handling of namespaces within addNamespaces

The addNamespaces(String appId, Collection<String> namespaces, int order) method correctly updates APP_NAMESPACE_NAMES by associating namespaces with the specified appId and order. The logic ensures namespaces are organized per application ID.

106-122: LGTM: initializePropertySources method updated for multiple app IDs

The iteration over APP_NAMESPACE_NAMES in initializePropertySources properly processes each appId and its associated namespaces. The construction of property sources now accommodates multiple app IDs, effectively supporting the PR's goal.

178-180: LGTM: Reset functionality updated appropriately

The reset() method correctly clears APP_NAMESPACE_NAMES and AUTO_UPDATE_INITIALIZED_BEAN_FACTORIES, ensuring the class resets its state as expected.

apollo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java (2)

99-99: Correct usage of namespaceName in SimpleConfig initialization

Good job updating the SimpleConfig constructor to use namespaceName. This ensures that configurations are correctly associated with their respective namespaces.

200-200: Cleared CONFIG_FILE_REGISTRY in doTearDown method

Adding CONFIG_FILE_REGISTRY.clear(); ensures that residual states are removed after tests, preventing interference with subsequent tests.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (9)

42-49: Appropriate imports for new data structures

The added imports for HashBasedTable, Table, and Tables are necessary and correct for the implementation of the new data structures used in the class.

82-84: Proper initialization of thread-safe collections

The utilization of ConcurrentHashMap for m_longPollStarted, a concurrent map for m_longPollNamespaces, and a synchronized Table for m_notifications ensures thread safety across concurrent operations.

100-104: Consistent use of cached thread pool

Switching to Executors.newCachedThreadPool for m_longPollingService aligns with best practices for managing dynamic workloads and enhances performance in a multi-application environment.

114-123: Thread-safe repository submission with computeIfAbsent

Implementing computeIfAbsent for m_longPollNamespaces effectively eliminates race conditions when multiple threads submit repositories for the same appId, ensuring atomic initialization of repositoryMultimap.

127-129: Atomic check-and-set for starting long polling

Using putIfAbsent on m_longPollStarted provides an atomic operation to prevent multiple threads from starting redundant long polling for the same appId.

152-152: Proper cleanup on exception

Removing the appId from m_longPollStarted in the catch block ensures that the system can retry starting long polling if an exception occurs during initialization.

238-241: Null check prevents potential NullPointerException

Adding a null check for namespaceRepositories in the notify method safeguards against a possible NullPointerException if no repositories are registered for a given appId.

262-275: Accurate update of notifications per appId

The updateNotifications method correctly updates notification IDs for each namespace under the specified appId, ensuring that the notification system functions accurately in a multi-application context.

301-306: Safely assembling namespaces with null checks

Including a null check in the assembleNamespaces method prevents errors when no namespaces are registered for an appId, enhancing the robustness of the method.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Show resolved Hide resolved
...lo-client/src/test/java/com/ctrip/framework/apollo/spring/AbstractSpringIntegrationTest.java Show resolved Hide resolved
@TerryLam2010
Merge branch 'main' into 20240703-apollo-multiple-appid
f81a266 
# Conflicts:
#	apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java
#	apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java
#	apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java
#	apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java
#	apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java
coderabbitai[bot]
coderabbitai bot reviewed Oct 21, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 10

🧹 Outside diff range and nitpick comments (12)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1)

67-70: LGTM! Consider adding null check and updating documentation.

The changes to the fireRepositoryChange method align well with the PR objectives of supporting multiple app IDs. The addition of the appId parameter is consistent with similar updates across the codebase, as evidenced by the retrieved learnings.

To further improve the implementation:

  1. Consider adding a null check for the appId parameter to enhance robustness:
if (appId == null) {
    logger.warn("Received null appId in fireRepositoryChange. Using default or throwing an exception might be appropriate.");
    // Decide whether to use a default value or throw an exception
}
  1. Update the method's documentation to reflect the new appId parameter:
/**
 * Notifies all registered listeners of a repository change.
 *
 * @param appId The ID of the application for which the change occurred
 * @param namespace The namespace of the changed properties
 * @param newProperties The new set of properties
 */
protected void fireRepositoryChange(String appId, String namespace, Properties newProperties) {
    // ... existing implementation ...
}
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (1)

40-41: LGTM! Consider adding a brief comment for clarity.

The constructor change aligns with the PR objectives to support multiple app IDs. The implementation looks correct and consistent with changes in other classes.

Consider adding a brief comment explaining the purpose of the appId parameter for better clarity:

 public YamlConfigFile(String appId, String namespace, ConfigRepository configRepository) {
+    // appId is used to support multiple application configurations
     super(appId, namespace, configRepository);
     tryTransformToProperties();
 }
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (2)

59-61: Well-implemented getConfig method changes

The changes to the getConfig method effectively introduce multi-application support while maintaining backward compatibility. The new overloaded method correctly uses the Table data structure and updates the locking mechanism appropriately.

Consider optimizing the lock key generation:

-Object lock = m_configLocks.computeIfAbsent(String.format("%s.%s", appId, namespace), key -> new Object());
+Object lock = m_configLocks.computeIfAbsent(appId + "." + namespace, key -> new Object());

This change reduces the overhead of String.format in a potentially high-frequency operation.

Also applies to: 63-76

Line range hint 37-37: Well-implemented multi-application support with minor suggestion

The overall changes to DefaultConfigManager effectively implement multi-application support while maintaining backward compatibility and thread-safety. The class structure remains consistent and well-organized.

As a minor suggestion:

Consider updating the class-level JavaDoc to reflect the new multi-application support feature. This will help future developers understand the enhanced capabilities of this class.

apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (1)

226-226: LGTM! Consider adding a comment for clarity.

The change correctly updates the test to use the new getDefaultLocalCacheDir(appId) method signature. This aligns with the new functionality of supporting multiple app IDs.

Consider adding a brief comment explaining the purpose of including someAppId in the expected result, to enhance test readability:

// Verify that the cache directory includes both the system property value and the app ID
assertEquals(someCacheDir + File.separator + someAppId, configUtil.getDefaultLocalCacheDir(someAppId));
apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (2)

321-330: Consider adding a null check for the appId parameter.

The method implementation looks good and follows the existing coding standards. However, to improve robustness, consider adding a null check for the appId parameter at the beginning of the method.

Here's a suggested implementation:

 public String getDefaultLocalCacheDir(String appId) {
+  if (Strings.isNullOrEmpty(appId)) {
+    throw new IllegalArgumentException("appId must not be null or empty");
+  }
   String cacheRoot = getCustomizedCacheRoot();

   if (!Strings.isNullOrEmpty(cacheRoot)) {
     return cacheRoot + File.separator + appId;
   }

   cacheRoot = isOSWindows() ? "C:\\opt\\data\\%s" : "/opt/data/%s";
   return String.format(cacheRoot, appId);
 }

602-604: Approve implementation with a suggestion for null check.

The implementation looks good and correctly delegates the call to Foundation.app().getAccessKeySecret(appId). However, consider adding a null check for the appId parameter to improve robustness.

Here's a suggested implementation:

 public String getAccessKeySecret(String appId){
+  if (Strings.isNullOrEmpty(appId)) {
+    throw new IllegalArgumentException("appId must not be null or empty");
+  }
   return Foundation.app().getAccessKeySecret(appId);
 }
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (1)

66-70: Consider adding unit tests for the new constructor

Adding unit tests for scenarios with and without a provided appId will enhance test coverage and ensure the new logic functions as intended.

Would you like assistance in creating these unit tests or opening a GitHub issue to track this task?

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (1)

96-98: Add missing JavaDoc for the new public method

The new public method getConfig(String appId, String namespace) lacks a JavaDoc comment. Adding documentation will improve code readability and help other developers understand its purpose and usage.

Apply this change to add JavaDoc for the method:

+  /**
+   * Get the config instance for the specified appId and namespace.
+   *
+   * @param appId     the application ID
+   * @param namespace the namespace of the config
+   * @return config instance
+   */
   public static Config getConfig(String appId, String namespace) {
     return s_instance.getManager().getConfig(appId, namespace);
   }
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (1)

Line range hint 105-127: Method parameters appId and namespace are not used within onRepositoryChange

In the method onRepositoryChange(String appId, String namespace, Properties newProperties), the parameters appId and namespace are not utilized inside the method body. Instead, the class fields m_appId and m_namespace are used. This could lead to unexpected behavior if the passed parameters differ from the class fields.

Consider using the method parameters within the method to ensure consistency and correct handling of the provided arguments.

Apply this diff to fix the issue:

 public synchronized void onRepositoryChange(String appId, String namespace, Properties newProperties) {
     if (newProperties.equals(m_configProperties.get())) {
         return;
     }
     Properties newConfigProperties = propertiesFactory.getPropertiesInstance();
     newConfigProperties.putAll(newProperties);

     String oldValue = getContent();

     update(newProperties);
     m_sourceType = m_configRepository.getSourceType();

     String newValue = getContent();

     PropertyChangeType changeType = PropertyChangeType.MODIFIED;

     if (oldValue == null) {
         changeType = PropertyChangeType.ADDED;
     } else if (newValue == null) {
         changeType = PropertyChangeType.DELETED;
     }

-    this.fireConfigChange(new ConfigFileChangeEvent(m_appId, m_namespace, oldValue, newValue, changeType));
+    this.fireConfigChange(new ConfigFileChangeEvent(appId, namespace, oldValue, newValue, changeType));

-    Tracer.logEvent(APOLLO_CLIENT_CONFIGCHANGES, m_namespace);
+    Tracer.logEvent(APOLLO_CLIENT_CONFIGCHANGES, namespace);
 }
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (2)

205-208: Null Check for appId Parameter

In the method loadFromLocalCacheFile, consider adding a null check for the appId parameter to prevent potential NullPointerException.

Apply this diff to add a null check:

   private Properties loadFromLocalCacheFile(File baseDir, String appId, String namespace) throws IOException {

+    Preconditions.checkNotNull(appId, "appId cannot be null");
     Preconditions.checkNotNull(baseDir, "Basedir cannot be null");

240-244: Consistent Null Checks for Parameters

Similarly, in persistLocalCacheFile, ensure all parameters are validated to prevent unintended runtime exceptions.

Apply this diff to add null checks:

 void persistLocalCacheFile(File baseDir, String appId, String namespace) {
     if (baseDir == null) {
       return;
     }
+    Preconditions.checkNotNull(appId, "appId cannot be null");
+    Preconditions.checkNotNull(namespace, "namespace cannot be null");
     File file = assembleLocalCacheFile(baseDir, appId, namespace);
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 5e3885e and f81a266.

📒 Files selected for processing (13)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (7 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (8 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (12 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (5 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java (1 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2 hunks)
🧰 Additional context used
📓 Learnings (3)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (1)
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java:85-85
Timestamp: 2024-10-19T12:52:36.706Z
Learning: In the Java class `ConfigChangeEvent` (`apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java`), the constructor has been updated to accept three parameters: `String appId`, `String namespace`, and `Map<String, ConfigChange> changes`.
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigRepository.java (2)
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java:32-38
Timestamp: 2024-10-19T12:48:00.553Z
Learning: In the Apollo Java client, the class `PureApolloConfig` extends `DefaultConfig`, which implements the `onRepositoryChange(String appId, String namespace, Properties newProperties)` method from the `RepositoryChangeListener` interface. Therefore, `PureApolloConfig` doesn't need its own implementation of this method.

Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java:85-85
Timestamp: 2024-10-19T12:52:36.706Z
Learning: In the Java class `ConfigChangeEvent` (`apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java`), the constructor has been updated to accept three parameters: `String appId`, `String namespace`, and `Map<String, ConfigChange> changes`.
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (2)
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/test/java/com/ctrip/framework/apollo/spring/config/CachedCompositePropertySourceTest.java:85-85
Timestamp: 2024-10-19T12:52:36.706Z
Learning: In the Java class `ConfigChangeEvent` (`apollo-client/src/main/java/com/ctrip/framework/apollo/model/ConfigChangeEvent.java`), the constructor has been updated to accept three parameters: `String appId`, `String namespace`, and `Map<String, ConfigChange> changes`.

Learnt from: nobodyiam
PR: apolloconfig/apollo-java#70
File: apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RepositoryChangeListener.java:32-38
Timestamp: 2024-10-19T12:48:00.553Z
Learning: In the Apollo Java client, the class `PureApolloConfig` extends `DefaultConfig`, which implements the `onRepositoryChange(String appId, String namespace, Properties newProperties)` method from the `RepositoryChangeListener` interface. Therefore, `PureApolloConfig` doesn't need its own implementation of this method.
🔇 Additional comments (44)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java (4)

28-29: Improved data structure for multi-application support

The changes to import statements and data structures are well-implemented:

  • The use of Table instead of Map allows for efficient storage and retrieval of configurations based on both appId and namespace.
  • Tables.synchronizedTable ensures thread-safety for the new data structures.

These changes effectively support the multi-application configuration management feature.

Also applies to: 32-33, 44-45, 48-49

42-43: Appropriate addition of ConfigUtil

The addition of ConfigUtil as a member variable and its initialization in the constructor using ApolloInjector is appropriate. This change supports the retrieval of the application ID in various methods, which is crucial for the multi-application support feature.

Also applies to: 55-55

73-75: Appropriate updates to ConfigFactory usage

The changes to ConfigFactory usage, including the addition of the appId parameter to getFactory, create, and createConfigFile methods, are consistent with the multi-application support feature. These updates ensure that the correct factory is used for each appId and namespace combination.

Also applies to: 104-106

76-76: Effective updates to configuration storage

The changes to configuration storage, including the use of Table data structures and the addition of appId in put operations, are well-implemented. These updates ensure that configurations are correctly stored and retrieved based on both appId and namespace, which is crucial for the multi-application support feature.

Also applies to: 107-107

apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (1)

239-239: LGTM! Consider addressing the existing comment about hardcoded paths.

The changes correctly update the test to use the new getDefaultLocalCacheDir(appId) method signature for both Windows and non-Windows systems. This aligns with the new functionality of supporting multiple app IDs.

The existing comment about hardcoded paths in the tests is still relevant. Consider addressing this issue to make the tests more robust and environment-independent.

Also applies to: 243-243

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java (6)

43-43: Addition of m_appId enhances multi-application support

The introduction of the m_appId field effectively supports configurations for multiple application IDs within SimpleConfig.

56-58: Original constructor is preserved and delegates appropriately

By retaining the original constructor and delegating to the new one, backward compatibility is maintained.

66-70: Proper handling of appId in the new constructor

The overloaded constructor correctly initializes m_appId, ensuring that when appId is null, it defaults to the configured application ID.

115-116: Consistent use of m_appId in onRepositoryChange

Using m_appId when delegating to the overloaded onRepositoryChange ensures consistency with the instance's application ID.

Line range hint 118-138: Appropriate propagation of appId in configuration change handling

The updated onRepositoryChange method and subsequent calls correctly utilize appId, ensuring that configuration changes are accurately associated with the correct application context.

138-138: Alignment with previous reviewer feedback on fireConfigChange

Using the passed appId in fireConfigChange reflects adherence to previous review suggestions and promotes consistency.

apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java (2)

130-134: ⚠️ Potential issue

Re-evaluate the appId matching logic for multiple appId support

The current implementation in create(String appId, String namespace) only returns the config if the provided appId matches the default appId. This behavior restricts the support for multiple appIds, as it doesn't allow configurations for different appIds to be retrieved.

Please verify if this implementation aligns with the intention of supporting multiple appIds. If the goal is to fetch configurations for various appIds, consider adjusting the logic to handle different appIds appropriately.

121-122: 🛠️ Refactor suggestion

Limit the scope of m_configUtil

The variable m_configUtil is declared at the class level within the anonymous ConfigFactory, but it's only used in the create(String appId, String namespace) method. To improve code readability and maintainability, consider moving its declaration inside the method to limit its scope.

Apply this change to adjust the scope of m_configUtil:

-      private final ConfigUtil m_configUtil = ApolloInjector.getInstance(ConfigUtil.class);

       @Override
       public Config create(String appId, String namespace) {
+        ConfigUtil m_configUtil = ApolloInjector.getInstance(ConfigUtil.class);
         if(!StringUtils.equals(appId, m_configUtil.getAppId())){
           throw new IllegalArgumentException("Provided appId '" + appId + "' does not match the default appId '" + m_configUtil.getAppId() + "'");
         }
         return config;
       }

Likely invalid or redundant comment.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfigFile.java (2)

50-50: LGTM!

The addition of m_appId as a protected field enhances the ability to manage configurations specific to an application.

87-91: LGTM!

Providing the getAppId() method offers necessary access to the application ID for external classes.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java (4)

301-301: Ensure Cluster Information Is Correctly Retrieved

In the assembleLocalCacheFile method, you are joining appId, m_configUtil.getCluster(), and namespace. Verify that m_configUtil.getCluster() returns the correct cluster information, especially in multi-app scenarios.

Run the following script to check usages of getCluster and ensure consistency:

#!/bin/bash
# Description: Verify that `getCluster()` is used appropriately.

# Test: Search for `getCluster()` usages. Expect: Consistent use across the codebase.

rg 'getCluster\(\)'

298-301: Validate File Naming Convention for Cache Files

The cache file name now includes the appId. Ensure that this naming convention aligns with other parts of the system that read from or write to these cache files to prevent any file access discrepancies.

Run the following script to find usages of assembleLocalCacheFile and verify consistency:

#!/bin/bash
# Description: Find all usages of `assembleLocalCacheFile` to ensure consistent file naming.

# Test: Search for calls to `assembleLocalCacheFile`. Expect: All calls include `appId`.

rg 'assembleLocalCacheFile\([^,]+,\s*appId,\s*[^)]+\)'

137-138: ⚠️ Potential issue

Incorrect Use of @Override Annotation

The method public void onRepositoryChange(String appId, String namespace, Properties newProperties) is annotated with @Override, but it does not override any method from a superclass or interface. This will lead to a compilation error.

Remove the @Override annotation to fix the compilation error:

-  @Override
   public void onRepositoryChange(String appId, String namespace, Properties newProperties) {

Likely invalid or redundant comment.

71-72: Ensure Upstream Repository Handles appId Appropriately

When setting the upstream repository with the appId, ensure that the upstream repository is also aware of the appId parameter to prevent any inconsistency in configuration fetching.

Run the following script to check if appId is properly used in upstream repositories:

✅ Verification successful

Upstream Repositories Handle appId Appropriately

Verified that all upstream repositories instantiate with the appId parameter correctly, ensuring consistent configuration fetching.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that upstream repositories are instantiated with the correct `appId`.

# Test: Search for instantiations of upstream repositories with `appId`.
# Expect: All upstream repositories should accept `appId` if required.

rg -A 5 'new .*Repository\(.*appId.*\)'

Length of output: 492

Script:

#!/bin/bash
# Description: Verify that upstream repositories are instantiated with the correct `appId`.

# Corrected Test: Search for instantiations of upstream repositories with `appId`.
# Expect: All upstream repositories should accept `appId` if required.

rg -A 5 'new .*Repository\(.*appId.*\)'

Length of output: 1628

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java (3)

53-53: Ensure m_appId is properly initialized

The new member variable m_appId is crucial for multi-app support. Please verify that it is correctly initialized in all constructors to prevent any NullPointerException and ensure consistent behavior across the application.

69-70: Maintain backward compatibility with the default constructor

Using this(null, namespace, configRepository); in the default constructor ensures backward compatibility. Passing null for appId should correctly default to the configured appId. This approach allows existing code to function without modification.

262-262: Verify fireConfigChange handles the appId correctly

Ensure that the fireConfigChange method and its listeners are updated to handle the additional appId parameter properly. This verification is essential to prevent any unexpected behavior during configuration changes.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigRepository.java (5)

77-77: Addition of m_appId field is appropriate

The new field private final String m_appId; will store the appId provided during instantiation, which is necessary for supporting multiple app IDs.

165-165: Updated method call to fireRepositoryChange

The call to this.fireRepositoryChange now includes m_appId as an argument, aligning with the updated method signature to support multiple app IDs.

196-199: Consistent usage of m_appId for configuration

Replaced String appId = m_configUtil.getAppId(); with String appId = this.m_appId; to ensure that the appId provided during instantiation is consistently used throughout the class. Additionally, retrieving the secret using the correct appId ensures that the appropriate access key is used.

343-343: Long polling submission updated with m_appId

The call to remoteConfigLongPollService.submit now passes m_appId as the first parameter. Verify that the RemoteConfigLongPollService class and its submit method have been updated to accept the appId parameter.

Run the following script to confirm that RemoteConfigLongPollService.submit has been updated to accept appId:

#!/bin/bash
# Description: Check the method signature of RemoteConfigLongPollService.submit

# Search for the submit method definition in RemoteConfigLongPollService.
rg 'public\s+void\s+submit\s*\(' -A 5

95-99: Constructor updated to accept appId

The constructor now accepts String appId and assigns it to m_appId. The JavaDoc comment has been updated accordingly. Ensure that all instances where RemoteConfigRepository is instantiated are updated to pass the correct appId.

Run the following script to verify that all instantiations of RemoteConfigRepository include the appId parameter:

✅ Verification successful

All instantiations of RemoteConfigRepository include the appId parameter.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all instantiations of RemoteConfigRepository and check for the appId parameter.

# Search for 'new RemoteConfigRepository' and display the lines where it occurs.
rg 'new\s+RemoteConfigRepository\s*\(' -A 2

Length of output: 133

Script:

#!/bin/bash
# Description: Find all instantiations of RemoteConfigRepository and check for the appId parameter.

# Search for 'new RemoteConfigRepository' and display the lines where it occurs along with their parameters.
rg 'new\s+RemoteConfigRepository\s*\(([^)]*)\)'

Length of output: 1815

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollService.java (14)

43-43: Appropriate Imports for New Data Structures

The imports for HashBasedTable, Table, and Tables are necessary for implementing the new data structures used in the class. Good job on explicitly adding them.

Also applies to: 49-50

60-60: Addition of ConcurrentHashMap Import

Importing ConcurrentHashMap is essential for the thread-safe operations introduced in the code. This import is appropriate and aligns with the concurrent data structures used.

84-86: Use of Thread-Safe Data Structures for Multi-App Support

The introduction of ConcurrentHashMap for m_longPollStarted, Map<String, Multimap<String, RemoteConfigRepository>> for m_longPollNamespaces, and Table<String, String, Long> for m_notifications enhances thread safety and properly supports multi-application configurations.

102-102: Initialization of Thread Pool and Data Structures

Using Executors.newCachedThreadPool improves resource utilization for the long polling service. Initializing m_longPollStarted, m_longPollNamespaces, and m_notifications appropriately sets up the necessary data structures for multi-app support.

Also applies to: 104-106

116-125: Thread-Safe Submission in submit Method

The use of computeIfAbsent for repositoryMultimap in m_longPollNamespaces ensures thread-safe initialization, preventing race conditions when multiple threads submit different namespaces with the same appId. The logic for starting long polling per appId is correctly implemented.

128-129: Concurrency Handling in startLongPolling Method

The check using putIfAbsent on m_longPollStarted effectively prevents multiple threads from starting the long polling for the same appId concurrently. This is a proper way to handle concurrency.

154-154: Cleaning Up m_longPollStarted on Failure

Removing sysAppId from m_longPollStarted in the catch block ensures that if starting the long polling fails, it can be retried in the future. Good practice for handling exceptions.

185-185: Passing Notifications Per Application in URL Assembly

Using m_notifications.row(appId) when assembling the long poll refresh URL correctly limits the notifications to the specified appId, aligning with the multi-app support.

203-203: Updating Methods to Include appId Parameter

Modifying the updateNotifications and notify methods to include appId ensures that notifications are correctly processed per application. This change is consistent with the multi-application architecture.

Also applies to: 206-206

223-223: Enhanced Logging with Application Context

Including appId in logging statements and tracing events provides better context for debugging and monitoring, especially in a multi-application environment.

Also applies to: 227-227

239-246: Null Check in notify Method to Prevent NullPointerException

Adding a null check for namespaceRepositories ensures that the method handles cases where the appId is not present, preventing potential NullPointerException.

251-251: Collecting Repositories to Notify

Gathering the RemoteConfigRepository instances using the appId and namespaceName correctly identifies which repositories need to be notified. Including the .properties suffix accounts for different namespace formats.

Also applies to: 255-256

267-267: Proper Notification Updates in updateNotifications

Updating notifications with the appId key ensures that notification IDs are maintained per application. Checks for the existence of the namespace before updating prevent unintended entries.

Also applies to: 273-274, 279-280

306-311: Null Handling in assembleNamespaces Method

The null check for namespaceRepositories in assembleNamespaces prevents errors when no namespaces exist for an appId, ensuring the method returns an empty string in such cases.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/AbstractConfig.java (3)

Line range hint 457-469: Inclusion of appId enhances multi-application support

The fireConfigChange method now includes the appId parameter, which improves configuration change tracking across different applications. This update aligns with the goal of supporting multiple appIds as specified in the PR objectives.

Line range hint 570-608: calcPropertyChanges method updated with appId parameter

Adding appId to the calcPropertyChanges method ensures that configuration changes are accurately associated with the correct application, enhancing the configurability and traceability of changes.

Line range hint 590-608: ConfigChange instances now include appId for better context

The creation of ConfigChange objects now includes the appId, which provides additional context and aligns with the updates to support multiple application IDs. This change is consistent with modifications in other parts of the codebase.

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/YamlConfigFile.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfigManager.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/SimpleConfig.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/ConfigService.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/LocalFileConfigRepository.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java Show resolved Hide resolved
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/DefaultConfig.java Show resolved Hide resolved
@TerryLam2010
Copy link
Author

Jason, my unit tests pass perfectly when I run them locally, but fail when I run them on GitHub.

nobodyiam
nobodyiam reviewed Oct 26, 2024
View reviewed changes
...ient/src/test/java/com/ctrip/framework/apollo/internals/RemoteConfigLongPollServiceTest.java
@@ -28,11 +28,14 @@
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

import com.ctrip.framework.apollo.build.ApolloInjector;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe these imports are not used.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactoryManager.java Show resolved Hide resolved
nobodyiam
nobodyiam reviewed Oct 26, 2024
View reviewed changes
Copy link
Member

@nobodyiam nobodyiam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran the unit test in my local environment and get the same errors.

[ERROR] Failures: 
[ERROR]   ConfigIntegrationTest.testGetConfigWithLocalFileAndRemoteConfigError:179 expected: <someValue> but was: <anotherValue>
[ERROR]   ConfigIntegrationTest.testGetConfigWithNoLocalFileAndRemoteConfigError:164 expected: <defaultValue0.4766152787709471> but was: <someValue>
[ERROR]   ConfigIntegrationTest.testOrderGetConfigWithLocalFileAndRemoteConfigError:201 expected: <someValue1> but was: <null>
[ERROR]   ConfigServiceTimeoutIntegrationTest.give9NamespaceConfigBackupWhenMeetTimeout:156 expected: <backupNs0.v1> but was: <null>
[ERROR]   ConfigServiceTimeoutIntegrationTest.giveDefaultNamespaceConfigBackupWhenMeetTimeout:96 expected: <v1> but was: <null>
[ERROR]   ConfigServiceTimeoutIntegrationTest.giveTimeoutThenRecover:198 expected: <v1> but was: <null>
[ERROR]   ConfigServiceLocatorTest.giveNoUsableConfigServiceThenThrowExceptionQuickly:84 Expected com.ctrip.framework.apollo.exceptions.ApolloConfigException to be thrown, but nothing was thrown.
[INFO] 
[ERROR] Tests run: 428, Failures: 7, Errors: 0, Skipped: 1

@TerryLam2010
Merge branch 'main' into 20240703-apollo-multiple-appid
cbcd062 
# Conflicts:
#	apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java
coderabbitai[bot]
coderabbitai bot reviewed Nov 6, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (6)
apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (1)

241-245: Consider parameterizing the test cases.

While the test correctly verifies the appId inclusion for both Windows and Unix paths, we can make it more maintainable by:

  1. Using parameterized tests to avoid code duplication
  2. Moving the OS-specific base paths to constants or test configuration
  3. Adding test cases for different appId values

Example refactor:

@ParameterizedTest
@MethodSource("provideOsTestCases")
void testDefaultLocalCacheDir(boolean isWindows, String expectedBasePath, String appId) {
    ConfigUtil configUtil = spy(new ConfigUtil());
    doReturn(appId).when(configUtil).getAppId();
    doReturn(isWindows).when(configUtil).isOSWindows();
    
    String expected = expectedBasePath + appId;
    assertEquals(expected, configUtil.getDefaultLocalCacheDir(appId));
}

private static Stream<Arguments> provideOsTestCases() {
    return Stream.of(
        Arguments.of(true, "C:\\opt\\data\\", "app1"),
        Arguments.of(false, "/opt/data/", "app1"),
        Arguments.of(true, "C:\\opt\\data\\", "app2"),
        Arguments.of(false, "/opt/data/", "app2")
    );
}
apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (5)

89-89: Update log message to include appId for clarity

The debug log currently mentions only the repository type and namespace:

logger.debug("Created a configuration repository of type [{}] for namespace [{}]",
    configRepository.getClass().getName(), namespace);

Consider including appId in the log message to provide more context, especially now that configurations are app-specific.

Apply this diff to enhance the log message:

 logger.debug("Created a configuration repository of type [{}] for namespace [{}]",
-    configRepository.getClass().getName(), namespace);
+    configRepository.getClass().getName(), namespace, appId);

Update the log message format accordingly.

99-100: New createRepositoryConfig method centralizes DefaultConfig creation

Introducing createRepositoryConfig(String appId, String namespace, ConfigRepository configRepository) centralizes the creation of DefaultConfig instances, promoting code reuse and maintainability.

136-147: Update JavaDoc comments to include appId parameter

The JavaDoc for createLocalConfigRepository mentions @param appId but does not explain it. Please provide a description for the appId parameter to improve code documentation.

Apply this diff to update the JavaDoc:

 /**
  * Creates a local repository for a given namespace
  *
+ * @param appId    the application ID of the repository
  * @param namespace the namespace of the repository
  * @return the newly created repository for the given namespace
  */

163-164: Potential issue with trimNamespaceFormat using appId

The method trimNamespaceFormat now includes appId:

String actualNamespaceName = trimNamespaceFormat(appId, namespace, format);

However, in the implementation:

String trimNamespaceFormat(String appId, String namespaceName, ConfigFileFormat format) {
    String extension = "." + format.getValue();
    // ...
}

appId is not used inside trimNamespaceFormat. If appId is not required, consider removing it from the method signature to avoid confusion.

Apply this diff to remove the unused appId parameter:

-String trimNamespaceFormat(String appId, String namespaceName, ConfigFileFormat format) {
+String trimNamespaceFormat(String namespaceName, ConfigFileFormat format) {

And update the method calls accordingly.

183-186: Remove unused appId parameter from trimNamespaceFormat

As appId is not utilized within the method, retaining it may lead to confusion or future maintenance issues.

Confirm if appId is intended to be used. If not, consider removing it as per the previous suggestion.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between f81a266 and cbcd062.

📒 Files selected for processing (3)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (4 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java (2 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/util/ConfigUtil.java
🔇 Additional comments (12)
apollo-client/src/test/java/com/ctrip/framework/apollo/util/ConfigUtilTest.java (2)

228-228: LGTM: Test correctly verifies cache directory path with appId.

The updated test properly verifies that the cache directory path includes the appId when a system property is set.

241-241: Existing feedback about hardcoded paths still applies.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (10)

68-69: Verify appId initialization when calling overloaded create method

The method m_configUtil.getAppId() retrieves the appId used in the overloaded create method. Please ensure that appId is properly initialized and cannot be null to prevent potential NullPointerException issues.

To confirm that appId is always initialized, consider adding a null check or default value in ConfigUtil.getAppId().

71-72: Addition of overloaded create method enhances configurability

The introduction of the overloaded create(String appId, String namespace) method allows for configurations to be specified per appId, aligning with the PR objective to support multiple appIds.

82-83: Ensure correct handling of properties-compatible formats

The condition checks if the format is properties-compatible but not exactly Properties:

if (ConfigFileFormat.isPropertiesCompatible(format) &&
    format != ConfigFileFormat.Properties) {
  configRepository = createPropertiesCompatibleFileConfigRepository(appId, namespace, format);
}

Verify that this logic correctly handles all intended formats and that createPropertiesCompatibleFileConfigRepository properly supports the appId.

Consider adding unit tests to cover different ConfigFileFormat scenarios.

85-85: Consistent use of appId in repository creation

The call to createConfigRepository(appId, namespace) ensures that the appId is consistently passed, improving the configurability across repositories.

91-91: Creation of DefaultConfig with appId supports multi-app scenarios

Returning a DefaultConfig instance initialized with appId aligns with the goal of managing configurations per application.

94-97: Overloaded createConfigFile method enhances file configuration

By overloading createConfigFile to include appId, the configuration files can now be retrieved per application, supporting multiple appIds.

104-105: Consistent appId usage in createConfigFile method

The method correctly passes appId to repository creation, ensuring that configuration files are properly associated with the specified application.

124-130: Adjust repository creation logic for appId inclusion

The createConfigRepository method now accepts appId, and calls to createLocalConfigRepository and createRemoteConfigRepository have been updated accordingly. Verify that all repository types correctly handle the appId.

Ensure that any custom repositories or extensions also accommodate the new appId parameter.

145-147: Handle local mode appropriately with appId

When in local mode, LocalFileConfigRepository is initialized with appId:

return new LocalFileConfigRepository(appId, namespace);

Ensure that the local repository correctly uses appId to locate the appropriate configuration files.

Consider testing the local mode to confirm that configurations are loaded as expected.

158-159: Creation of RemoteConfigRepository with appId

The method createRemoteConfigRepository now includes appId, facilitating remote configuration retrieval per application.

coderabbitai[bot]
coderabbitai bot reviewed Nov 6, 2024
View reviewed changes
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (3)
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepositoryTest.java (1)

167-167: Consider enhancing test coverage for appId scenarios

While the method call has been correctly updated to include the appId parameter, consider adding test cases for:

  1. Verifying the appId is correctly used in the ConfigMap update
  2. Testing error scenarios with invalid appIds

Example test cases to add:

@Test
public void testOnRepositoryChangeWithInvalidAppId() throws ApiException {
    Properties newProperties = new Properties();
    newProperties.setProperty(defaultKey, defaultValue);
    
    // Test with invalid appId
    String invalidAppId = "";
    k8sConfigMapConfigRepository.onRepositoryChange(invalidAppId, someNamespace, newProperties);
    
    // Verify appropriate error handling
    verify(kubernetesManager, never()).updateConfigMap(anyString(), anyString(), anyMap());
}

@Test
public void testOnRepositoryChangeVerifyAppIdUsage() throws ApiException {
    Properties newProperties = new Properties();
    newProperties.setProperty(defaultKey, defaultValue);
    
    k8sConfigMapConfigRepository.onRepositoryChange(someAppId, someNamespace, newProperties);
    
    // Verify appId is correctly used in ConfigMap update
    verify(kubernetesManager).updateConfigMap(
        eq(someAppId), // Verify exact appId is used
        anyString(),
        anyMap()
    );
}
apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (1)

88-89: Consider enhancing debug logging.

The debug log could be more helpful by including the appId:

-    logger.debug("Created a configuration repository of type [{}] for namespace [{}]",
-            configRepository.getClass().getName(), namespace);
+    logger.debug("Created a configuration repository of type [{}] for appId [{}] and namespace [{}]",
+            configRepository.getClass().getName(), appId, namespace);
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepository.java (1)

Line range hint 59-68: Critical: Constructor uses incorrect appId source.

The constructor accepts an appId parameter but uses configUtil.getAppId() when calling setConfigMapName. This could lead to configuration mismatches if the passed appId differs from the one in configUtil.

Apply this fix:

 public K8sConfigMapConfigRepository(String appId, String namespace, ConfigRepository upstream) {
     this.appId = appId;
     this.namespace = namespace;
     configUtil = ApolloInjector.getInstance(ConfigUtil.class);
     kubernetesManager = ApolloInjector.getInstance(KubernetesManager.class);
     k8sNamespace = configUtil.getK8sNamespace();

     this.setConfigMapKey(configUtil.getCluster(), namespace);
-    this.setConfigMapName(configUtil.getAppId(), false);
+    this.setConfigMapName(appId, false);
     this.setUpstreamRepository(upstream);
 }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between cbcd062 and 6d654f5.

📒 Files selected for processing (3)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepository.java (3 hunks)
  • apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (3 hunks)
  • apollo-client/src/test/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepositoryTest.java (2 hunks)
🧰 Additional context used
📓 Learnings (1)
apollo-client/src/main/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepository.java (1) 
Learnt from: nobodyiam
PR: apolloconfig/apollo-java#79
File: apollo-client/src/main/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepository.java:156-162
Timestamp: 2024-10-26T12:49:07.584Z
Learning: In `K8sConfigMapConfigRepository#setUpstreamRepository`, when `upstreamConfigRepository` is `null`, we should return early without setting `upstream` to `null`, so the original upstream remains.
🔇 Additional comments (11)
apollo-client/src/test/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepositoryTest.java (1)

81-81: LGTM: Constructor updated correctly to support multiple appIds

The constructor call has been properly updated to include the appId parameter, maintaining test coverage for the new signature.

apollo-client/src/main/java/com/ctrip/framework/apollo/spi/DefaultConfigFactory.java (7)

68-69: LGTM! Clean backward compatibility implementation.

The delegation to the new overloaded method maintains backward compatibility while supporting multiple app IDs.

94-97: LGTM! Consistent backward compatibility pattern.

The delegation pattern is consistently applied for ConfigFile creation.

99-100: LGTM! Clean parameter propagation.

The method correctly forwards the appId parameter to the DefaultConfig constructor.

124-130: LGTM! Consistent repository creation chain.

The appId parameter is properly propagated through the entire repository creation chain, maintaining the existing repository hierarchy while supporting multiple app IDs.

Also applies to: 140-147, 155-156, 158-159

163-164: Verify ConfigService.getConfigFile implementation.

The code looks good, but we should verify that ConfigService.getConfigFile has been updated to handle the appId parameter correctly.

#!/bin/bash
# Description: Verify ConfigService implementation
# Test: Check if ConfigService has been updated to support appId

echo "Checking ConfigService implementation..."
ast-grep --pattern "class ConfigService {
  $$$
  public static ConfigFile getConfigFile(String appId, String namespace, ConfigFileFormat format) {
    $$$
  }
  $$$
}"

183-183: Question: Is appId parameter necessary?

The trimNamespaceFormat method accepts appId but doesn't use it in its implementation. Consider removing this parameter if it's not needed for the namespace format trimming logic.

#!/bin/bash
# Description: Check if appId is used in other implementations of trimNamespaceFormat
# Test: Search for other implementations that might use appId

echo "Checking for other trimNamespaceFormat implementations..."
rg -p "trimNamespaceFormat.*appId.*namespace.*format"
-  String trimNamespaceFormat(String appId, String namespaceName, ConfigFileFormat format) {
+  String trimNamespaceFormat(String namespaceName, ConfigFileFormat format) {

104-118: LGTM! Verify constructor signatures.

The appId parameter is consistently passed to all config file implementations. Let's verify that all referenced config file classes have been updated to accept appId in their constructors.

✅ Verification successful

All config file implementations correctly updated with appId parameter

Based on the verification results, all config file implementations (PropertiesConfigFile, XmlConfigFile, JsonConfigFile, YamlConfigFile, YmlConfigFile, and TxtConfigFile) have been properly updated to include the appId parameter in their constructors and correctly pass it to their parent classes. Each implementation follows the same pattern of accepting (String appId, String namespace, ConfigRepository configRepository) in their constructors.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all config file implementations have been updated with appId parameter
# Test: Search for constructor definitions in config file classes

echo "Checking config file constructors..."
for class in PropertiesConfigFile XmlConfigFile JsonConfigFile YamlConfigFile YmlConfigFile TxtConfigFile; do
  echo "Checking $class..."
  ast-grep --pattern "class $class {
    $$$
    $class(String appId, String namespace, $_) {
      $$$
    }
    $$$
  }"
done

Length of output: 660

Script:

#!/bin/bash
# Let's try a different approach using ripgrep to find constructor definitions
echo "Checking PropertiesConfigFile constructor..."
rg "PropertiesConfigFile\(String\s+\w+,\s*String\s+\w+,\s*\w+\s+\w+\)" -A 2

echo -e "\nChecking XmlConfigFile constructor..."
rg "XmlConfigFile\(String\s+\w+,\s*String\s+\w+,\s*\w+\s+\w+\)" -A 2

echo -e "\nChecking JsonConfigFile constructor..."
rg "JsonConfigFile\(String\s+\w+,\s*String\s+\w+,\s*\w+\s+\w+\)" -A 2

echo -e "\nChecking YamlConfigFile constructor..."
rg "YamlConfigFile\(String\s+\w+,\s*String\s+\w+,\s*\w+\s+\w+\)" -A 2

echo -e "\nChecking YmlConfigFile constructor..."
rg "YmlConfigFile\(String\s+\w+,\s*String\s+\w+,\s*\w+\s+\w+\)" -A 2

echo -e "\nChecking TxtConfigFile constructor..."
rg "TxtConfigFile\(String\s+\w+,\s*String\s+\w+,\s*\w+\s+\w+\)" -A 2

Length of output: 2701

Script:

#!/bin/bash
# Let's check the remaining config file implementations that weren't found in the previous search
echo "Checking PropertiesConfigFile implementation..."
rg "class PropertiesConfigFile" -A 10

echo -e "\nChecking XmlConfigFile implementation..."
rg "class XmlConfigFile" -A 10

echo -e "\nChecking JsonConfigFile implementation..."
rg "class JsonConfigFile" -A 10

Length of output: 8075

apollo-client/src/main/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepository.java (3)

47-47: LGTM: Appropriate field addition for multi-app support.

The addition of the final appId field aligns with the PR's objective of supporting multiple app IDs and follows good encapsulation practices.

241-241: LGTM: Proper propagation of appId to listeners.

The change correctly propagates the appId to repository change listeners, maintaining consistency with the multi-app support objective.

Line range hint 59-241: Verify impact on monitoring metrics.

As mentioned in the PR discussion, this change might affect monitoring metrics from PR #74. The addition of multiple appId support could require adjustments to metric collection and reporting.

Let's verify the metric collection points:

Consider these architectural recommendations:

  1. Ensure metrics are properly tagged with appId for accurate monitoring
  2. Update dashboards and alerts to handle multi-app scenarios
  3. Document the changes in monitoring behavior for operators
✅ Verification successful

Metrics implementation is sufficient for multi-app support

The current implementation of metrics in K8sConfigMapConfigRepository is consistent with other repositories and properly handles multi-app scenarios:

  1. Transaction metrics already include configMapName which contains the appId (via APOLLO_CONFIG_CACHE + appId format)
  2. Error tracking includes detailed context through ExceptionUtil
  3. The implementation follows the same pattern as RemoteConfigRepository which successfully handles multi-app scenarios

The metrics will naturally segment by app since the configMapName (which includes appId) is added as transaction data in both create and persist operations.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for metric collection points that might need updating
rg -l "Tracer.logEvent|Tracer.logError|Tracer.newTransaction" | grep -v "test"

Length of output: 1554

Script:

#!/bin/bash
# Let's examine the actual metric collection points in K8sConfigMapConfigRepository
rg -A 5 "Tracer\.(logEvent|logError|newTransaction)" apollo-client/src/main/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepository.java

# Let's also check how other repositories handle appId in metrics
rg -A 5 "Tracer\.(logEvent|logError|newTransaction).+appId" --type java

Length of output: 4272

...-client/src/main/java/com/ctrip/framework/apollo/internals/K8sConfigMapConfigRepository.java
Comment on lines +222 to +225
@Override
public void onRepositoryChange(String namespace, Properties newProperties) {

}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Critical: Fix repository change notification handling.

The code has multiple issues with the onRepositoryChange methods:

  1. The empty implementation could silently drop notifications
  2. Having both methods violates the Liskov Substitution Principle
  3. The old method should be marked as deprecated if being replaced

Apply this fix:

-    @Override
-    public void onRepositoryChange(String namespace, Properties newProperties) {
-
-    }

+    /**
+     * @deprecated Use {@link #onRepositoryChange(String, String, Properties)} instead
+     */
+    @Deprecated
+    @Override
+    public void onRepositoryChange(String namespace, Properties newProperties) {
+        onRepositoryChange(this.appId, namespace, newProperties);
+    }

     /**
      * Update the memory
      *
      * @param namespace     the namespace of this repository change
      * @param newProperties the properties after change
      */
     @Override
     public void onRepositoryChange(String appId, String namespace, Properties newProperties) {
         if (newProperties == null || newProperties.equals(configMapProperties)) {
             return;
         }
         Properties newFileProperties = propertiesFactory.getPropertiesInstance();
         newFileProperties.putAll(newProperties);
         updateConfigMapProperties(newFileProperties, upstream.getSourceType());
         this.fireRepositoryChange(appId, namespace, newProperties);
     }

Also applies to: 234-241

@nobodyiam
Copy link
Member

@TerryLam2010 As this pull request is quite large and already takes a lot of time in reviewing. I suggest scheduling an online meeting for a thorough, quick review. If that works for you, please email me at [email protected] to arrange a suitable time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@coderabbitai coderabbitai[bot] coderabbitai[bot] left review comments

@nobodyiam nobodyiam nobodyiam requested changes

Requested changes must be addressed to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@TerryLam2010 @nobodyiam @Anilople @Rawven