Hi Frank
Resources stored in a resource library contract has precedence over
everything. In other words, a resource library contract has the
ability to override any resource. In MyFaces code there are two kind
of loaders : ContractResourceLoader and ResourceLoader. Both are
similar, inclusive has some duplicated code, but both follows
different precedence rules.
FC>>Does this work in MyFaces?
Yes. This is one comment I added long time ago in the code that explains it:
// Contracts are on top of everything, because it is a concept
that defines
// resources in a application scope concept. It means all resources in
// /resources or /META-INF/resources can be overriden using a
contract. Note
// it also means resources under /META-INF/flows can also be
overriden using
// a contract.
// Check first the preferred contract if any. If not found,
try the remaining
// contracts and finally if not found try to found a resource without a
// contract name.
In that way, you can define the "default" stylesheet, composite
component, javascript or whatever under /META-INF/resources, and the
contract can override it if necessary, making easier to define an
alternate L&F just making some small changes from the original. The
same applies with the templates, but in that case you can define them
in the webapp root folder. Otherwise, you can't define a "default",
for every resource involved, and that is nonsense to me.
regards,
Leonardo Uribe
2015-02-04 8:43 GMT-05:00 Frank Caputo <frank_at_frankcaputo.de>:
> 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
>>>>>
>>>>
>>
>