[
https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844366#action_12844366
]
Howard M. Lewis Ship commented on TAP5-1013:
--------------------------------------------
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.
> Live class reloading for service implementations
> ------------------------------------------------
>
> Key: TAP5-1013
> URL: https://issues.apache.org/jira/browse/TAP5-1013
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.0.19
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 5.2.0
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
