Using multiple databases?

[Tom van Dijk]

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: [hidden email]
For additional commands, e-mail: [hidden email]

[joostschouten]

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Howard Lewis Ship]

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
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!

[phone]
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Christophe Cordenier]

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 <[hidden email]>

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Regards,
Christophe Cordenier.

Developer of wooki @wookicentral.com

[Piero Sartini-3]

> 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).

I've thought about implementing this functionality in tapestry-jpa as well.
With JPA we don't have the problem of the configuration as everything
is configured inside persistence.xml. Auto discovery is already
handled by most implementations. No need to do all the configuration
magic present in the hibernate module.

If you want to introduce some way to handle multiple databases in the
hibernate module, maybe it would be a good timeframe to create a
tapestry-persistence module which can be used by other modules like
tapestry-jpa or tapestry-mongodb as well. I am thinking mainly about
annotations like @CommitAfter. But the interface to handle multiple
data sources should be reusable as well.

On a side note, maybe its time for tapestry to get first class JPA2 support?

             Piero

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Howard Lewis Ship]

Just a matter of bandwidth.  Also, I prefer not to create modules for
things I'm not actively using. I currently use Hibernate in both my
client projects, but don't use JPA. I or someone else could throw
something together, or take a contribution, but I'd prefer to have
someone who actively maintains and improves whatever library is
created.

I've seen in infrastructures that make it very easy to create and
distribute libraries or modules, such as Ruby Gems, you see an awful
lot of incomplete, outdated and orphaned code.

On Wed, Jun 2, 2010 at 9:20 AM, Piero Sartini <[hidden email]> wrote:

>> 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).
>
> I've thought about implementing this functionality in tapestry-jpa as well.
> With JPA we don't have the problem of the configuration as everything
> is configured inside persistence.xml. Auto discovery is already
> handled by most implementations. No need to do all the configuration
> magic present in the hibernate module.
>
> If you want to introduce some way to handle multiple databases in the
> hibernate module, maybe it would be a good timeframe to create a
> tapestry-persistence module which can be used by other modules like
> tapestry-jpa or tapestry-mongodb as well. I am thinking mainly about
> annotations like @CommitAfter. But the interface to handle multiple
> data sources should be reusable as well.
>
> On a side note, maybe its time for tapestry to get first class JPA2 support?
>
>             Piero
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
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!

[phone]
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Piero Sartini-3]

> Just a matter of bandwidth.  Also, I prefer not to create modules for
> things I'm not actively using. I currently use Hibernate in both my
> client projects, but don't use JPA. I or someone else could throw
> something together, or take a contribution, but I'd prefer to have
> someone who actively maintains and improves whatever library is
> created.

Point taken. I am happy with tapestry-jpa as a seperate module.
It's just that people often say to me: "What? No JPA support?"
Sometimes its hard to explain that there exists a third party module
that is not part of tapestry itself. But I guess we can solve this
with the new homepage and make it more clear that it is totally OK to
use external modules.

Anyway, what I would really love to see is that tapestry's core makes
it easier for others to integrate new persistence strategies.
@CommitAfter and other stuff could be factored out of the hibernate
module - its used in every persistence module I've created so far.
This would be a good start, and could be extended as needed.

To make it short: please don't put new logic into tapestry-hibernate
that could be useful for other persistence strategies as well.

                 Piero

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Thiago H de Paula Figueiredo]

On Wed, 02 Jun 2010 14:48:30 -0300, Piero Sartini <[hidden email]>  
wrote:

> Anyway, what I would really love to see is that tapestry's core makes
> it easier for others to integrate new persistence strategies.
> @CommitAfter and other stuff could be factored out of the hibernate
> module - its used in every persistence module I've created so far.
> This would be a good start, and could be extended as needed.

That's where my idea of a tapestry-transaction package would come in. It  
would provide the transation annotation (@CommitAfter or another one still  
to be created).

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tom van Dijk]

  After a "slight" delay, I've been working on a solution. (I'm a
Master's student and it appears I have little spare time for private
projects right now, hence the delay)
I didn't want to use Spring if it's not needed; in my opinion just using
Tapestry should be enough.


One line of thought that I've been toying with the last couple of days
is to have a @UseDatabase annotation, e.g.
@Inject @UseDatabase("one") Session sessionOne,
@Inject @UseDatabase("two") Session sessionTwo

The implementation is a custom object provider, which provides objects
for the interfaces Session, HibernateSessionSource,
HibernateSessionManager, HibernateTransactionDecorator and
HibernateTransactionAdvisor.
There is a configurator object (MultiHibernateEntityPackageManager) that
is configured by Map<String, Collection<String>>, with the semantics
(database-id) -> {packageName}
By default is uses "/hibernate-«name».cfg.xml" for the configuration.

Obviously, because it's a custom object provider, the whole lifecycle
stuff doesn't apply, which is a terribly ugly hack really. Besides, it's
absolutely not compatible with the original tapestry-hibernate-core module.

A different issue is that the Tapestry/Hibernate (web) integration
module also depends on Session objects, which needs to be solved at some
point (right now I just deleted them, keeping only a modified
CommitAfterWorker, which works btw).

