Ok, the trick is that one MUST override the getResourceName() method if there is no fileame given. I assume that this is not treated correctly yet in this case.

@Override
public String getResourceName()

This makes the Resources again unique.

Is this supposed to be corrected in IceFaces 4.3.0
I assume not because it is still reproducible there.
The description above doesn't help really how to make this work with IceFaces 4.3.0. Any help would be appreciated.

It works well if a filename is given (and thus it performs a download). But if no filename is given, it uses always the last resource of the last ace:dynamicResource on the page if there are multiple ones.

The various tests I carried out went according to expectations. Indeed, there was a memory usage issue, but it didn't seem related to garbage collection. The issue was due to the previous strategy to provide a resource name in the ProxyResource implementation within the component. It was causing the creation of a new resource at every lifecycle. This was changed to something that will produce unique resource names/URLs within a session, without producing multiple instances of said resource. After letting enough time pass after a test for the sessions to expire, the memory usage was reduced considerably, which indicates that there's no garbage collection issue.

Here are some more tips to make the memory usage more efficient when dealing with in-memory dynamic resources:

• The bean scope must match the scope specified in the component (the default is session scope, if unspecified).
• If a resource is the same for all users, then put it in an application-scoped bean and specify the application scope in the component, so that there are no multiple copies of the same resource per user.
• This component is geared towards session-scoped resources, and that's what is recommended to use for more efficient memory usage (if the resources are generated differently per user). For example, for in-memory resources that are in a window-scoped bean, a new instance of them will be loaded into memory for each new window open, even within the same session. This is simply because a new window-scoped bean will be created per window, loading its own set of properties to memory.

r53028: modified the hash string used for the resource name and resource URL to ensure that unique URLs are produced for a session, view, component, while avoiding generating multiple, unnecessary copies of the same resource across lifecycles; corrected TLD documentation

r53029: committed fix to P07 tag

investigate for memory leak.

r52897: added a distinct hash code to the calculation of the random string used as resource name, in order to ensure that these strings are distinct between other ace:dynamicResource instances on the same page