Michael Kurz wrote:
> Read inline
>
> dougd schrieb:
>> Read inline
>>
>> Michael Kurz wrote:
>>> Hi,
>>>
>>> I got your point (and that is exactly what I wanted to try), but I'm
>>> not sure how this can be accomplished. Let's assume this three
>>> resources in the jar supplied library 'images':
>>>
>>> /META-INF/resources/images/img1.png
>>> /META-INF/resources/images/img2.png
>>> /META-INF/resources/images/img3.png
>>>
>>> When I want to overwrite one of those images I have to create a
>>> resource like this:
>>>
>>> /resources/images/img2.png/2_0.png
>>>
>>> But with this and the current implementation I have also created a
>>> new library and the jar supplied library won't be used any longer.
>>> At least when I include the images using a library:
>>>
>> Are you trying to use the web root style of packaging resources? If
>> so move the directory structure up one level, and out of META-INF.
>>
>> /resources/images/img1.png
>> /resources/images/img2.png
>> /resources/images/img3.png
>
> No, I want to overwrite a resource supplied in the classpath (a jar)
> with a resource in the web root.
>
> Michael
Ok, I will do some more research. I read through the Spec Pros
documentation on Resource Packaging and I do not see anything that
stands out on how the rules apply when using both styles of packaging
inside the same webapp. It would make sense to have the rules apply,
and almost have the packaging layer transparent I would think.
Doug
>
>> Doug
>>> <h:graphicImage name="img1.png" library="images"/> (not working)
>>> <h:graphicImage name="test/test1.png"/> (working)
>>>
>>> Or did I get something wrong?
>>>
>>> Michael
>>>
>>>> Good Morning,
>>>> At first I thought the same thing, but it would seem to me
>>>> that if you were suppling a newer version of a "library" that you
>>>> would include all the files for that given library, including files
>>>> that had not changed form the previous version. If you were
>>>> changing version of specific Resource on a one by one basis would
>>>> you not want to use the Resource Version instead?
>>>>
>>>> Doug
>>>>
>>>> Michael Kurz wrote:
>>>>> Hi,
>>>>>
>>>>> I'm currently playing around with resources and libraries in Mojarra
>>>>> trunk and found someting that seams weird to me. I tried to create a
>>>>> library in META-INF/resources with a css and an image. Worked fine.
>>>>> Then I tried to "overwrite" the image in /resources in a new version
>>>>> of the library. Works too, BUT the css, which I did not overwrite, is
>>>>> no longer found.
>>>>>
>>>>> It seems that ResourceManager.doLookup() first gets the library
>>>>> with the
>>>>> highest version number in /resources and if one exists uses this
>>>>> for all resources in this library. This means that it would be
>>>>> necessary to
>>>>> overwrite the complete library if I want to change one resource
>>>>> out of it.
>>>>>
>>>>> According to the algorithm for createResource() in section 2.6.1.4 of
>>>>> the spec (PFD) I would say it should be possible to overwrite single
>>>>> files in /resources from a library in the classpath. But I might
>>>>> misinterpret it.
>>>>>
>>>>> I would be interested in what you think about that issue!
>>>>>
>>>>> rgards
>>>>> Michael Kurz
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>>> For additional commands, e-mail:
>>>>> dev-help_at_javaserverfaces.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>