ClasspathResourceOrigin suffers from several problems which are very hard to overcome without significant modifications of current implementation. The list of topics which needs attention includes:

• development time resource reloading,
• retrieval of classpath resource contents,
• classpath configuration flexibility,
• classpath file/folder hierarchy maintenance
• etc.

Main issue as it appears is related to how classpath resources are retrieved at the moment. We heavily rely on the context ClassLoader to provide resource URLs, last modified dates and InputStreams. While such an approach works well for the case of production mode (i.e. classloader doesn't do and never needs to do any reloading), in dev mode when we can deliberately update, remove or add a resource - class loader may or may not be able to resolve it (similar how IDE's support class reloading - a new/deleted/modified class support is there, but limited and somewhat unreliable => such tools as JRebel exist and bloom).

Attempt to obtain via classloader a URL or contents of the resource which e.g. has been detected as a new by Reflections library (which looks into re-deployed jar files and doesn't rely on classloader itself) may lead to all sorts of IO/Runtime exceptions. The idea which could help in such case is to obviously stop unconditionally relying on the classloader but rather maintain the ability to point the classpath resources directly into the deployed jars and should file stream be needed - refer to jar file itself.

Hereby it is proposed to take the following actions to improve the situation with the classpath resources support:

• use dedicated ClasspathEntry objects for resource identification instead of mere Strings - encapsulate path operations, provide simple hierarchy-related interface, distinguish between folder and file, provide transparent stream API.
• aggregate all related classpath-related parameters in a simple component (jar URLs, resource predicates, monitored resource pattern, default charset etc)
• revise the purpose, naming and role of ClasspathScannerService - each time after scanning it has info about current resources and yet we have to maintain a copy of resource cache in ClasspathResourceOrigin manually. It is proposed to introduce ClasspathService which would be a centralised access point of classpath entry hierarchy, origin itself would be just a consumer of such service.
• introduce a alternative (light!) version of such service for production mode - essentially no monitoring, less overhead, ful relying on context classloader.
• the solution has to be tested against cases of excessive data served via classpath (hundreds/thousands of resources)
• solution has to be tested against most common app servers and at least in IntelliJ and Eclipse