Hi To find elements on how to override some Tapestry Hibernate services, you can have a look at http://github.com/spreadthesource/tapestry5-spring-tx
If you combine this with Howard's design advices, i guess you will have all the elements to develop your solution. 2010/6/2 Tom van Dijk <[email protected]> > 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] > > -- Regards, Christophe Cordenier. Developer of wooki @wookicentral.com
