Re: tapestry-hibernate + tapestry-cdi

[Adam X]

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

Re: tapestry-hibernate + tapestry-cdi

[Qbyte Consulting]

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

Re: tapestry-hibernate + tapestry-cdi

[Adam X]

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

Re: tapestry-hibernate + tapestry-cdi

[Kalle Korhonen]

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

Re: tapestry-hibernate + tapestry-cdi

[Adam X]

Yep, like I said, that part is easy and I believe I can get that
resolved. My question is how to tell Tapestry that @Inject Session is
done by foo+tapestry-cdi and it should use @Inject @Named Session
instead?

On Fri, Sep 23, 2016 at 10:13 AM, Qbyte Consulting
 wrote:
> What about exclude tapestries default hibernate dependency with Maven exclude?
>
> Sent from my iPhone
>
>> On 23 Sep 2016, at 09:05, Adam X  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

Re: tapestry-hibernate + tapestry-cdi

[Qbyte Consulting]

What about exclude tapestries default hibernate dependency with Maven exclude?

Sent from my iPhone

> On 23 Sep 2016, at 09:05, Adam X  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