Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.4.19, 6.2.0
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None

      Description

      As described in https://issues.apache.org/jira/browse/WICKET-102 , DateConverter internally uses DateFormat to do its job, without the external synchronization DateFormat's javadoc states it need.

      Since DateConverter is used by Wicket in a multi-threaded scenario (converters instances can be shared between threads) it should guarantee thread-safeness.
      A user of DateConverter (and he could be unaware of using a DateConverter) shouldn't worry about its internal mechanics, thus DateConverter should handle the synchronization by itself.

      Tested on v1.4.19, and just browsed v6.2.0 sources to check if something changed.

      Thanks in advance, and sorry for my sloppy english.

        Issue Links

          Activity

          SoulSpirit created issue -
          SoulSpirit made changes -
          Field Original Value New Value
          Link This issue is related to WICKET-102 [ WICKET-102 ]
          Hide
          Emond Papegaaij added a comment -

          A new DateConverter is created on every conversion, therefore there is no need for synchronization.

          Show
          Emond Papegaaij added a comment - A new DateConverter is created on every conversion, therefore there is no need for synchronization.
          Emond Papegaaij made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Invalid [ 6 ]
          Hide
          Martin Grigorov added a comment -

          Looking at java.text.DateFormat#get() it may return a pooled one...

          Show
          Martin Grigorov added a comment - Looking at java.text.DateFormat#get() it may return a pooled one...
          Hide
          Emond Papegaaij added a comment -

          No, the pool is just about DateFormatProviders, not about DateFormats. DateFormatProviders always return new instances.

          Show
          Emond Papegaaij added a comment - No, the pool is just about DateFormatProviders, not about DateFormats. DateFormatProviders always return new instances.
          Hide
          SoulSpirit added a comment -

          Converters are mantained in a map managed by ConverterLocator, which is usually unique among the Application lifetime.
          A new instance of org.apache.wicket.util.convert.converter.DateConverter is created in ConverterLocator's constructor and that single instance is referenced by every thread in the same Application.

          I'm not even considering java.text.DateFormat internals, since its javadocs states: Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.

          Show
          SoulSpirit added a comment - Converters are mantained in a map managed by ConverterLocator, which is usually unique among the Application lifetime. A new instance of org.apache.wicket.util.convert.converter.DateConverter is created in ConverterLocator's constructor and that single instance is referenced by every thread in the same Application. I'm not even considering java.text.DateFormat internals, since its javadocs states: Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.
          SoulSpirit made changes -
          Link This issue relates to WICKET-4839 [ WICKET-4839 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              SoulSpirit
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development