there's been some talk about allowing for seperate Sessions (and related), using marker annotation to identify which one you need. I.e., you might have
@Inject @Product private Session productSession; @Inject @Content private Session contentSession; That's not too hard; the tricky part is the replication of several services with the same interface; i.e., you will need an @Product HibernateConfigurer and a @Content HibernateConfigurer, etc. This could all be done, and done on top of tapestry-hibernate without changing the framework, I think. The only tricky part is that the default HibernateConfigurer assumes that you start by reading hibernate.cfg.xml and that would need to be more flexible (hibernate-products.cfg.xml, hibernate-session.cfg.xml). On Tue, Jun 1, 2010 at 3:25 PM, Tom van Dijk <[email protected]> wrote: > Hi, > > I'll be brief to save you time. > > I want to turn my webapplication (for a company I work for, I'm doing a > proof of concept to see if what I want is possible) into a Tapestry5 based > system. > > Our web applications use multiple databases (to enforce seperation of > concerns and for possible future scaling) > > We currently use two filters that provide two EntityManagerFactory objects > (this is just for a small proof of concept webapp) and what I would like is > to have two differently configured Session services. Obviously, I want to > move on, embrace the future and start using a proper IoC framework. > > Now I see in the issue system that this (using multiple databases) is > unsupported. My question concerns a generalized approach. My first thoughts > were on creating some kind of a general Factory service that would spawn the > necessary custom services, but at second thought I found something that > might be less complex. > > What if there were a way to copy existing services and override their > configurations? Unless I'm really stupid, this is not yet possible. > > One rather obvious issue is that the services I'd like to copy depend on > eachother, so there would have to be a method to map them all to a copy. > Else I would copy a service only to find that it's still depending on the > original's services. > > Constraints: > The software is supposed to be unaware of the implementation classes but it > may of course be aware of the externally provided services. > I don't want to copy existing code. Obviously. It would hurt reusability. > Basically, what we're dealing with is a matter of creating different > services (or groups of services) with different configurations. > > So, we have 3 services > HibernateSessionManager > HibernateSessionSource > HibernateEntityPackageManager > Session > > Now what I would like is to create 3 new services: > ContentSessionManager > ContentSessionSource > ContentEntityPackageManager > ContentSession > ProductsSessionManager > ProductsSessionSource > ProductsEntityPackageManager > ProductsSession > > Now I would like a service "ServiceCopier" or something like that to > implement: [pseudocode] > Map<String, String> content = { "Session" => "ContentSession", > "HibernateSessionManager" => "ContentSessionManager", > "HibernateSessionSource"=>"ContentSessionSource", > "HibernateEntityPackageManager"=>"ContentEntityPackageManager" } > Map<String, String> products = {"Session" => "ProductsSession", > "HibernateSessionManager" => "ProductsSessionManager", > "HibernateSessionSource"=>"ProductsSessionSource", > "HibernateEntityPackageManager"=>"PrudctsEntityPackageManager" } > copier.add(first); > copier.add(second); > > This would happen in the Module, of course. I would also set > DefaultConfiguration to false and provide my own thingie for that, but > that's simple once the new services are coaxed to use the contributions > using their new service id. > > The service builder would construct the three services as normal, except > that whenever ContentSessionManager depends on HibernateSessionSource, it > will depend on ContentSessionSource instead, et cetera. I can then use > @InjectService("ContentSession") > > There is one important thing: the contributions from the original service > will have to be included, as well as contributions for the new service id. > If this would not happen, configurers such as > PackageNameHibernateConfigurer.java would not be included. The proper usage > of the concept explained here is that a user would not provide extra > configuration contributions for the base case, but only for the derived > services. > > Hmmm this sounds conceptually a bit like namespaces, but you're way ahead of > me in experience so I can't really comment on the similarity. > > Anyway, I promised to keep it brief and I doubt I could describe it in less > words. I've described my problem and leave it to you to reply. > > Hoping for an answer, > > Tom van Dijk. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