All in all, this seems to work, but it's ugly and I have some feeling
I'm also violating Tapestry principles somewhere.



A different line of thought that I am considering is using a construct
like in the Tapestry / Swing integration package, to create all
services. There is still the issue of the Tapestry/Hibernate (web)
integration module assuming that there is only one database.
It would have
@InjectService("SessionOne") Session sessionOne.

I don't really see how the Marker option would be implemented, but this
may be my lack of experience with Tapestry. You say it can be done
without changing the framework? At the very least, it seems Persisting /
ValueEncoder / all that stuff would be broken.

Any thoughts?



Op 2-6-2010 17:23, Howard Lewis Ship schreef:

> 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<[hidden email]>  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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Howard Lewis Ship]

I think you are on the right track, but I think you'll find it easier
to go with the flow of Tapestry using a marker annotation for each
database, rather than a single annotation that names the database.

Either way, the idea that you inject the Session you need is at the core.

You'll also want to tweak @CommitAfter to search for an annotation to
determine *which* Session's transaction to commit.

You may also want to consider a service builder factory service to
make it easy to define new Hibernate services, since there's a lot in
parallel.

The new @Contribute annotation will make it easier to contribute
configuration to a specific Hibernate connection factory, or to any of
them (via marker annotations).

On Sat, Oct 16, 2010 at 7:56 AM, Tom van Dijk <[hidden email]> wrote:

>  After a "slight" delay, I've been working on a solution. (I'm a Master's
> student and it appears I have little spare time for private projects right
> now, hence the delay)
> I didn't want to use Spring if it's not needed; in my opinion just using
> Tapestry should be enough.
>
>
> One line of thought that I've been toying with the last couple of days is to
> have a @UseDatabase annotation, e.g.
> @Inject @UseDatabase("one") Session sessionOne,
> @Inject @UseDatabase("two") Session sessionTwo
>
> The implementation is a custom object provider, which provides objects for
> the interfaces Session, HibernateSessionSource, HibernateSessionManager,
> HibernateTransactionDecorator and HibernateTransactionAdvisor.
> There is a configurator object (MultiHibernateEntityPackageManager) that is
> configured by Map<String, Collection<String>>, with the semantics
> (database-id) -> {packageName}
> By default is uses "/hibernate-«name».cfg.xml" for the configuration.
>
> Obviously, because it's a custom object provider, the whole lifecycle stuff
> doesn't apply, which is a terribly ugly hack really. Besides, it's
> absolutely not compatible with the original tapestry-hibernate-core module.
>
> A different issue is that the Tapestry/Hibernate (web) integration module
> also depends on Session objects, which needs to be solved at some point
> (right now I just deleted them, keeping only a modified CommitAfterWorker,
> which works btw).
>
> All in all, this seems to work, but it's ugly and I have some feeling I'm
> also violating Tapestry principles somewhere.
>
>
>
> A different line of thought that I am considering is using a construct like
> in the Tapestry / Swing integration package, to create all services. There
> is still the issue of the Tapestry/Hibernate (web) integration module
> assuming that there is only one database.
> It would have
> @InjectService("SessionOne") Session sessionOne.
>
> I don't really see how the Marker option would be implemented, but this may
> be my lack of experience with Tapestry. You say it can be done without
> changing the framework? At the very least, it seems Persisting /
> ValueEncoder / all that stuff would be broken.
>
> Any thoughts?
>
>
>
> Op 2-6-2010 17:23, Howard Lewis Ship schreef:
>>
>> 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<[hidden email]>  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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
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!

[phone]
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tom van Dijk]

I'm sorry, but I don't "get" it.

Where can I find this service builder factory service? I use
5.2.2-SNAPSHOT from your git.

The basic idea I'm now trying to work upon is that through some kind of
configuration, the MultiHibernateModule class can figure out which
databases are used. Ideally I want it to be possible to access two
databases that have the same model (e.g. two book libraries). I don't want
to have to specify services in the web application or in model modules, but
I would like the MultiHibernateModule to take care of creating the
appropriate Session«name», HibernateSessionManager«name» and similar
services.

What tapestry-spring does is override TapestryFilter, requiring developers
to modify web.xml; besides, it doesn't scale as I don't see how multiple
tapestry modules can override TapestryFilter to add their "dynamic"
services.

As said, I can't find a service builder factory service. Where can I find
it? I can imagine contributing a service or configuration to a tapestry-ioc
service that adds 'dynamic' services [*] without "hacks" like a custom
TapestryFilter. [*] 'dynamic' defined as "determined when starting the
registry". Non-dynamic (call it static, whatever) could be defined as
compile-time / binary defined. There is no way for the MultiHibernateModule
to know which services it should define before the application is being
initialized.

I can imagine such a dynamic service builder work as follows. After the
"normal" service definitions have been collected, all contributions
(OrderedConfiguration) to the dynamic service builder are collected as well
and processed, resulting in possible extra services. I think this concept
would make tapestry-spring cleaner as well.

