You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Tom van Dijk <to...@tvandijk.nl> on 2011/07/18 19:34:52 UTC
Questions regarding Configuration Groups / Multiple Databases
Hi all of you,
After a break from development (concentrating on my CS studies) I find
myself with some summer free time and updated my tapestry git tree.
Currently I have a number of commits that might be useful. Most are
related to the thing I was working on earlier, having multiple databases
support using configuration groups.
Now I know that there might be a different way to get multiple databases
support, which I did not test myself yet. What I'm doing here is
extending the IoC in a way that might be useful in other ways as well.
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 commits I have available are:
1. a typo fix, "cxreateProvider". Should I make a JIRA issue out of it
or can some committer just fix this without all the paperwork?
2. TAP5-1321. If there are no reasons why this couldn't be in, I can
update the JIRA issue.
3. Related to this is a commit that adds a new getObject() to
RegistryImpl and a getMarkers() to RegistryImpl, which are necessary for
configuration groups. Do you want me to add this commit to TAP5-1321, or
to the configuration groups patch?
4. TAP5-1313 The commit that introduces configuration groups.
5. TAP5-1313 (2) The commit that modifies tapestry-hibernate and
tapestry-hibernate-conf to allow multiple databases.
6. TAP5-1475 A feature "fix" in tapestry-upload. Maybe a committer can
get assigned to this issue so it gets resolved?
Those were my questions.
If you want to see the current version of my patches, you can use my git
repository, at git://hetdiana.dyndns.org/tapestry5.git ... it may be out
of date if I don't update it regularly by rebasing everything against
the apache git repo.
Thanks,
Tom.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Questions regarding Configuration Groups / Multiple Databases
Posted by Tom van Dijk <to...@tvandijk.nl>.
Maybe you now have time to take a look at this. I have no idea if
attaching a PDF file works, but I'll just try!
I will also just paste it here but I have the feeling that the result
will look ugly but anyway, here goes...
*Multiple Configurations extension to Tapestry IoC*
_*Goal*_
Create services with the same implementation but with a different
configuration.
_*Description*_
With an annotation a service implementation can be assigned to a
configuration group. This group is represented by a /Class/. (Just like
markers.)
Tapestry Modules can contribute configuration markers (represented by a
/class/) to a configuration group. The configuration marker can also be
/null/.
If no markers are contributed, every service will be instantiated
without additional markers. If markers are contributed, every service
will be instantiated for each marker. If the /null/marker is
contributed, then there will also be a service without additional markers.
The different instantiated services will be automatically linked to
services within the same configuration group.
Configurations are contributed to a combination of service interface and
markers. For a given service, it will use the contributions to the
service /without the configuration marker/that has the
@MultipleConfigurations annotation, plus the contributions to the
service /with the configuration marker/.
_*Example*_
There are two services in the module ExampleModule, service One and Two,
with implementation OneImpl and TwoImpl. The OneImpl service has the
mark @Example to distinguish it from other services. OneImpl relies on
TwoImpl, which is a local implementation of a service that is also
implemented elsewhere.
Example code:
@Marker(Example.class) @ConfigurationGroup(ExampleGroup.class)
public class OneImpl implements One {
public OneImpl(@Local Two twoObject) {}
}
@ConfigurationGroup(ExampleGroup.class)
public class TwoImpl implements Two {
public TwoImpl() {}
}
@ContributeConfigurationMarker(ExampleGroup.class)
public static final void blablabla(Configuration<Class> cfg) {
cfg.add(...);
}
_Case 1: no markers_
If no markers are contributed, there will be two services, OneImpl with
marker @Example and TwoImpl.
_Case 2: markers @Red and @Blue_
In this case, there will be four services. OneImpl with markers @Example
and @Red, which uses TwoImpl with marker @Red; OneImpl with markers
@Example and @Blue, which uses TwoImpl with marker @Blue.
_Case 3: markers @Red and null_
In this case there will also be four services. OneImpl with markers
@Example and @Red, which uses TwoImpl with marker @Red; OneImpl with
marker @Example, which uses TwoImpl without markers.
_Configuration example_
For case 3, there may be three contributions:
@Contribution(One.class) @Marker({Red.class})
public static void firstContribution() ...
@Contribution(One.class)
public static void secondContribution() …
@Contribution(One.class) @MultipleConfigurations
public static void thirdContribution() …
In this example, the service with marker @Red will receive the first and
the third contributions. The service without markers will receive the
first and the second contributions.
_*Extra features*_
It is sometimes necessary to know the different configurations and
markers. One example is when contributing an object provider that has to
provide a different object for every configuration. It is also possible
to query the Registry for this information. Because this cannot be done
in the startup phase, the contributed markers can also be injected.
We define two additional resources:
*
a Class with the @ConfigurationGroup annotation will at runtime hold
the marker of this service or /null/ if it has none.
*
A Set or Collection with the @ConfigurationGroup annotation will
hold all contributed markers, including /null/ if it has been
contributed.
_*Naming*_
The names are not fixed yet so they are up to debate and preference.
*
the terms “configuration group” and “configuration marker”
*
the annotation @ConfigurationGroup
*
the annotation @MultipleConfigurations for contributions to all
services in the same group
*
the annotation @ContributeConfigurationMarker for contributions to
configuration groups
*
the injection marker @ConfigurationGroup
Op 19-7-2011 18:34, Thiago H. de Paula Figueiredo schreef:
> 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 <to...@tvandijk.nl> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
Re: Questions regarding Configuration Groups / Multiple Databases
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
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 <to...@tvandijk.nl> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Questions regarding Configuration Groups / Multiple Databases
Posted by Tom van Dijk <to...@tvandijk.nl>.
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Questions regarding Configuration Groups / Multiple Databases
Posted by Tom van Dijk <to...@tvandijk.nl>.
Obviously, if you want to checkout from my git repository, use the
"multiconf" branch. Forgot to mention it. All other branches on that git
repo are very obsolete.
On 07/18/2011 07:34 PM, Tom van Dijk wrote:
> Hi all of you,
>
>
> After a break from development (concentrating on my CS studies) I find
> myself with some summer free time and updated my tapestry git tree.
>
>
> Currently I have a number of commits that might be useful. Most are
> related to the thing I was working on earlier, having multiple
> databases support using configuration groups.
>
> Now I know that there might be a different way to get multiple
> databases support, which I did not test myself yet. What I'm doing
> here is extending the IoC in a way that might be useful in other ways
> as well.
>
> 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 commits I have available are:
>
>
> 1. a typo fix, "cxreateProvider". Should I make a JIRA issue out of it
> or can some committer just fix this without all the paperwork?
>
> 2. TAP5-1321. If there are no reasons why this couldn't be in, I can
> update the JIRA issue.
>
> 3. Related to this is a commit that adds a new getObject() to
> RegistryImpl and a getMarkers() to RegistryImpl, which are necessary
> for configuration groups. Do you want me to add this commit to
> TAP5-1321, or to the configuration groups patch?
>
> 4. TAP5-1313 The commit that introduces configuration groups.
>
> 5. TAP5-1313 (2) The commit that modifies tapestry-hibernate and
> tapestry-hibernate-conf to allow multiple databases.
>
> 6. TAP5-1475 A feature "fix" in tapestry-upload. Maybe a committer can
> get assigned to this issue so it gets resolved?
>
>
>
> Those were my questions.
>
> If you want to see the current version of my patches, you can use my
> git repository, at git://hetdiana.dyndns.org/tapestry5.git ... it may
> be out of date if I don't update it regularly by rebasing everything
> against the apache git repo.
>
> Thanks,
>
> Tom.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org