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

Reply via email to