So, I'm again at your mercy, sir! Unless I'm overlooking something, my
"humble request" would need something new in tapestry-ioc.



On Sat, 16 Oct 2010 10:52:15 -0700, Howard Lewis Ship <[hidden email]>
wrote:
> I think you are on the right track, but I think you'll find it easier
> to go with the flow of Tapestry using a marker annotation for each
> database, rather than a single annotation that names the database.
>
> Either way, the idea that you inject the Session you need is at the
core.

>
> You'll also want to tweak @CommitAfter to search for an annotation to
> determine *which* Session's transaction to commit.
>
> You may also want to consider a service builder factory service to
> make it easy to define new Hibernate services, since there's a lot in
> parallel.
>
> The new @Contribute annotation will make it easier to contribute
> configuration to a specific Hibernate connection factory, or to any of
> them (via marker annotations).
>
> On Sat, Oct 16, 2010 at 7:56 AM, Tom van Dijk <[hidden email]> wrote:
>>  After a "slight" delay, I've been working on a solution. (I'm a
>> Master's
>> student and it appears I have little spare time for private projects
>> right
>> now, hence the delay)
>> I didn't want to use Spring if it's not needed; in my opinion just

using

>> Tapestry should be enough.
>>
>>
>> One line of thought that I've been toying with the last couple of days
>> is to
>> have a @UseDatabase annotation, e.g.
>> @Inject @UseDatabase("one") Session sessionOne,
>> @Inject @UseDatabase("two") Session sessionTwo
>>
>> The implementation is a custom object provider, which provides objects
>> for
>> the interfaces Session, HibernateSessionSource,

HibernateSessionManager,
>> HibernateTransactionDecorator and HibernateTransactionAdvisor.
>> There is a configurator object (MultiHibernateEntityPackageManager)
that

>> is
>> configured by Map<String, Collection<String>>, with the semantics
>> (database-id) -> {packageName}
>> By default is uses "/hibernate-«name».cfg.xml" for the configuration.
>>
>> Obviously, because it's a custom object provider, the whole lifecycle
>> stuff
>> doesn't apply, which is a terribly ugly hack really. Besides, it's
>> absolutely not compatible with the original tapestry-hibernate-core
>> module.
>>
>> A different issue is that the Tapestry/Hibernate (web) integration

module
>> also depends on Session objects, which needs to be solved at some point
>> (right now I just deleted them, keeping only a modified
>> CommitAfterWorker,
>> which works btw).
>>
>> All in all, this seems to work, but it's ugly and I have some feeling
I'm

>> also violating Tapestry principles somewhere.
>>
>>
>>
>> A different line of thought that I am considering is using a construct
>> like
>> in the Tapestry / Swing integration package, to create all services.
>> There
>> is still the issue of the Tapestry/Hibernate (web) integration module
>> assuming that there is only one database.
>> It would have
>> @InjectService("SessionOne") Session sessionOne.
>>
>> I don't really see how the Marker option would be implemented, but this
>> may
>> be my lack of experience with Tapestry. You say it can be done without
>> changing the framework? At the very least, it seems Persisting /
>> ValueEncoder / all that stuff would be broken.
>>
>> Any thoughts?
>>
>>
>>
>> Op 2-6-2010 17:23, Howard Lewis Ship schreef:
>>>
>>> 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<[hidden email]>  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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tom van Dijk]

Okay, I got to work a bit and here's a patch that does what I described.
Uhm, I'm not sure if I'm supposed to submit patches this way.
Anyway, it allows extra ModuleDef objects to be added.

The patch shows the general idea, I'm pretty sure I'm missing something
that breaks everything (although it builds fine) and I suppose I'm not
really following coding/commenting conventions.

Unfortunately, tapestry-spring can't be modified to use this technique,
since it relies on a ServerContext object which is unreachable because
ApplicationGlobals doesn't have it before performRegistryStartup.

Tom.


On Sat, 16 Oct 2010 23:51:04 +0200, Tom van Dijk <[hidden email]> wrote:
> I'm sorry, but I don't "get" it.
>
> Where can I find this service builder factory service? I use
> 5.2.2-SNAPSHOT from your git.
>
> The basic idea I'm now trying to work upon is that through some kind of
> configuration, the MultiHibernateModule class can figure out which
> databases are used. Ideally I want it to be possible to access two
> databases that have the same model (e.g. two book libraries). I don't
want
> to have to specify services in the web application or in model modules,
but
> I would like the MultiHibernateModule to take care of creating the
> appropriate Session«name», HibernateSessionManager«name» and similar
> services.
>
> What tapestry-spring does is override TapestryFilter, requiring
developers
> to modify web.xml; besides, it doesn't scale as I don't see how multiple
> tapestry modules can override TapestryFilter to add their "dynamic"
> services.
>
> As said, I can't find a service builder factory service. Where can I
find
> it? I can imagine contributing a service or configuration to a
tapestry-ioc
> service that adds 'dynamic' services [*] without "hacks" like a custom
> TapestryFilter. [*] 'dynamic' defined as "determined when starting the
> registry". Non-dynamic (call it static, whatever) could be defined as
> compile-time / binary defined. There is no way for the
MultiHibernateModule
> to know which services it should define before the application is being
> initialized.
>
> I can imagine such a dynamic service builder work as follows. After the
> "normal" service definitions have been collected, all contributions
> (OrderedConfiguration) to the dynamic service builder are collected as
well
> and processed, resulting in possible extra services. I think this
concept

