Hi Leonardo,
thanks for explaining the SPI. But for me it is not yet clear. In JAVASERVERFACES_SPEC_PUBLIC-1338 there is the following text:
The pseudo code won't find resources in contracts in jars, because the web app resource loader tries to find the resource without a contract before the classpath resource loader tries. The web app resource loader usually finds the resource without a contract. So the way it iterates should change to iterate per contract over both resource loaders.
Does this work in MyFaces?
Ciao Frank
> Am 03.02.2015 um 22:50 schrieb Leonardo Uribe <leonardo.uribe_at_irian.at>:
>
> Hi
>
> FC>>Can you please take a look at it and clarify how MyFaces handles
> contracts in jars?
>
> Resource library contracts follows "locale" rules, in the same way as
> normal resources. First there is the contract name and then the
> resource identifier with the localePrefix, libraryName, resourceName
> and so on. There is no special handling for jar files, but MyFaces
> have an special SPI to locate resource library contracts
> (ResourceLibraryContractsProvider) with two methods:
>
> public abstract Set<String> getExternalContextResourceLibraryContracts(
> ExternalContext context) throws IOException;
>
> public abstract Set<String> getClassloaderResourceLibraryContracts(
> ExternalContext context) throws IOException;
>
> The policy in MyFaces is: if there is something in JSF that needs to
> scan the classpath, provide an SPI interface, so server vendors can
> customize that detail. That provides better flexibility, specially
> with containers like OSGi, where the jar files are "bundles" and there
> is an special API for this. Most of the time the default code works
> just fine.
>
> There is a param called
> org.apache.myfaces.TEMPORAL_RESOURCEHANDLER_CACHE_ENABLED that uses a
> temporal folder and avoid open the jar each time a resource is needed
> and a top level cache to speed up resource location.
>
> regards,
>
> Leonardo
>
> 2015-02-03 5:51 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>> Hi,
>>
>> On Tue, Feb 3, 2015 at 10:40 AM, Frank Caputo <frank_at_frankcaputo.de> wrote:
>>> I think, we can resolve the PENDINGs for 2.3 (most of them should be obsolete). This was my first bigger contribution to Mojarra, so I was a little bit insecure, if this is all correct.
>>
>> Great, that should help. I know your feeling. I'm currently looking
>> into adding the /views folder; a folder from which (top level) views
>> can be loaded, and I too am a bit insecure about that (even though I
>> effectively implemented it already in OmniFaces). With all the PENDING
>> comments I was even less sure of where to put what.
>>
>> I'll start a separate discussion about this views folder on this list.
>>
>> Kind regards,
>> Arjan
>>
>>
>>>
>>> Ciao Frank
>>>
>>>> Am 02.02.2015 um 20:17 schrieb arjan tijms <arjan.tijms_at_gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> While reading up on resource handling in the Mojarra source code, I
>>>> noticed there were quite a few PENDING markers there.
>>>>
>>>> E.g.
>>>>
>>>>
>>>> com.sun.faces.facelets.impl.DefaultFaceletFactory.needsToBeRefreshed(URL)
>>>>
>>>> // PENDING(FCAPUTO) not sure, if this is what we want.
>>>> for (FaceletCache<DefaultFacelet> faceletCache :
>>>> cachePerContract.values()) {
>>>>
>>>>
>>>> com.sun.faces.facelets.impl.DefaultFaceletFactory.getCache(FacesContext)
>>>>
>>>> // PENDING(FCAPUTO) we don't support
>>>> com.sun.faces.config.WebConfiguration.WebContextInitParameter#FaceletCache
>>>> for contracts
>>>> faceletCache = initCache(null);
>>>>
>>>>
>>>> com.sun.faces.facelets.impl.DefaultFaceletFactory.resolveURL(String)
>>>>
>>>> // PENDING(FCAPUTO) Deactivated caching for resource library
>>>> contracts. If we still want to cache it, we need a cache per contract
>>>> libraries list.
>>>> // But the ResourceHandler caches on his own (using
>>>> ResourceManager).
>>>> URL url = this.resolveURL(this.baseUrl, uri);
>>>>
>>>>
>>>> com.sun.faces.facelets.impl.DefaultFaceletFactory._createComponent(FacesContext,
>>>> String, String, Map<String, Object>)
>>>>
>>>> // PENDING(FCAPUTO) does this work for resource library contracts? I think so.
>>>> UIComponent result = null;
>>>> Application app = context.getApplication();
>>>>
>>>>
>>>> com.sun.faces.application.resource.ResourceHandlerImpl.libraryExists(String)
>>>>
>>>> // PENDING(fcaputo) do we need to iterate over the contracts here? I
>>>> don't think so.
>>>> LibraryInfo info = manager.findLibrary(libraryName, null,
>>>> null, context);
>>>>
>>>> com.sun.faces.application.resource.ResourceHelper.getInputStream(ResourceInfo,
>>>> FacesContext)
>>>>
>>>> // PENDING(edburns): this is a sub-optimal implementation choice
>>>> // done in the interest of prototyping. It's never a good idea
>>>> // to do a switch statement based on the type of an object.
>>>>
>>>> InputStream in = null;
>>>>
>>>>
>>>> com.sun.faces.application.resource.ResourceManager.findResource(String)
>>>>
>>>> // PENDING(fcaputo) do we need to handle contracts here?
>>>> String libraryName = null;
>>>> String resourceName = null;
>>>>
>>>>
>>>> I wonder if there should be a kind of theme in JSF 2.3 to resolve
>>>> those pending issues, especially where it concerns the contracts /
>>>> resource handling?
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>
>