You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org> on 2010/02/11 14:28:28 UTC
[jira] Created: (TAP5-1013) Live class reloading for service
implementations
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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832726#action_12832726 ]
Howard M. Lewis Ship commented on TAP5-1013:
--------------------------------------------
There could be some overhead; perhaps we should have a special scope, "reloadable", for services that are subject to reload.
> 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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAP5-1013:
---------------------------------------
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.
was:
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.
Issue Type: New Feature (was: Bug)
As implemented is very specific, and limited to the default service scope.
> 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
>
> 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.
[jira] Assigned: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1013:
------------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: 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.
[jira] Closed: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-1013.
--------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.0
> 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.
[jira] Updated: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAP5-1013:
---------------------------------------
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.
was:
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.
Issue Type: New Feature (was: Bug)
As implemented is very specific, and limited to the default service scope.
> 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
>
> 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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832482#action_12832482 ]
Massimo Lusetti commented on TAP5-1013:
---------------------------------------
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?
> 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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832726#action_12832726 ]
Howard M. Lewis Ship commented on TAP5-1013:
--------------------------------------------
There could be some overhead; perhaps we should have a special scope, "reloadable", for services that are subject to reload.
> 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.
[jira] Assigned: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1013:
------------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: 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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-1013.
--------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.0
> 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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (TAP5-1013) Live class reloading for service
implementations
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832482#action_12832482 ]
Massimo Lusetti commented on TAP5-1013:
---------------------------------------
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?
> 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.