[
https://issues.apache.org/jira/browse/TAP5-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom van Dijk updated TAP5-1313:
-------------------------------
Component/s: tapestry-hibernate
Description:
Contribution groups allow service implementations that are closely linked
together, to be created multiple times (using markers to identify them) with
automatic dependency resolution.
e.g. service implementations OneImpl (implements One) and TwoImpl (implements
Two) use eachother, then with markers red and blue, we get One@Red and One@Blue
and Two@Red and Two@Blue. They will each have their own configurations
(unmarked contributions go to both Red and Blue, but contributions marked Red
will go to the One@Red and Two@Red services, etc.)
This is applied to the hibernate and hibernate-core services, allowing multiple
databases to be used without having to use spring services.
was:
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.
Affects Version/s: (was: 5.2.2)
Summary: Configuration groups to easily allow multiple services
with same implementation, allowing handling multiple hibernate databases (was:
Allow dynamic services to be created based on configuration)
> Configuration groups to easily allow multiple services with same
> implementation, allowing handling multiple hibernate databases
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1313
> URL: https://issues.apache.org/jira/browse/TAP5-1313
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-hibernate, tapestry-ioc
> Reporter: Tom van Dijk
> Attachments:
> Multiple-databases-support-using-configuration-group.patch
>
>
> Contribution groups allow service implementations that are closely linked
> together, to be created multiple times (using markers to identify them) with
> automatic dependency resolution.
> e.g. service implementations OneImpl (implements One) and TwoImpl (implements
> Two) use eachother, then with markers red and blue, we get One@Red and
> One@Blue and Two@Red and Two@Blue. They will each have their own
> configurations (unmarked contributions go to both Red and Blue, but
> contributions marked Red will go to the One@Red and Two@Red services, etc.)
> This is applied to the hibernate and hibernate-core services, allowing
> multiple databases to be used without having to use spring services.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira