Tapestry 5
  1. Tapestry 5
  2. TAP5-1076

When a service implementation is reloadable, it will not eager load

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.2.0
    • Fix Version/s: 5.2.0
    • Component/s: tapestry-ioc
    • Labels:
      None

      Description

      Howard's comment on user mailling list:

      Basically, when using reloadable, the object at the end of the
      delegate/advice stack, which is normally the service implementation,
      is itself a proxy that performs live class reloading. Currently, it
      does not attempt to load the service implementation until needed, but
      that can and should be changed, giving reloaded services that same
      semantics as non-reloadable services (just with one extra level of
      proxy).

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        ... because instantiating the service eagerly only instantiates another layer of just-in-time object creation (the proxy around the live-reloaded implementation). Fortunately, it's easy to force the innermost proxy to create an object if eager loading.

        Show
        Howard M. Lewis Ship added a comment - ... because instantiating the service eagerly only instantiates another layer of just-in-time object creation (the proxy around the live-reloaded implementation). Fortunately, it's easy to force the innermost proxy to create an object if eager loading.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Christophe Cordenier
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development