# Core: @OpenmrsProfile to filter for modules that are absent

**URL:** <https://talk.openmrs.org/t/core-openmrsprofile-to-filter-for-modules-that-are-absent/13099>\
**Category:** Development\
**Tags:** spring, core\
**Created:** [August 28, 2017, 1:31pm UTC](https://talk.openmrs.org/t/core-openmrsprofile-to-filter-for-modules-that-are-absent/13099 "2017-08-28T13:31:06Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\
**Post date:** [August 28, 2017, 2:36pm UTC](https://talk.openmrs.org/t/core-openmrsprofile-to-filter-for-modules-that-are-absent/13099/3 "2017-08-28T14:36:52Z")

</div>

Yes it is a consequence of attempting a full leverage of the ‘aware of’ config directive. When doing so one might not so much be interested in filtering for ranges of versions of a module, but rather to know whether a module is present (with any version) or missing.

* * *

Our specific use case is about AH’s awareness of Ext I18N.

- If Ext I18N is present it should provide an implementation to one of AH’s interfaces. `@OpenmrsProfile(modules = {"exti18n:*"})`

- If Ext I18N is absent then AH itself should provide a default implementation to its interface. `@OpenmrsProfile(modules = {"exti18n:_"})`

The above config could be put in place, with `@Autowired`-annotated instances of AH’s interface, that would work both at runtime and within context-sensitive tests. See also ‘[Core: enabling context-sensitive tests to start modules](https://talk.openmrs.org/t/core-enabling-context-sensitive-tests-to-start-modules/13098)’.

Cc @mogoodrich

---

_[View the full topic](https://talk.openmrs.org/t/core-openmrsprofile-to-filter-for-modules-that-are-absent/13099)._