wrt requirements of root resource or provider/feature classes

I believe my issue is somehow related to issue #3700 (Registering resources in ResourceConfig leads to warnings). I have been using a class that extends javax.ws.rs.core.Application, and I have been trying to override the getSingletons/0 method. This results in the warning:

Aug 18, 2019 8:03:43 PM org.glassfish.jersey.internal.inject.Providers checkProviderRuntime
WARNING: A provider ...rest.sample.resources.EmployeeResource registered in SERVER runtime does not implement any provider interfaces applicable in the SERVER runtime. Due to constraint configuration problems the provider ...rest.sample.resources.EmployeeResource will be ignored.

However this same EmployeeResource class works as expected when loaded via getClasses/0 instead. Therefore this class _does_ conform to the requirements of root resource or provider/feature classes.

Thus in my experience the Jersey implementation indicates that my class does (success via getClasses/0) and does not (failure via getSingletons/) conform to the requirements of root resource or provider/feature classes.

1. The Oracle javax.ws.rs.core.Application documentation for getSingletons/0 and getClasses/0 does not indicate that singletons and classes should be treated differently by the developer wrt to being conformant to requirements, and
2. the Oracle javax.ws.rs.core.Application documentation does not lead the developer to expect that "Jersey supports (two) 2 ways of components registration" as described by senivam on 22 Aug 2018. Actually developers should not have to care about two internal ways of component registration.

The two different Jersey treatments indicate that Jersey treats the same requirements in two different ways, which of itself means that the Jersey implementation is buggy from a documentation perspective. Moreover the warning message above is misleading, since the issue has nothing to do with "requirements of root resource or provider/feature classes", but rather with the inconsistent two-way Jersey implementation itself, and this should be noted!

What could be a work-around?