tapestry-hibernate + tapestry-cdi

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

tapestry-hibernate + tapestry-cdi

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

> What about exclude tapestries default hibernate dependency with Maven exclude?
>
> Sent from my iPhone
>
>> On 23 Sep 2016, at 09:05, Adam X <[hidden email]> 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: [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]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tapestry-hibernate + tapestry-cdi

kaosko
In reply to this post by Adam X
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Loading...