[
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.
