ClassLoader.getResources vs Module.getResourceAsStream

Michał Zegan webczat_200 at poczta.onet.pl
Mon Jul 16 18:49:49 UTC 2018


Well, these are not stateless factories that you register as a service
and then discover to later use them to create some objects.
Those are factories that implement a specific algorithm like crypto
algorithm, or that are adapters for a crypto library like for JCA, in
the second case one factory class can be used to create many factories
for many algorithms depending on properties set on them.
Concrete algo instances are created when needed by connection objects.
That is why I cannot register them as some kind of services, i need
configuration to be able to define what algorithms are supported using
what factory class with what configuration for each algorithm, and this
would be ugly to do in code. And I would actually like for this
mechanism to also load some extensions, like secondary files in other
jars/modules that may register other algorithms that are not registered
by core, using builtin or extension factory classes.
I currently want to put that in META-INF that seems to be non-encapsulated.
W dniu 16.07.2018 o 08:52, Sander Mak pisze:
> In that case you'd expose the factories through the services mechanism (`provides com.acme.api.MyWidgetFactory with com.acme.factories.XmlBasedWidgetFactory` in the module descriptor). Or, if you must expose the XML itself to the outside world rather than the factories, you can create a service that offers the XML as String or InputStream. Each module then has an implementation reading its own encapsulated XML. The former approach is preferable IMO.
> 
> Note that you can also use the services mechanism without module descriptors by placing text files in META-INF/services (https://docs.oracle.com/javase/tutorial/ext/basics/spi.html). However, if your code isn't a reusable library itself, you can also choose to modularize your own code and depend on non-modularized dependencies through their automatic module name (http://branchandbound.net/blog/java/2017/12/automatic-module-name/).
> 
> Sander
> 
> On 14 Jul 2018, at 17:58, Michał Zegan <webczat_200 at poczta.onet.pl<mailto:webczat_200 at poczta.onet.pl>> wrote:
> 
> It is a completely new code. It is not modularized for now because some
> dependencies are not modularized, but I want it to be compatible to ease
> later modularization.
> My actual goal is to load xml files defining and configuring some
> factories, from all modules that contain them. Not sure how would you do
> that with services?
> 
> W dniu 14.07.2018 o 17:53, Alan Bateman pisze:
> On 14/07/2018 16:38, Michał Zegan wrote:
> What is then a recommendation for searching for all resources with name
> x that i can access? Something like load all configuration including
> some kind of extensions. I cannot list resources easily.
> 
> Services is the cleaner way to do this kind of thing, esp. if you have
> flexibility to change the code and move away from legacy ClassLoader
> getResources.
> 
> -Alan
> 
> 



More information about the jigsaw-dev mailing list