I have created a Github pull request of a minor patch that will improve usage of the RESTEasy Guice plugin.

One of the hook methods provided for users wishing to use an overridden instance of GuiceResteasyBootstrapServletContextListener is List<Module> getModules(). Overriding this method allows the user to specify a customized list of Guice modules to use in the RESTEasy application. I have instead changed the return type of this method to List<? extends Module> and have also updated variables inside of this class as necessary.

Allowing the usage of Java wildcards will provide RESTEasy Guice users with further flexibility when creating the list of Modules to be returned by getModules(). For instance, suppose that the user wanted to use Arrays.asList() to return a list of multiple modules in a quick-and-easy one-liner of code. It is likely that the concrete types of each Module in the list will not be the same and, since Module itself is an interface, we can't have constructors of our own Module classes be of the Module type. Therefore, unless the module instances were created in previous lines of code, Arrays.asList() cannot return an instance of List<Module>. However, since all these Module instances implement (in the context of a wildcard statement, "extends") Module, Arrays.asList() is able to return a type of List<? extends Module>.

Besides, if one were to look at the JavaDoc for Guice classes such as Guice and the Injector, one can observe that methods expecting an Iterable of Modules uses the type parameter of <? extends Module> already. Perhaps the Guice developers too saw the benefits of allowing a wildcard list of Modules.

The code that I have changed does not change the core functionality of the RESTEasy-Guice plugin, as I only changed the types of one global variable and one method. Rather, this will create a small breaking change for users of RESTEasy-Guice that override getModules() once this change is integrated into the project and released to the public. The only thing that developers will need to do to upgrade is to change the return type of getModules() in their code from List<Module> to List<? extends Module>. However, if we do not want to cause this minor breaking change, then we can perhaps mark the existing version of the method in GuiceResteasyBootstrapServletContextListener as @Deprecated and introduce an entirely brand new method that could be overridden.

Also in my pull request is the associated documentation change.