[MAGNOLIA-5170] LegacyComponentsConfigurer can't work (in tests) when modules declare components in <properties> Created: 09/Jul/13  Updated: 07/Aug/13  Resolved: 10/Jul/13

Status: Closed
Project: Magnolia
Component/s: testing
Affects Version/s: None
Fix Version/s: 5.0.2, 5.1

Type: Bug Priority: Neutral
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
supersession
is superseded by MAGNOLIA-5173 Deprecate/rewrite MgnlTestCase and su... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

info.magnolia.objectfactory.configuration.LegacyComponentsConfigurer#addComponent registers a component twice - as a component, and as a type mapping.
Consequently, info.magnolia.test.mock.AbstractComponentProvider#configure calls registerImplementation twice (one from the loop of configuration.getComponents() and once from the loop of configuration.getTypeMapping()). The second call fails.

I experienced this while testing a ModuleVersionHandler, where the imaging module was involved (at the time of writing, the imaging module still has a component declared in <properties>.

Workarounds:

  • Remove the <property> (replace it by the appropriate <component> or <type-mapping>)
  • Add ComponentsTestUtil.setImplementation(SystemContext.class, MockContext.class); in the test's setUp (no idea why this "works")

Some more "interesting" observations that may or may not be related, but are probably due to other bugs in MgnlTestCase, RepositoryTestCase etc:

  • In my test, only the 2nd test method would fail, from the setUp, due to the imaging component being registered twice. Consequently, the tearDown would also fail, claiming a SystemContext impl isn't registered (which is what led me to the 2nd workaround)
  • When adding the following in my test class, both test methods would fail the same way, which leads me to believe there are other bugs in the setup/teardown of our abstract test classes.
        @Override
        @Before
        public void setUp() throws Exception {
            SystemProperty.clear();
            ComponentsTestUtil.clear();
            super.setUp();
        }
    


 Comments   
Comment by Magnolia International [ 10/Jul/13 ]

Committed a fix in AbstractComponentProvider which prevents the double-registration. Further improvements/fixes to the test framework could be helpful, but will be tackled with MAGNOLIA-5170

Comment by Federico Grilli [ 29/Jul/13 ]

If I understand correctly, now that this issue is fixed the workaround at JbpmWorkflowModuleVersionHandlerTest.java can be removed.

Comment by Magnolia International [ 29/Jul/13 ]

Indeed - workaround now removed. Cheers.

Generated at Mon Feb 12 04:02:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.