Skip to content

feat(webhook-starter): integrate telegrambots-extensions command module with starter#1570

Open
makariyp wants to merge 8 commits intorubenlagus:devfrom
makariyp:feature/spring_starters_extensions
Open

feat(webhook-starter): integrate telegrambots-extensions command module with starter#1570
makariyp wants to merge 8 commits intorubenlagus:devfrom
makariyp:feature/spring_starters_extensions

Conversation

@makariyp
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants