Hi Leonardo,
thanks for the explanation. So you agree with the new pseudo code in JAVASERVERFACES_SPEC_PUBLIC-1338?
Ciao Frank
> Am 04.02.2015 um 19:59 schrieb Leonardo Uribe <leonardo.uribe_at_irian.at>:
>
> 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
>>>>>>
>>>>>
>>>
>>
>