EPMRPP-109656 || Events refactoring

[Evelina02]

Summary by CodeRabbit

• Refactor

  • Updated plugin event handling architecture to use modern Spring event listener patterns
  • Simplified JIRA integration workflow by removing legacy event abstractions
  • Improved extensibility of plugin upload event processing

• Chores

  • Updated dependency versions for non-release builds

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The event handling architecture undergoes a migration from a custom EventHandlerFactory pattern to Spring's ApplicationListener framework. PluginEvent handling is replaced with PluginUploadedEvent, StartLaunchEvent listeners are removed, and the extension's event listener initialization is refactored accordingly.

Changes

Cohort / File(s)	Summary
Gradle Dependency Update build.gradle	Service-API artifact version updated from 3e34a90 to a47f5cf in non-release build path.
Event Handler Architecture Removal src/main/java/com/epam/reportportal/extension/jira/event/EventHandlerFactory.java, src/main/java/com/epam/reportportal/extension/jira/event/handler/EventHandler.java, src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginEventHandlerFactory.java, src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginEventListener.java	Removed generic EventHandler interface, EventHandlerFactory abstraction, PluginEventHandlerFactory implementation, and PluginEventListener class as part of migration away from custom factory pattern.
Listener Removal src/main/java/com/epam/reportportal/extension/jira/event/launch/StartLaunchEventListener.java	Removed StartLaunchEvent listener; StartLaunchEvent handling flow is eliminated.
Event Listener Refactoring src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginLoadedEventListener.java	Refactored from PluginLoadedEventHandler to PluginLoadedEventListener implementing Spring's ApplicationListener; added pluginId field and supports() guard; changed event processing to derive plugin name from PluginActivityResource.
Extension Configuration Update src/main/java/com/epam/reportportal/extension/jira/CloudJiraExtension.java	Updated pluginLoadedListenerSupplier to wire PluginUploadedEvent and new PluginLoadedEventListener; removed LaunchRepository autowiring and startLaunchEventListenerSupplier; updated listener initialization with integrationRepository and integrationTypeRepository dependencies.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

• High heterogeneity: Involves file removals, class refactoring, interface deletion, and dependency wiring changes across 8 files with distinct reasoning paths
• Architectural pattern shift: Migration from custom EventHandlerFactory pattern to Spring ApplicationListener requires understanding both the old and new paradigms
• Public API surface changes: Multiple public types removed and listener signature altered (PluginEvent → PluginUploadedEvent, EventHandler interface removed)
• Dependency graph changes: LaunchRepository removed, new integrationRepository added to listener initialization
• Extra attention areas:
  • Verify all references to removed EventHandlerFactory and EventHandler interfaces are eliminated throughout the codebase (may have wider impact beyond this diff)
  • Confirm PluginUploadedEvent provides all necessary information previously supplied by PluginEvent
  • Review the plugin name extraction logic change in PluginLoadedEventListener (from event.getPluginId() to event.getPluginActivityResource().getName())
  • Validate that removal of StartLaunchEvent handling does not leave orphaned event dispatch or listener registration code

Poem

🐰 Old factories fade, new listeners bloom,
Spring's gentle guidance fills the room,
PluginUploaded arrives with grace,
StartLaunch bids its last farewell race,
Refactored paths now spring aligned,
A cleaner event flow, carefully designed! 🌿

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'EPMRPP-109656 || Events refactoring' accurately reflects the main objective of this pull request, which involves refactoring event handling mechanisms and removing legacy event-related interfaces and classes.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch EPMRPP-109656-events-refactoring

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginLoadedEventListener.java (2)

54-68: Minor: redundant event value extraction.

After supports() validates the event, eventPluginId will always equal pluginId. You could use pluginId directly.

🔎 Suggested simplification

   @Override
   public void onApplicationEvent(PluginUploadedEvent event) {
     if (!supports(event)) {
       return;
     }
 
-    String eventPluginId = event.getPluginActivityResource().getName();
-    integrationTypeRepository.findByName(eventPluginId).ifPresent(integrationType -> {
-      createIntegration(eventPluginId, integrationType);
+    integrationTypeRepository.findByName(pluginId).ifPresent(integrationType -> {
+      createIntegration(pluginId, integrationType);
       integrationTypeRepository.save(pluginInfoProvider.provide(integrationType));
     });
   }

---

70-82: Consider: potential race condition in integration creation.

The check-then-act pattern (findAllGlobalByType → save) could create duplicate integrations if called concurrently. This is likely low-risk since plugin uploads are typically single-threaded admin operations, but worth noting if this could ever be invoked in parallel.

If needed, a database unique constraint or @Transactional with appropriate isolation could prevent duplicates.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b07df4b and faef271.

📒 Files selected for processing (8)

• build.gradle (1 hunks)
• src/main/java/com/epam/reportportal/extension/jira/CloudJiraExtension.java (4 hunks)
• src/main/java/com/epam/reportportal/extension/jira/event/EventHandlerFactory.java (0 hunks)
• src/main/java/com/epam/reportportal/extension/jira/event/handler/EventHandler.java (0 hunks)
• src/main/java/com/epam/reportportal/extension/jira/event/launch/StartLaunchEventListener.java (0 hunks)
• src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginEventHandlerFactory.java (0 hunks)
• src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginEventListener.java (0 hunks)
• src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginLoadedEventListener.java (2 hunks)

💤 Files with no reviewable changes (5)

• src/main/java/com/epam/reportportal/extension/jira/event/handler/EventHandler.java
• src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginEventListener.java
• src/main/java/com/epam/reportportal/extension/jira/event/launch/StartLaunchEventListener.java
• src/main/java/com/epam/reportportal/extension/jira/event/EventHandlerFactory.java
• src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginEventHandlerFactory.java

🧰 Additional context used

🧬 Code graph analysis (1)

src/main/java/com/epam/reportportal/extension/jira/CloudJiraExtension.java (1)

src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginLoadedEventListener.java (1)

• PluginLoadedEventListener (36-83)

🔇 Additional comments (5)

build.gradle (1)

39-40: Service-api version uses valid JitPack commit hash format.

The dependency version update aligns with the PR's event refactoring objectives. The commit hash a47f5cf is a valid JitPack version identifier for development/snapshot builds. However, verification that this specific commit contains the necessary event framework changes (PluginUploadedEvent and Spring ApplicationListener support) requires direct access to the repository's commit history, which cannot be confirmed through public sources alone.

src/main/java/com/epam/reportportal/extension/jira/CloudJiraExtension.java (3)

25-25: LGTM!

Import updates align correctly with the migration from PluginEvent to PluginUploadedEvent and the new PluginLoadedEventListener class.

Also applies to: 36-36

---

97-97: LGTM!

The refactoring from the factory pattern to direct PluginLoadedEventListener instantiation simplifies the code. The MemoizingSupplier correctly defers initialization until @PostConstruct, ensuring @Autowired fields are populated before the lambda executes.

Also applies to: 138-141

---

191-210: LGTM!

Clean listener lifecycle management - properly registers in @PostConstruct and unregisters in DisposableBean.destroy(). The removal of StartLaunchEvent listener handling simplifies the event architecture.

src/main/java/com/epam/reportportal/extension/jira/event/plugin/PluginLoadedEventListener.java (1)

36-51: LGTM!

Clean implementation of ApplicationListener<PluginUploadedEvent>. The constructor properly initializes all required dependencies for handling plugin upload events.