mirror of
https://github.com/eclipse-sailing-analytics/sailing-analytics.git
synced 2026-11-02 01:00:46 +00:00
Axel Uhl
43279c843a
Previously the polars bundle registered its PolarDataService in the OSGi registry immediately at bundle start, then unregistered/re-registered around a remote regression-data fetch in a background thread. The unregister transiently nulled RacingEventServiceImpl.polarDataService, opening a window in which PolarFixCacheUpdater.statusChanged would skip its raceFinishedLoading call for any race transitioning past LOADING during that window, and in which restoreTrackedRaces()'s call to markLoadingOfAllRacesToRestoreStarted() would silently drop. Reversed the dependency: the polars Activator now opens a ServiceTracker for RacingEventService, obtains its DomainFactory, constructs the PolarDataServiceImpl, populates it (registerDomainFactory, then remote fetch if configured), and only then registers the service in the OSGi registry -- exactly once. The OSGi contract now holds: if the service is registered, it is ready. Also dropped the !maneuverCache.canBeUpdated() gate on TrackedRaceImpl.feedAlreadyKnownManeuversToWindEstimation, so that compute-path races whose maneuver detector captured a null WindEstimationInteraction at detection time (because the estimator hadn't been installed yet) still get their detected maneuvers fed to the estimator when it arrives. Manifest change: com.sap.sailing.polars now Require-Bundles com.sap.sailing.server.interface directly, in order to reference the RacingEventService type from the Activator's ServiceTracker.