> would make tapestry-spring cleaner as well.
>
> So, I'm again at your mercy, sir! Unless I'm overlooking something, my
> "humble request" would need something new in tapestry-ioc.
>
>
>
> On Sat, 16 Oct 2010 10:52:15 -0700, Howard Lewis Ship <[hidden email]>
> wrote:
>> I think you are on the right track, but I think you'll find it easier
>> to go with the flow of Tapestry using a marker annotation for each
>> database, rather than a single annotation that names the database.
>>
>> Either way, the idea that you inject the Session you need is at the
> core.
>>
>> You'll also want to tweak @CommitAfter to search for an annotation to
>> determine *which* Session's transaction to commit.
>>
>> You may also want to consider a service builder factory service to
>> make it easy to define new Hibernate services, since there's a lot in
>> parallel.
>>
>> The new @Contribute annotation will make it easier to contribute
>> configuration to a specific Hibernate connection factory, or to any of
>> them (via marker annotations).
>>
>> On Sat, Oct 16, 2010 at 7:56 AM, Tom van Dijk <[hidden email]> wrote:
>>>  After a "slight" delay, I've been working on a solution. (I'm a
>>> Master's
>>> student and it appears I have little spare time for private projects
>>> right
>>> now, hence the delay)
>>> I didn't want to use Spring if it's not needed; in my opinion just
> using
>>> Tapestry should be enough.
>>>
>>>
>>> One line of thought that I've been toying with the last couple of days
>>> is to
>>> have a @UseDatabase annotation, e.g.
>>> @Inject @UseDatabase("one") Session sessionOne,
>>> @Inject @UseDatabase("two") Session sessionTwo
>>>
>>> The implementation is a custom object provider, which provides objects
>>> for
>>> the interfaces Session, HibernateSessionSource,
> HibernateSessionManager,
>>> HibernateTransactionDecorator and HibernateTransactionAdvisor.
>>> There is a configurator object (MultiHibernateEntityPackageManager)
> that
>>> is
>>> configured by Map<String, Collection<String>>, with the semantics
>>> (database-id) -> {packageName}
>>> By default is uses "/hibernate-«name».cfg.xml" for the configuration.
>>>
>>> Obviously, because it's a custom object provider, the whole lifecycle
>>> stuff
>>> doesn't apply, which is a terribly ugly hack really. Besides, it's
>>> absolutely not compatible with the original tapestry-hibernate-core
>>> module.
>>>
>>> A different issue is that the Tapestry/Hibernate (web) integration
> module
>>> also depends on Session objects, which needs to be solved at some

point

>>> (right now I just deleted them, keeping only a modified
>>> CommitAfterWorker,
>>> which works btw).
>>>
>>> All in all, this seems to work, but it's ugly and I have some feeling
> I'm
>>> also violating Tapestry principles somewhere.
>>>
>>>
>>>
>>> A different line of thought that I am considering is using a construct
>>> like
>>> in the Tapestry / Swing integration package, to create all services.
>>> There
>>> is still the issue of the Tapestry/Hibernate (web) integration module
>>> assuming that there is only one database.
>>> It would have
>>> @InjectService("SessionOne") Session sessionOne.
>>>
>>> I don't really see how the Marker option would be implemented, but

this

>>> may
>>> be my lack of experience with Tapestry. You say it can be done without
>>> changing the framework? At the very least, it seems Persisting /
>>> ValueEncoder / all that stuff would be broken.
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>> Op 2-6-2010 17:23, Howard Lewis Ship schreef:
>>>>
>>>> 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<[hidden email]>  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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Howard Lewis Ship]

Patches needs to come through the JIRA system, for administrative reasons.

On Sun, Oct 17, 2010 at 7:11 AM, Tom van Dijk <[hidden email]> wrote:

