feat(webhook-starter): integrate telegrambots-extensions command module with starter#1570
Open
makariyp wants to merge 8 commits intorubenlagus:devfrom
Open
feat(webhook-starter): integrate telegrambots-extensions command module with starter#1570makariyp wants to merge 8 commits intorubenlagus:devfrom
makariyp wants to merge 8 commits intorubenlagus:devfrom
Conversation
…le with starter via annotation-driven registration
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed change
This PR enhances both telegrambots‑springboot‑webhook‑starter and telegrambots‑springboot‑longpolling‑starter by integrating the command module from telegrambots‑extensions. It adds an annotation‑driven mechanism so that Spring‑managed command classes are automatically registered when using either TelegramWebhookCommandBot or CommandLongPollingTelegramBot.
Background
Before these changes, developers had to manually create IBotCommand instances and call register() on the command bot. Neither starter supported auto‑registration, leading to boilerplate and error‑prone code.
Solution
The starters now provide:
• A @command annotation (with command, description and bot attributes) that also acts as a Spring @component. It marks classes as Telegram commands. Annotated classes must implement a simple ICommand interface, which defines a single processMessage(TelegramClient, Message, String[]) method .
• An AnnotationBackedBotCommand adapter that implements IBotCommand by delegating to your ICommand and using the annotation’s metadata for the command identifier and description .
• A CommandRegistrar that implements SmartInitializingSingleton. At startup it scans the Spring context for beans annotated with @command. For each bean it validates that it implements ICommand, locates the appropriate ICommandRegistry by the bot name, wraps the bean in an AnnotationBackedBotCommand, and registers it . If the annotation metadata is missing or the registry doesn’t exist, an exception is thrown to fail fast.
Modifications per module
• Webhook starter:
• Adds an optional dependency on telegrambots‑extensions .
• Updates SpringTelegramWebhookBot to implement TelegramWebhookBot .
• TelegramBotInitializer and TelegramBotStarterConfiguration now work with List and a map of ICommandRegistrys, and they define a CommandRegistrar only when a TelegramWebhookCommandBot bean is present .
• Long‑polling starter:
• Declares the same @command, ICommand, adapter and registrar classes in org.telegram.telegrambots.longpolling.starter.extension.
• Adds telegrambots‑extensions as an optional dependency in its pom.xml .
• TelegramBotStarterConfiguration defines a CommandRegistrar conditional on a CommandLongPollingTelegramBot bean . The registrar logic and validation rules are identical to those in the webhook starter.
Example usage
See the sample project makariyp/telegram‑polling‑bot for a working example. It shows how to create a command‑enabled bot, annotate a StartCommand with @command, and rely on the starter to auto‑register and delegate the command.
Impact
These changes enable concise, Spring‑style command definitions for both webhook and long‑polling bots, removing manual register() calls. The feature is fully backward‑compatible: the new registrar is only created when a command‑enabled bot is present, and the telegrambots‑extensions dependency is marked optional, so projects that don’t use commands remain unaffected.
PS: The annotation, adapter and registrar classes currently reside inside each starter’s extension package. It would be cleaner to extract these common classes into a dedicated module so both starters depend on a single implementation rather than duplicating code. If maintainers agree, I’d be happy to submit a follow‑up PR to perform that refactoring.