Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:Lazy Start Bundles"
(→Resource Loads) |
m |
||
| Line 7: | Line 7: | ||
[[User:Hargrave.us.ibm.com|BJ Hargrave]] 14:29, 7 September 2006 (EDT) | [[User:Hargrave.us.ibm.com|BJ Hargrave]] 14:29, 7 September 2006 (EDT) | ||
| − | Well I would rather change the trigger to be "create a class loader" instead of "first class (or resource) load". In reality it is the class loader creation event that should be the trigger for lazy start. Class loader creation may be triggered by a class load (by following a wire into the bundle or Bundle.loadClass) or a resource request (by following a wire into the bundle or Bundle.getResource). While the framework should be free to create the class loader earlier if it so desires the visible effect of the creation of the class loader (lazy start) does not need to be visible until the class loader is used (first class or resource load is requested). | + | Well I would rather change the trigger to be "create a class loader" instead of "first class (or resource) load". In reality it is the class loader creation event that should be the trigger for lazy start. Class loader creation may be triggered by a class load (by following a wire into the bundle or Bundle.loadClass) or a resource request (by following a wire into the bundle or Bundle.getResource). While the framework should be free to create the class loader earlier if it so desires, the visible effect of the creation of the class loader (lazy start) does not need to be visible until the class loader is first used (first class or resource load is requested). |
[[User:Tjwatson.us.ibm.com|Tjwatson.us.ibm.com]] 14:39, 7 September 2006 (EDT) | [[User:Tjwatson.us.ibm.com|Tjwatson.us.ibm.com]] 14:39, 7 September 2006 (EDT) | ||
I need to investigate this approach more. It may make things simplier and it may help solve the class circularity issues. In this model the classloader would be created and the bundle would be activated before even asking for the class being requested. This should help prevent the circularity issue. | I need to investigate this approach more. It may make things simplier and it may help solve the class circularity issues. In this model the classloader would be created and the bundle would be activated before even asking for the class being requested. This should help prevent the circularity issue. | ||
Revision as of 14:45, 7 September 2006
Resource Loads
BJ Hargrave changed the design to activate lazy-start bundles upon first class or resource load requests. This is not how the current lazy-start implementation works in Equinox.
In the past we have not thought of any reason a bundle would need to be activated because a resource was loaded from it. Are there any reasons why a bundle would need to be activated before a resource is allowed to load from it?
BJ Hargrave 14:29, 7 September 2006 (EDT)
Well I would rather change the trigger to be "create a class loader" instead of "first class (or resource) load". In reality it is the class loader creation event that should be the trigger for lazy start. Class loader creation may be triggered by a class load (by following a wire into the bundle or Bundle.loadClass) or a resource request (by following a wire into the bundle or Bundle.getResource). While the framework should be free to create the class loader earlier if it so desires, the visible effect of the creation of the class loader (lazy start) does not need to be visible until the class loader is first used (first class or resource load is requested).
Tjwatson.us.ibm.com 14:39, 7 September 2006 (EDT)
I need to investigate this approach more. It may make things simplier and it may help solve the class circularity issues. In this model the classloader would be created and the bundle would be activated before even asking for the class being requested. This should help prevent the circularity issue.