> Okay, I got to work a bit and here's a patch that does what I described.
> Uhm, I'm not sure if I'm supposed to submit patches this way.
> Anyway, it allows extra ModuleDef objects to be added.
>
> The patch shows the general idea, I'm pretty sure I'm missing something
> that breaks everything (although it builds fine) and I suppose I'm not
> really following coding/commenting conventions.
>
> Unfortunately, tapestry-spring can't be modified to use this technique,
> since it relies on a ServerContext object which is unreachable because
> ApplicationGlobals doesn't have it before performRegistryStartup.
>
> Tom.
>
>
> On Sat, 16 Oct 2010 23:51:04 +0200, Tom van Dijk <[hidden email]> wrote:
>> I'm sorry, but I don't "get" it.
>>
>> Where can I find this service builder factory service? I use
>> 5.2.2-SNAPSHOT from your git.
>>
>> The basic idea I'm now trying to work upon is that through some kind of
>> configuration, the MultiHibernateModule class can figure out which
>> databases are used. Ideally I want it to be possible to access two
>> databases that have the same model (e.g. two book libraries). I don't
> want
>> to have to specify services in the web application or in model modules,
> but
>> I would like the MultiHibernateModule to take care of creating the
>> appropriate Session«name», HibernateSessionManager«name» and similar
>> services.
>>
>> What tapestry-spring does is override TapestryFilter, requiring
> developers
>> to modify web.xml; besides, it doesn't scale as I don't see how multiple
>> tapestry modules can override TapestryFilter to add their "dynamic"
>> services.
>>
>> As said, I can't find a service builder factory service. Where can I
> find
>> it? I can imagine contributing a service or configuration to a
> tapestry-ioc
>> service that adds 'dynamic' services [*] without "hacks" like a custom
>> TapestryFilter. [*] 'dynamic' defined as "determined when starting the
>> registry". Non-dynamic (call it static, whatever) could be defined as
>> compile-time / binary defined. There is no way for the
> MultiHibernateModule
>> to know which services it should define before the application is being
>> initialized.
>>
>> I can imagine such a dynamic service builder work as follows. After the
>> "normal" service definitions have been collected, all contributions
>> (OrderedConfiguration) to the dynamic service builder are collected as
> well
>> and processed, resulting in possible extra services. I think this
> concept
>> would make tapestry-spring cleaner as well.
>>
>> So, I'm again at your mercy, sir! Unless I'm overlooking something, my
>> "humble request" would need something new in tapestry-ioc.
>>
>>
>>
>> On Sat, 16 Oct 2010 10:52:15 -0700, Howard Lewis Ship <[hidden email]>
>> wrote:
>>> I think you are on the right track, but I think you'll find it easier
>>> to go with the flow of Tapestry using a marker annotation for each
>>> database, rather than a single annotation that names the database.
>>>
>>> Either way, the idea that you inject the Session you need is at the
>> core.
>>>
>>> You'll also want to tweak @CommitAfter to search for an annotation to
>>> determine *which* Session's transaction to commit.
>>>
>>> You may also want to consider a service builder factory service to
>>> make it easy to define new Hibernate services, since there's a lot in
>>> parallel.
>>>
>>> The new @Contribute annotation will make it easier to contribute
>>> configuration to a specific Hibernate connection factory, or to any of
>>> them (via marker annotations).
>>>
>>> On Sat, Oct 16, 2010 at 7:56 AM, Tom van Dijk <[hidden email]> wrote:
>>>>  After a "slight" delay, I've been working on a solution. (I'm a
>>>> Master's
>>>> student and it appears I have little spare time for private projects
>>>> right
>>>> now, hence the delay)
>>>> I didn't want to use Spring if it's not needed; in my opinion just
>> using
>>>> Tapestry should be enough.
>>>>
>>>>
>>>> One line of thought that I've been toying with the last couple of days
>>>> is to
>>>> have a @UseDatabase annotation, e.g.
>>>> @Inject @UseDatabase("one") Session sessionOne,
>>>> @Inject @UseDatabase("two") Session sessionTwo
>>>>
>>>> The implementation is a custom object provider, which provides objects
>>>> for
>>>> the interfaces Session, HibernateSessionSource,
>> HibernateSessionManager,
>>>> HibernateTransactionDecorator and HibernateTransactionAdvisor.
>>>> There is a configurator object (MultiHibernateEntityPackageManager)
>> that
>>>> is
>>>> configured by Map<String, Collection<String>>, with the semantics
>>>> (database-id) -> {packageName}
>>>> By default is uses "/hibernate-«name».cfg.xml" for the configuration.
>>>>
>>>> Obviously, because it's a custom object provider, the whole lifecycle
>>>> stuff
>>>> doesn't apply, which is a terribly ugly hack really. Besides, it's
>>>> absolutely not compatible with the original tapestry-hibernate-core
>>>> module.
>>>>
>>>> A different issue is that the Tapestry/Hibernate (web) integration
>> module
>>>> also depends on Session objects, which needs to be solved at some
> point
>>>> (right now I just deleted them, keeping only a modified
>>>> CommitAfterWorker,
>>>> which works btw).
>>>>
>>>> All in all, this seems to work, but it's ugly and I have some feeling
>> I'm
>>>> also violating Tapestry principles somewhere.
>>>>
>>>>
>>>>
>>>> A different line of thought that I am considering is using a construct
>>>> like
>>>> in the Tapestry / Swing integration package, to create all services.
>>>> There
>>>> is still the issue of the Tapestry/Hibernate (web) integration module
>>>> assuming that there is only one database.
>>>> It would have
>>>> @InjectService("SessionOne") Session sessionOne.
>>>>
>>>> I don't really see how the Marker option would be implemented, but
> this
>>>> may
>>>> be my lack of experience with Tapestry. You say it can be done without
>>>> changing the framework? At the very least, it seems Persisting /
>>>> ValueEncoder / all that stuff would be broken.
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>>
>>>> Op 2-6-2010 17:23, Howard Lewis Ship schreef:
>>>>>
>>>>> 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<[hidden email]>  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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
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!

