Hi Tom,
I'm not completely sure I understand how you wish to accomplish this in
detail, but the copier idea sounds dangerous to me.
We run a system where we have a different db per license (read client)
and many clients on one webapp. In our architecture we have used spring
in which all services are defined as prototypes and pass the
HibernateSession with its connection properties as constructor argument
to make sure one service can never switch db's. Some overhead in the
fact we have a pool of services per db.
The services are managed by a context class (one per db/client). In
Tapestry we have build a per thread ServiceProvider class. This service
provider checks the HttpSession for the context the asking user belongs
to and returns the required service from the correct db/context. This
way our pages/components don't need to know anything about where the
service comes from.
The downfall is that we can't directly @Inject all our services and have
to go through the @Injecte'd ServiceProvider. Ok for us, but I'm sure
its possible to overwrite Tapestries inject process to accomplish this.
Hope it is of some help.
Cheers,
Joost
Tom van Dijk 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
