[
https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832885#action_12832885
]
Massimo Lusetti commented on TAP5-1013:
---------------------------------------
And perhaps hook it to the "production" symbol to disable it on production
deployments.
> Live class reloading for service implementations
> ------------------------------------------------
>
> Key: TAP5-1013
> URL: https://issues.apache.org/jira/browse/TAP5-1013
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
> Affects Versions: 5.0.19
> Reporter: Howard M. Lewis Ship
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
