For what it's worth, encapsulating Session#setMetaData() and
Session#getMetaData() to work around this issue led me to the following
pattern which I'm really enjoying. Synchronization and dirtying are omitted
here for brevity.

SessionMetaDataModel<T extends Serializable> implements IModel {
  private final MetaDataKey<T> key;

  public SessionMetaDataModel(MetaDataKey<T> key) { this.key = key; }
  public static IModel<T> of(MetaDataKey<T> key) { return new
SessionMetaDataModel<T>(key); }

  public T getObject() { return session.getMetaData(key); }
  public void setObject(T object) { session.setMetaData(key, object); }
  public void detach() {}
}

Then in the class that defines the metadata:
private static final IModel<String> STRING_MODEL =
SessionMetaDataModel.of(new MetaDataKey<String>{ });

Essentially we've just replaced the static final MetaDataKey with a static
final IModel, which plays nicer with components and whose use is easier on
the eyes.

Dan

On Wed, Jun 8, 2011 at 11:45 AM, Dan Retzlaff <[email protected]> wrote:

> https://issues.apache.org/jira/browse/WICKET-3779
>
>
> On Wed, Jun 8, 2011 at 11:32 AM, Igor Vaynberg <[email protected]>wrote:
>
>> most likely it is an oversight. open an issue. at some point session
>> access was synchronized, but later it was made more granular. the
>> metadata code may have never been updated.
>>
>> -igor
>>
>>
>> On Wed, Jun 8, 2011 at 11:29 AM, Dan Retzlaff <[email protected]>
>> wrote:
>> > Hey all,
>> >
>> > Can someone help me understand the synchronization and dirty-marking
>> > requirements surrounding Session#setMetaData()? I thought the rules for
>> > Session use were (1) synchronize data access, (2) call Session#dirty()
>> after
>> > data changes to replicate the changes across the cluster. However, I
>> don't
>> > see either of these happening in Wicket's internal use of Session
>> MetaData.
>> > Is this an oversight, or am I missing something?
>> >
>> > Thanks,
>> > Dan
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>

Reply via email to