Hi Martin,
On 11/05/2012 10:30, Martin Grigorov wrote:
Hi Jesse,
On Fri, May 11, 2012 at 11:06 AM, Jesse Long<[email protected]> wrote:
Hi Wicket Devs,
TextTemplateResourceReference is dynamic, it contains a Map<String, Object>
to populate a normal text resource.
issue 1: It cannot be shared between servers in a cluster, I think we should
add some javadocs explaining this. The old, "if your cluster does not
support sticky sessions, this will not work" bit.
Yes. This is valid for every dynamic resource that gets registered in
the ResourceReferenceRegistry.
issue 2: The problem is that it is registered using the same key in the
ResourceReferenceRegistry each time. In 1.5.5 only the first instance was
registered, but I see this is fixed, at least in master. Now, it deregisters
the previous instance and registers a new instance. This is not very thread
safe. Think multiple instances created in different sessions.
I was wondering, would it be possible to register
TextTemplateResourceReference using a autogenerated "resource name" (param 2
to ResourceReference constructor), and use some sort of listener to identify
when it goes out of scope (page expired etc), and then clean it up?
I think there may be a better solution which solves both issues:
create a ResourceReferenceRegistry on Session level.
Issue 1 will be solved by session replication.
I think moving ResourceReferenceRegistry to the session is a good idea.
We should not that in TextTemplateResourceReference, the map is defined
as Map<String, Object> as opposed to Map<String, Serializable>, even
though ResourceReference implement IClusterable.
If serialization of a ResourceReference fails, would that cause the
entire session replication to fail?
I'm still not entirely happy about TextTemplateResourceReference
deregistering the previous instance even if it only affects just the
current session. Would there be a possibility of it removing a real
reference to a resource that could still be used by a user (refresh page
etc)?
I normally create the TextTemplateResourceReference in renderHead(), so
new one each render....
Issue 2 - each session handles its dynamic res refs.
What do you think ?
I wouldn't mind working on a patch, if I could get some pointers on where to
start.
Thanks,
Jesse
