Tapestry 5
  1. Tapestry 5
  2. TAP5-1013

Live class reloading for service implementations

    Details

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

      Description

      It should be possible to create a class loader for (each) service implementation that can reload the service when its underlying class changes.

      Once could imagine this as a special proxy; possibly this would require a particular service scope ("reloadable").

      Periodically, a check could occur to let the proxies see if the underlying service implementation class file has changed and, if so, create a new class loader to load that specific class, much as tapestry-core does with component.

      This would involve moving some number of services from tapestry-core to tapestry-ioc, and there are implications related to some public services.

      I think it would be too much to support reloadable modules, just service implementations. Therefore, services that are constructed via a builder method would not be reloadable.

        Activity

        Hide
        Massimo Lusetti added a comment -

        I'm not sure to fully understand the whole story behind this, but a question arise.

        Doesn't this involve a (big) overhead within services and services interactions?

        Show
        Massimo Lusetti added a comment - I'm not sure to fully understand the whole story behind this, but a question arise. Doesn't this involve a (big) overhead within services and services interactions?
        Hide
        Howard M. Lewis Ship added a comment -

        There could be some overhead; perhaps we should have a special scope, "reloadable", for services that are subject to reload.

        Show
        Howard M. Lewis Ship added a comment - There could be some overhead; perhaps we should have a special scope, "reloadable", for services that are subject to reload.
        Hide
        Massimo Lusetti added a comment -

        And perhaps hook it to the "production" symbol to disable it on production deployments.

        Show
        Massimo Lusetti added a comment - And perhaps hook it to the "production" symbol to disable it on production deployments.
        Hide
        Howard M. Lewis Ship added a comment -

        As implemented is very specific, and limited to the default service scope.

        Show
        Howard M. Lewis Ship added a comment - As implemented is very specific, and limited to the default service scope.
        Hide
        Howard M. Lewis Ship added a comment -

        Since it only applies to Java class files on the file system (URL is "file:" protocol), there will be no new overhead in production, where libraries and (usually) the application classes are packaged up into JARs. This is really useful for development only, where performance is less of an issue.

        Show
        Howard M. Lewis Ship added a comment - Since it only applies to Java class files on the file system (URL is "file:" protocol), there will be no new overhead in production, where libraries and (usually) the application classes are packaged up into JARs. This is really useful for development only, where performance is less of an issue.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development