[phone]
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tom van Dijk]

I've made a report in JIRA, TAP5-1313.

You may expect it to be a new functionality issue for allowing extra
ModuleDef objects to be added, but the result is quite different, because I
believe dynamic services really should be in the same module that wants to
define them. Anyway, you can find it in JIRA.

Tom.

On Sun, 17 Oct 2010 09:47:19 -0700, Howard Lewis Ship <[hidden email]>
wrote:
> Patches needs to come through the JIRA system, for administrative
reasons.
>
> On Sun, Oct 17, 2010 at 7:11 AM, Tom van Dijk <[hidden email]> wrote:
>> Okay, I got to work a bit and here's a patch that does what I
described.

>> Uhm, I'm not sure if I'm supposed to submit patches this way.
>> Anyway, it allows extra ModuleDef objects to be added.
>>
>> The patch shows the general idea, I'm pretty sure I'm missing something
>> that breaks everything (although it builds fine) and I suppose I'm not
>> really following coding/commenting conventions.
>>
>> Unfortunately, tapestry-spring can't be modified to use this technique,
>> since it relies on a ServerContext object which is unreachable because
>> ApplicationGlobals doesn't have it before performRegistryStartup.
>>
>> Tom.
>>
>>
>> On Sat, 16 Oct 2010 23:51:04 +0200, Tom van Dijk <[hidden email]>

wrote:
>>> I'm sorry, but I don't "get" it.
>>>
>>> Where can I find this service builder factory service? I use
>>> 5.2.2-SNAPSHOT from your git.
>>>
>>> The basic idea I'm now trying to work upon is that through some kind
of
>>> configuration, the MultiHibernateModule class can figure out which
>>> databases are used. Ideally I want it to be possible to access two
>>> databases that have the same model (e.g. two book libraries). I don't
>> want
>>> to have to specify services in the web application or in model
modules,
>> but
>>> I would like the MultiHibernateModule to take care of creating the
>>> appropriate Session«name», HibernateSessionManager«name» and similar
>>> services.
>>>
>>> What tapestry-spring does is override TapestryFilter, requiring
>> developers
>>> to modify web.xml; besides, it doesn't scale as I don't see how
multiple

>>> tapestry modules can override TapestryFilter to add their "dynamic"
>>> services.
>>>
>>> As said, I can't find a service builder factory service. Where can I
>> find
>>> it? I can imagine contributing a service or configuration to a
>> tapestry-ioc
>>> service that adds 'dynamic' services [*] without "hacks" like a custom
>>> TapestryFilter. [*] 'dynamic' defined as "determined when starting the
>>> registry". Non-dynamic (call it static, whatever) could be defined as
>>> compile-time / binary defined. There is no way for the
>> MultiHibernateModule
>>> to know which services it should define before the application is

being
>>> initialized.
>>>
>>> I can imagine such a dynamic service builder work as follows. After
the

>>> "normal" service definitions have been collected, all contributions
>>> (OrderedConfiguration) to the dynamic service builder are collected as
>> well
>>> and processed, resulting in possible extra services. I think this
>> concept
>>> would make tapestry-spring cleaner as well.
>>>
>>> So, I'm again at your mercy, sir! Unless I'm overlooking something, my
>>> "humble request" would need something new in tapestry-ioc.
>>>
>>>
>>>
>>> On Sat, 16 Oct 2010 10:52:15 -0700, Howard Lewis Ship

<[hidden email]>

>>> wrote:
>>>> I think you are on the right track, but I think you'll find it easier
>>>> to go with the flow of Tapestry using a marker annotation for each
>>>> database, rather than a single annotation that names the database.
>>>>
>>>> Either way, the idea that you inject the Session you need is at the
>>> core.
>>>>
>>>> You'll also want to tweak @CommitAfter to search for an annotation to
>>>> determine *which* Session's transaction to commit.
>>>>
>>>> You may also want to consider a service builder factory service to
>>>> make it easy to define new Hibernate services, since there's a lot in
>>>> parallel.
>>>>
>>>> The new @Contribute annotation will make it easier to contribute
>>>> configuration to a specific Hibernate connection factory, or to any

of
>>>> them (via marker annotations).
>>>>
>>>> On Sat, Oct 16, 2010 at 7:56 AM, Tom van Dijk <[hidden email]>
wrote:

>>>>>  After a "slight" delay, I've been working on a solution. (I'm a
>>>>> Master's
>>>>> student and it appears I have little spare time for private projects
>>>>> right
>>>>> now, hence the delay)
>>>>> I didn't want to use Spring if it's not needed; in my opinion just
>>> using
>>>>> Tapestry should be enough.
>>>>>
>>>>>
>>>>> One line of thought that I've been toying with the last couple of

days
>>>>> is to
>>>>> have a @UseDatabase annotation, e.g.
>>>>> @Inject @UseDatabase("one") Session sessionOne,
>>>>> @Inject @UseDatabase("two") Session sessionTwo
>>>>>
>>>>> The implementation is a custom object provider, which provides
objects

