Skip to content

Failing test for ModuleOrdering that skips the extra test module(s) #760

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jan 13, 2025

Conversation

rbygrave
Copy link
Contributor

Test components in src/test that are not annotated with @TestScope go into an extra module. This module is ignored/skipped by the compiled module ordering.

A fix for this is desired.

Test components in src/test that are not annotated with @TestScope go into an extra module. This module is ignored/skipped by the compiled module ordering.

A fix for this is desired.
@rbygrave
Copy link
Contributor Author

The complied ModuleOrdering contains:

  @Override
  public void add(AvajeModule module) {
    final var index = INDEXES.get(module.getClass().getTypeName());
    if (index != null) {
      sortedModules[index] = module;
    }
  }

... so modules that are not known are effectively lost.

…module ordering when ...

When it supports the modules that are being used. When it does not then fall back to the default ordering mechanism.
@rbygrave rbygrave self-assigned this Jan 13, 2025
@rbygrave rbygrave requested a review from SentryMan January 13, 2025 03:08
@rbygrave
Copy link
Contributor Author

rbygrave commented Jan 13, 2025

The fix here adds a supportsExpected method to ModuleOrdering like:

public interface ModuleOrdering extends InjectExtension {

   /**
    * Return true if ordering supports the modules passed in.
    */
   default boolean supportsExpected(List<AvajeModule> modules) {
     return true;
   }
...

.. and changes the generated code to implement this with a check that the modules passed are the ones it expects to order.

  @Override
  public boolean supportsExpected(List<AvajeModule> modules) {
    if (modules.size() != sortedModules.length) {
      return false;
    }
    return modules.stream()
            .map(m -> m.getClass().getTypeName())
            .allMatch(k -> INDEXES.containsKey(k));
  }

Copy link
Collaborator

@SentryMan SentryMan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but the Compiled Ordering generation is an opt-in feature that's disabled by default, so I doubt this solves the actual issue that prompted this PR

@SentryMan
Copy link
Collaborator

Wait, actually this might work

@rbygrave
Copy link
Contributor Author

Compiled Ordering generation is an opt-in feature that's disabled by default, so I doubt this solves the actual issue that prompted this PR

Yes indeed - maybe there is another issue. I headed this way because it should have worked and I was able to reproduce the error this way. Hmm.

I'll include a test that wires a BeanScope in postConstruct(). Let me know if you are still happy with this perhaps.

Copy link
Collaborator

@SentryMan SentryMan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests also pass when I disable the strict wiring so I'm fine with this, let's publish an RC and see if we get some feedback

@rbygrave rbygrave merged commit f9baeb0 into master Jan 13, 2025
13 checks passed
@rbygrave rbygrave deleted the failingtest/test-components branch January 13, 2025 04:10
@SentryMan SentryMan added this to the 11.2 milestone Jan 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants