Details
-
Bug
-
Status: Open
-
Resolution: Unresolved
-
7.2.10 DXP FP16
-
None
-
None
Description
Under some very specific circumstances, the following component
may activate after the Liferay-Service tagged bundles start.
The consequence is that the BundleTracker is not going to catch the startup of those bundles and those Liferay services will miss their Configuration registration which happens here:
The consequence of those missing Configurations is that ds:unsatisfied gogo shell command will reveal that a lot of references are unsatisfied. And many things will not work properly in the portal.
What I've done in the project where the issue has occurred has been to implement this additional @Component:
Most of the code comes from ServiceConfigurationExtender. All I've done is to parse all the OSGi bundles and check whether some of the Liferay-Service tagged ones did not register their configuration. In which case, I do the registration.
I have put this:
@Reference(target = ModuleServiceLifecycle.PORTAL_INITIALIZED)
private ModuleServiceLifecycle _moduleServiceLifecycle;
so that this component activates at the end of Portal initialization.
Ways to reproduce:
It's not easy to reproduce the conditions that lead to this issue. However, what you can do is blacklist the following @Component :
com.liferay.portal.spring.extender.internal.configuration.ServiceConfigurationExtender
And restart Liferay with an osgi/state cleanup.
Then, once Liferay has restarted, remove the component from the blacklist and run ds:unsatisfied in the Gogo shell. You should have a bunch of unsatisfied references.
How to fix:
My proposed ServiceExtenderFix could be added to https://github.com/liferay/liferay-portal/tree/7.2.x/modules/apps/portal/portal-spring-extender-impl/src/main/java/com/liferay/portal/spring/extender/internal/configuration while mutualizing all the code in common with ServiceConfigurationExtender but there are probably a lot of potential approaches.
The important thing is that there is nothing preventing ServiceConfigurationExtender from starting too late in the current architecture. Thus, we either need to enforce intended startup sequence or include some compensation strategy as I proposed.