>>>>> for
>>>>> the interfaces Session, HibernateSessionSource,
>>> HibernateSessionManager,
>>>>> HibernateTransactionDecorator and HibernateTransactionAdvisor.
>>>>> There is a configurator object (MultiHibernateEntityPackageManager)
>>> that
>>>>> is
>>>>> configured by Map<String, Collection<String>>, with the semantics
>>>>> (database-id) -> {packageName}
>>>>> By default is uses "/hibernate-«name».cfg.xml" for the

configuration.
>>>>>
>>>>> Obviously, because it's a custom object provider, the whole
lifecycle

>>>>> stuff
>>>>> doesn't apply, which is a terribly ugly hack really. Besides, it's
>>>>> absolutely not compatible with the original tapestry-hibernate-core
>>>>> module.
>>>>>
>>>>> A different issue is that the Tapestry/Hibernate (web) integration
>>> module
>>>>> also depends on Session objects, which needs to be solved at some
>> point
>>>>> (right now I just deleted them, keeping only a modified
>>>>> CommitAfterWorker,
>>>>> which works btw).
>>>>>
>>>>> All in all, this seems to work, but it's ugly and I have some

feeling
>>> I'm
>>>>> also violating Tapestry principles somewhere.
>>>>>
>>>>>
>>>>>
>>>>> A different line of thought that I am considering is using a
construct
>>>>> like
>>>>> in the Tapestry / Swing integration package, to create all services.
>>>>> There
>>>>> is still the issue of the Tapestry/Hibernate (web) integration
module
>>>>> assuming that there is only one database.
>>>>> It would have
>>>>> @InjectService("SessionOne") Session sessionOne.
>>>>>
>>>>> I don't really see how the Marker option would be implemented, but
>> this
>>>>> may
>>>>> be my lack of experience with Tapestry. You say it can be done
without

>>>>> changing the framework? At the very least, it seems Persisting /
>>>>> ValueEncoder / all that stuff would be broken.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>>
>>>>>
>>>>> Op 2-6-2010 17:23, Howard Lewis Ship schreef:
>>>>>>
>>>>>> 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<[hidden email]>
>>>>>>  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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>

---------------------------------------------------------------------

>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Massimo Lusetti]

On Mon, Oct 18, 2010 at 10:05 PM, Tom van Dijk <[hidden email]> wrote:

> I've made a report in JIRA, TAP5-1313.
>
> You may expect it to be a new functionality issue for allowing extra
> ModuleDef objects to be added, but the result is quite different, because I
> believe dynamic services really should be in the same module that wants to
> define them. Anyway, you can find it in JIRA.
>

The idea sounds interesting as a solution for your question (hibernate
multiple database).
Please would you like to elaborate a little more? Where is the real
evidence of dynamic? ...It's just dynamic in creation/construction
time?

Cheers
--
Massimo
http://meridio.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tom van Dijk]

  Op 19-10-2010 10:14, Massimo Lusetti schreef:

> On Mon, Oct 18, 2010 at 10:05 PM, Tom van Dijk<[hidden email]>  wrote:
>
>> I've made a report in JIRA, TAP5-1313.
>>
>> You may expect it to be a new functionality issue for allowing extra
>> ModuleDef objects to be added, but the result is quite different, because I
>> believe dynamic services really should be in the same module that wants to
>> define them. Anyway, you can find it in JIRA.
>>
> The idea sounds interesting as a solution for your question (hibernate
> multiple database).
> Please would you like to elaborate a little more? Where is the real
> evidence of dynamic? ...It's just dynamic in creation/construction
> time?
>
> Cheers

Yes, it is dynamic in construction time. Perhaps I should've named the
thing "runtime services" instead of "dynamic services" now you mention it.

The idea is not something that allows further adding/removing of
services after startup. It's just so that during startup extra services
can be defined.
Right now I'm rewriting tapestry-hibernate as an example. (and already
discovering I need an additional method in ObjectLocator,
getServices(serviceInterface, markers))

Cheers too.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[joshcanfield]

I was trying to take a look at your patch but I couldn't get a good merge.
Are you synch'd to the trunk?

