You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Tom van Dijk (JIRA)" <ji...@apache.org> on 2010/10/18 22:00:24 UTC
[jira] Created: (TAP5-1313) Allow dynamic services to be created
based on configuration
Allow dynamic services to be created based on configuration
-----------------------------------------------------------
Key: TAP5-1313
URL: https://issues.apache.org/jira/browse/TAP5-1313
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-ioc
Affects Versions: 5.2.2
Reporter: Tom van Dijk
Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: 0003-Added-getService-with-markers-to-ObjectLocator.patch
0002-Include-contributions.patch
Dynamic-services-and-contributions.diff
These new patch files (plus a full diff) now also add dynamic/runtime contributions, as well as add a getService(ServiceInterface, Markers...) method to the ObjectLocator interface.
This last change WILL break test cases in other modules, because the Registry implementations used in other modules will not have the new method. As far as I can see, this is trivial to solve. (Just include a delegating method)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Comment: was deleted
(was: These new patch files (plus a full diff) now also add dynamic/runtime contributions, as well as add a getService(ServiceInterface, Markers...) method to the ObjectLocator interface.
This last change WILL break test cases in other modules, because the Registry implementations used in other modules will not have the new method. As far as I can see, this is trivial to solve. (Just include a delegating method))
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: 0003-Added-getService-with-markers-to-ObjectLocator.patch
0002-Include-contributions.patch
Dynamic-services-and-contributions.diff
These new patch files (plus a full diff) now also add dynamic/runtime contributions, as well as add a getService(ServiceInterface, Markers...) method to the ObjectLocator interface.
This last change WILL break test cases in other modules, because the Registry implementations used in other modules will not have the new method. As far as I can see, this is trivial to solve. (Just include a delegating method)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0003-Added-getService-with-markers-to-ObjectLocator.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0001-Dynamic-services.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Comment: was deleted
(was: Diff file containing patch (git diff)
Also patch file (git format-patch) but that's just the diff plus some additional git stuff and email headers.)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Comment: was deleted
(was: Diff file containing patch (git diff)
Also patch file (git format-patch) but that's just the diff plus some additional git stuff and email headers.)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: 0001-Dynamic-services.patch
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: 0001-Dynamic-services.diff
0001-Dynamic-services.patch
Diff file containing patch (git diff)
Also patch file (git format-patch) but that's just the diff plus some additional git stuff and email headers.
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.diff, 0001-Dynamic-services.patch
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TAP5-1313) Allow dynamic services to
be created based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922525#action_12922525 ]
Tom van Dijk edited comment on TAP5-1313 at 10/21/10 4:37 PM:
--------------------------------------------------------------
It appears I also need to add Dynamic contributions (basically, this allows modules that create dynamic services to also contribute configurations to them)
I'll get on it.
It also seems a ObjectLocator.getService(Class serviceImplementation, Class... markers) is very useful.
I added both things, you can see the result on my git at git://hetdiana.homeip.net/tapestry5.git (branches iocmod3 and hibmod)
was (Author: tvandijk):
It appears I also need to add Dynamic contributions (basically, this allows modules that create dynamic services to also contribute configurations to them)
I'll get on it.
It also seems a ObjectLocator.getService(Class serviceImplementation, Class... markers) is very useful.
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0002-Include-contributions.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922525#action_12922525 ]
Tom van Dijk commented on TAP5-1313:
------------------------------------
It appears I also need to add Dynamic contributions (basically, this allows modules that create dynamic services to also contribute configurations to them)
I'll get on it.
It also seems a ObjectLocator.getService(Class serviceImplementation, Class... markers) is very useful.
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.diff, 0001-Dynamic-services.patch
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0002-Include-contributions.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: 0001-Dynamic-services.patch
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0001-Dynamic-services.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TAP5-1313) Allow dynamic services to
be created based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922525#action_12922525 ]
Tom van Dijk edited comment on TAP5-1313 at 10/21/10 4:37 PM:
--------------------------------------------------------------
It appears I also need to add Dynamic contributions (basically, this allows modules that create dynamic services to also contribute configurations to them)
I'll get on it.
It also seems a ObjectLocator.getService(Class serviceImplementation, Class... markers) is very useful.
I added both things, you can see the result on my git at git://hetdiana.homeip.net/tapestry5.git (branches iocmod3 and hibmod)
was (Author: tvandijk):
It appears I also need to add Dynamic contributions (basically, this allows modules that create dynamic services to also contribute configurations to them)
I'll get on it.
It also seems a ObjectLocator.getService(Class serviceImplementation, Class... markers) is very useful.
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0001-Dynamic-services.diff)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: Dynamic-services-and-contributions.diff)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0001-Dynamic-services.diff)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922525#action_12922525 ]
Tom van Dijk commented on TAP5-1313:
------------------------------------
It appears I also need to add Dynamic contributions (basically, this allows modules that create dynamic services to also contribute configurations to them)
I'll get on it.
It also seems a ObjectLocator.getService(Class serviceImplementation, Class... markers) is very useful.
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.diff, 0001-Dynamic-services.patch
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Comment: was deleted
(was: These new patch files (plus a full diff) now also add dynamic/runtime contributions, as well as add a getService(ServiceInterface, Markers...) method to the ObjectLocator interface.
This last change WILL break test cases in other modules, because the Registry implementations used in other modules will not have the new method. As far as I can see, this is trivial to solve. (Just include a delegating method))
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0003-Added-getService-with-markers-to-ObjectLocator.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0001-Dynamic-services.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: Dynamic-services-and-contributions.diff)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: (was: 0001-Dynamic-services.patch)
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.patch, 0002-Include-contributions.patch, 0003-Added-getService-with-markers-to-ObjectLocator.patch, Dynamic-services-and-contributions.diff
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1313) Allow dynamic services to be created
based on configuration
Posted by "Tom van Dijk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom van Dijk updated TAP5-1313:
-------------------------------
Attachment: 0001-Dynamic-services.diff
0001-Dynamic-services.patch
Diff file containing patch (git diff)
Also patch file (git format-patch) but that's just the diff plus some additional git stuff and email headers.
> Allow dynamic services to be created based on configuration
> -----------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.2.2
> Reporter: Tom van Dijk
> Attachments: 0001-Dynamic-services.diff, 0001-Dynamic-services.patch
>
>
> Dynamic services are services that are not defined at compile-time, but at runtime, just before performing Registry startup.
> Dynamic services are a useful concept for the implementation of a module that allows for multiple Hibernate databases. Other modules can contribute markers to the Hibernate module. The Hibernate module will then create the set of Hibernate services (HibernateSessionSource, HibernateSessionManager, Session, etc) with marker annotations and service ids based on the configuration. These services can be further configured with contributions, e.g. if there are databases with markers "One" and "Two", these could cause HibernateEntityPackageManagerOne and HibernateEntityPackageManagerTwo to be created, which can be configured with contributors contributeHibernateEntityPackageManagerOne() and contributeHibernateEntityPackageManagerTwo.
> I propose dynamic services as one of the possible solutions for allowing services to be created after initial setup. The advantage of this method is that these services can be injected directly, without using indirect constructs such as object providers, which have the disadvantage of not being able to use the service lifecycle management Tapestry offers. It is also easier and more intuitive to contribute to each individual service using the standard service mechanisms in Tapestry rather than an indirect method, for example supplying the entire configuration for all services to a hypothetical HibernateObjectsSource or HibernateConfiguration service.
> Dynamic services have to be added prior to validateContributeDefs() in the constructor of the Registry service. I will include a patch with the implementation of this feature and a test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.