Hi!
Unfortunately, currently I don't have to take a deep look and what you're
doing, but from reading its description, it seems something that would be
of great worth for Tapestry-IoC. Please keep up the good work. ;)
On Mon, 18 Jul 2011 18:25:21 -0300, Tom van Dijk <[email protected]> wrote:
I thought it would be a good idea to explain this part again:
The extension is simple: it allows reusing existing (in-use) service
implementation, with a different marker. We can identify groups of
services that are tightly related and that all need to be properly
wired to eachother. They can be called "configuration groups"... maybe
someone has a better name, feel free to suggest one. With the idea in
mind that we would prefer to identify services using just the interface
they implement and additional markers, this is the perfect way to get
multiple services with the same implementation and a different
configuration.
The trick is that it might be useful to somehow reuse implementations
with a different configuration.
So how could we do it? We can't just create another instance of the
implementation and pray it goes well. There can be various reasons why
this would not work, for example, the service may use other services and
set their state depending on the configuration. If for some reason the
developer uses static fields, things would screw up. There may be other
reasons for failure. However, if developers would annotate suitable
classes, that actually can be instantiated for multiple configurations,
that would 'guarantee' that no such problems exist. After all, these
developers are then responsible for making sure there are no strange
effects and everything is neat and tidy.
Now, in the case where a service uses other closely related services in
a particular way, it is likely to be a good practice to create multiple
instances of these services as well. Also, some modules (like the
hibernate module) can provide objects and these should be provided for
every instantiation too.
For simplicity, we could assume that the instantiation is done by means
of contributing to the configuration group. For backward compatibility,
there is "default behavior" if no contributions are done: just the
normal behavior, as if there were no configuration group.
So what do we do with the hibernate and hibernate-core module? It boils
down to annotating the classes with a simple syntax, and then making
sure everything that used to be implemented well for the
single-configuration case, still works afterwards AND still works in a
multiple-configuration situation. I have done this for hibernate and
hibernate-core and the concept works.
Tom.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
