[ https://issues.apache.org/jira/browse/MYFACES-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811368#comment-13811368 ]
Leonardo Uribe commented on MYFACES-3814: ----------------------------------------- I changed the name of the issue, because put that information in FacesConfig does not work very well. The reason is SPI lookup needs to be setup before config code. The idea is add two methods: public Map<String, List<String>> calculateKnownServiceProviderMapInfo(ExternalContext ectx, String[] knownServices) public void initKnownServiceProviderMapInfo(ExternalContext ectx, Map<String, List<String>> map) At startup, MyFaces calls calculateKnownServiceProviderMapInfo and provide the list of known services used by ServiceProviderFinder. By default it returns null, but the idea is custom implementations can provide the logic that scan the classpath and find the configuration. If the configuration has been serialized somewhere the idea is put there the code that restore that information. Then MyFaces will call initKnownServiceProviderMapInfo and it will pass the map, so the default implementation can grab the map and use it into its logic. > Allow ServiceProviderFinder to be initialized at startup > -------------------------------------------------------- > > Key: MYFACES-3814 > URL: https://issues.apache.org/jira/browse/MYFACES-3814 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 > Reporter: Leonardo Uribe > Assignee: Leonardo Uribe > > The code inside ServiceProviderFinder usually involves classpath scanning and > read files from different locations. That code is ok, but it would be great > if we can put that into FacesConfig as a configuration information. > The idea is just list all SPI interfaces we are using in MyFaces Core, and do > the scanning of everything we need right at startup and finally store that > information into FacesConfig, just like it was done for Facelet tag lib > configuration. > If FacesConfig is serialized and deserialized, that scanning will not be > necessary and the startup will be faster. -- This message was sent by Atlassian JIRA (v6.1#6144)