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

        Howard M. Lewis Ship made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Fix Version/s 5.2.0 [ 12314122 ]
        Resolution Fixed [ 1 ]
        Howard M. Lewis Ship made changes -
        Issue Type Bug [ 1 ] New Feature [ 2 ]
        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.

        However, some methods of ObjectLocator (such as autoproxy()) should be able to hot reload the underlying class as well.
        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.
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Assignee Howard M. Lewis Ship [ hlship ]
        Howard M. Lewis Ship created 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