Problem solved. Just to give back to the community here is how I solved it and what I've learned.
First, it looks like when using tapestry-cdi in the project, tapestry-hibernate becomes completely unnecessary. In fact, it cannot and should not be used. In general, with JSR-330 (tapestry even implements it), I think tapestry-hibernate can be deprecated. So, I stayed with: foo weld tapestry-core tapestry-cdi Then, I submitted a patch to our foo team to introduce a CDI marker on hibernate Session and SessionFactory producer methods. Before they had: @Produces @ApplicationScoped private SessionFactory produceSessionFactory() { .. } @Produces @RequestScoped private Session produceHibernateSession() { .. } I patched it with: @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.TYPE, ElementType.METHOD}) public @interface FooSessionFactory {} @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.TYPE, ElementType.METHOD}) public @interface FooSession {} @Produces @FooSessionFactory @ApplicationScoped private SessionFactory produceSessionFactory() { .. } @Produces @FooSession @RequestScoped private Session produceHibernateSession() { .. } They integrated patch ASAP and with a foo hotfix I was able to introduce my own bean factory with produces for my own "bar" database: @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.TYPE, ElementType.METHOD}) public @interface BarSessionFactory {} @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.TYPE, ElementType.METHOD}) public @interface BarSession {} class TapestryCdiBeanFactory { @Produces @BarSessionFactory @ApplicationScoped private SessionFactory produceSessionFactory() { .. } @Produces @BarSession @RequestScoped private Session produceHibernateSession() { .. } } and now in my pages I can differentiate esily between the two sessions :) class Page1 { @Inject @BarSession Session barSession; @Inject @FooSession Session fooSession; } The only downside to this is lack of helpers such as @CommitAfter. But that can be alleviated with CDI as well, as I can have an AbstractDao that @Injects a session and closes it in @PreDestroy. Adam On Fri, Sep 23, 2016 at 10:41 AM, Qbyte Consulting <qbyteconsult...@gmail.com> wrote: > Ive been using tapestry jpa on an application that accesses 3 databases, 1 > Postgres and 2 mssql. It's just fine. Surprised tapestry hibernate doesn't > support this. > > Sent from my iPhone > >> On 23 Sep 2016, at 09:36, Adam X <vbgnm3c...@gmail.com> wrote: >> >> Yes, JPA should an option. I don't think foo uses a single hibernate >> annotation and our foo team often brags how they code to the spec :) >> >> So I will try tapestry-jpa (didn't even know about it). If that >> doesn't solve the problem I will try implementing @Session. >> >> I may come back with this if I still have problems :) >> >> On Fri, Sep 23, 2016 at 10:15 AM, Kalle Korhonen >> <kalle.o.korho...@gmail.com> wrote: >>> AFAIK, tapestry-hibernate simply doesn't support it. However, is switching >>> to JPA an option? You could still be using Hibernate as the provider. >>> tapestry-jpa merrily supports multi tenancy (and more). If JPA is not an >>> option, I'd look into implementing your own custom @Session - may not be >>> too bad - there isn't that much code in tapestry-hibernate. That would >>> resolve the version mismatch - since Hibernate is pretty finicky about it, >>> you could just build against the version of your choice. >>> >>> Kalle >>> >>>> On Fri, Sep 23, 2016 at 1:05 AM, Adam X <vbgnm3c...@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I have what seems like a major collision problem and don't know how to >>>> solve this. My current architecture is as following: >>>> >>>> foo >>>> weld >>>> tapestry-cdi >>>> tapestry-core >>>> >>>> I'd like to have: >>>> >>>> foo >>>> weld >>>> tapestry-cdi >>>> tapestry-hibernate >>>> >>>> foo (jar) is a major depenency of my project. It is an internal >>>> company framework which contains all the business logic, services, >>>> daos, etc etc. It it's only dependency is JSR-330 (cdi) as all >>>> services are CDI managed beans. It allows me to easily operate on AWS >>>> cloud (we're using DynamoDB, SNS, S3, IAM) as well as internal >>>> relational db (backed by hibernate). After integrating tapestry-cdi >>>> things work beautifully, as in my page classes I can do things like: >>>> >>>> @Inject >>>> private TxDynamoDao dao; >>>> >>>> or even >>>> >>>> @Inject >>>> private Session session; >>>> >>>> without tapestry-hibernate at all. In otherwords, my foo dependency >>>> bootstraps hibernate and makes session available to my tapestry app. >>>> >>>> But now, I want to introduce a separate relational db specific to my >>>> project. Since I thought a lot about on my way to work in recent days, >>>> I expected some sort of collision. Sure enough, merely changing >>>> tapestry-core to tapestry-hibernate in my pom.xml, broke my app as my >>>> foo dependency could no longer bootstrap ITS hibernate. But I think in >>>> the grand schema of things it's a problem I could manage to get fixed >>>> as in the stack trace I noticed things like class not found, so >>>> tapestry-hibernate probably brought in some unwanted dependencies (our >>>> foo uses hibernate 5.0.7 and tapestry-hibernate wants to bring 4.x). >>>> >>>> But let's assume that we could get past this initial problem. How do I >>>> proceed then? How do I tell Tapestry that: >>>> >>>> @Inject >>>> private Session session; >>>> >>>> is a no-no, because it belongs to foo, and rather I'd like to do something >>>> like: >>>> >>>> @Inject @Named("tapestry-hibernate-session") >>>> private Session session; >>>> >>>> Adam >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org