I found the rietveld code review tool helpful (
http://codereview.appspot.com/), would you consider putting your patch there
so we can get a better look without having to download and install the
patch? I've created a tapestry5 project there.
On 19 Oct 2010 03:19, "Tom van Dijk" <[hidden email]> wrote:

[Tom van Dijk]

I used the git from Howard. I'll check the code review  tool later
today/tomorrow.

On Tue, 19 Oct 2010 08:51:19 -0700, Josh Canfield <[hidden email]>
wrote:
> I was trying to take a look at your patch but I couldn't get a good
merge.
> Are you synch'd to the trunk?
>
> I found the rietveld code review tool helpful (
> http://codereview.appspot.com/), would you consider putting your patch
> there
> so we can get a better look without having to download and install the
> patch? I've created a tapestry5 project there.
> On 19 Oct 2010 03:19, "Tom van Dijk" <[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tom van Dijk]

  Okay, I can't use that code review tool. Maybe it is because I use git
and the rest of the world (except Howard?) uses svn?

Anyway, you can pull from my git repository, it's conveniently located
downstairs in the living room.

git://hetdiana.homeip.net/tapestry5.git

I've created branch "iocmod1" and branch "iocmod2" and branch "iocmod3"
and branch "hibmod"

iocmod1 adds dynamic services
iocmod2 adds dynamic contributions
iocmod3 adds getService(serviceInterface, markers) to ObjectLocator
(what is better, Set<Class<? extends Annotation>> or Set<Class> ?)

hibmod is a work in progress, for the next couple of hours at least it
will contain my changes to tapestry-hibernate-core, without integration
testing.

If you pull branch iocmod3 you get all proposed changes to ioc core and
if you pull branch iocmod2 you get only those that don't appear to break
test cases in tapestry-core and perhaps other projects

They are rebased upon the latest trunk (including Igor's change on
@Startup annotations).

I have yet to update the diff files in JIRA, I'll get to that later.
What is the best course of action? Change to using SVN and upload SVN
diff files? I kinda like git because it lets me do all the branching and
merging with ease.



Op 19-10-2010 20:13, Tom van Dijk schreef:

> I used the git from Howard. I'll check the code review  tool later
> today/tomorrow.
>
> On Tue, 19 Oct 2010 08:51:19 -0700, Josh Canfield<[hidden email]>
> wrote:
>> I was trying to take a look at your patch but I couldn't get a good
> merge.
>> Are you synch'd to the trunk?
>>
>> I found the rietveld code review tool helpful (
>> http://codereview.appspot.com/), would you consider putting your patch
>> there
>> so we can get a better look without having to download and install the
>> patch? I've created a tapestry5 project there.
>> On 19 Oct 2010 03:19, "Tom van Dijk"<[hidden email]>  wrote:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Tom van Dijk]

If you do

git clone git://hetdiana.homeip.net/tapestry5.git -b hibmod

you get the current version. I wouldn't consider it mature enough to merge
yet, I still need to fix breaking tapestry-core and other things because of
the modification to the ObjectLocator interface and tapestry-hibernate also
needs to be modified, but tapestry-hibernate-core seems to function well.
As soon as I'm confident that everything is mature (I still found a bug in
the ioc modifications) I'll reupload the patch to JIRA.

In the test suite you can find an example of how the system would work.

There are two packages, blue and red. Both have a Module class. Both have
an annotation (@Blue and @Red). Both have an example entity. By default, it
will use /hibernate-red.cfg.xml and /hibernate-blue.cfg.xml (for marker
@ThisIsALongMarker it would use /hibernate-thisIsALongMarker.cfg.xml)

The nice thing is that, as far as I can see, unless you do weird things
(override services and stuff like that), it is backwards compatible.

Feedback would be appreciated.

Tom.



On Wed, 20 Oct 2010 00:43:10 +0200, Tom van Dijk <[hidden email]> wrote:

> Okay, I can't use that code review tool. Maybe it is because I use git
> and the rest of the world (except Howard?) uses svn?
>
> Anyway, you can pull from my git repository, it's conveniently located
> downstairs in the living room.
>
> git://hetdiana.homeip.net/tapestry5.git
>
> I've created branch "iocmod1" and branch "iocmod2" and branch "iocmod3"
> and branch "hibmod"
>
> iocmod1 adds dynamic services
> iocmod2 adds dynamic contributions
> iocmod3 adds getService(serviceInterface, markers) to ObjectLocator
> (what is better, Set<Class<? extends Annotation>> or Set<Class> ?)
>
> hibmod is a work in progress, for the next couple of hours at least it
> will contain my changes to tapestry-hibernate-core, without integration
> testing.
>
> If you pull branch iocmod3 you get all proposed changes to ioc core and
> if you pull branch iocmod2 you get only those that don't appear to break

> test cases in tapestry-core and perhaps other projects
>
> They are rebased upon the latest trunk (including Igor's change on
> @Startup annotations).
>
> I have yet to update the diff files in JIRA, I'll get to that later.
> What is the best course of action? Change to using SVN and upload SVN
> diff files? I kinda like git because it lets me do all the branching and

> merging with ease.
>
>
>
> Op 19-10-2010 20:13, Tom van Dijk schreef:
>> I used the git from Howard. I'll check the code review  tool later
>> today/tomorrow.
>>
>> On Tue, 19 Oct 2010 08:51:19 -0700, Josh
Canfield<[hidden email]>

>> wrote:
>>> I was trying to take a look at your patch but I couldn't get a good
>> merge.
>>> Are you synch'd to the trunk?
>>>
>>> I found the rietveld code review tool helpful (
>>> http://codereview.appspot.com/), would you consider putting your patch
>>> there
>>> so we can get a better look without having to download and install the
>>> patch? I've created a tapestry5 project there.
>>> On 19 Oct 2010 03:19, "Tom van Dijk"<[hidden email]>  wrote:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]