Type: Technical Task
Affects Version/s: None
Fix Version/s: 7.0.0 M1
The root cause was this line:
This line is effectively trying to make a bean declared at util-spring.xml (MBCommentManager) use another bean declared at portal-spring.xml (MBMessageLocalService).
This is not allowed, as it results in a module-level circular dependency between util-spring and portal-spring. It's usual and valid for beans in portal-spring to inject beans from util-spring, but the other way around has never been done before and is not valid.
The broken Selenium tests make this much more evident. When applying the Spring wiring, Liferay's BaseTestCase restricts itself to only two Spring configuration files:
It doesn't include portal-spring.xml, therefore MBMessageLocalService isn't present, hence the bug. Which makes sense, as Selenium tests are black-box client tests running against an external Portal and wouldn't be expected to invoke local services.
This bug can be solved, and the Comments API become more modular, by moving all Comments-related bean declarations from util-spring.xml to a Spring configuration file of their own (comment-spring.xml). This is a well-established trend for several modules like workflow-spring.xml and mobile-device-spring.xml; gets Spring wiring working for functional tests, integration tests and the runtime Portal; and eliminates the need for any changes at Java source code level. (Reverting the modifications made for
LPS-48168 to pass and returning the Java code back to its original state from LPS-46460.)
As a bonus, we introduce a test (InitUtilTest) to do exactly the same as the Selenium base test class (com.liferay.portalweb.portal.BaseTestCase), but at the integration test level: run the Spring wiring with the same reduced set of configurations (management-spring.xml, util-spring.xml) that will be later used by the Selenium functional tests.
Now a programmer that changes util-spring.xml in an invalid way will see this test break when running the Portal integration tests from the command line or local Jenkins, and have a chance to fix the problem before sending a pull request. This will prevent QA functional tests from breaking for the same reason in the future.