Re: Tapestry 5.4.1, MessageFormatter gone?
Just the packaging has changed, add dependency to commons: org.apache.tapestry commons 5.4.1 Kalle On Fri, Sep 23, 2016 at 3:13 PM, Charles Roth wrote: > Apologies in advance if I'm posting this incorrectly (in which case I > welcome a link to any Tapestry-specific etiquette guide) -- my first post > to this list. > > We are experimenting with upgrading from Tapestry 5.3.6 to 5.4.1, as part > of our move from Java 7 to Java 8. > > The interface org.apache.tapestry5.ioc.MessageFormatter seems to have > disappeared. Yet it is still listed, e.g. at > https://ci.apache.org/projects/tapestry/current/apidocs/org/ > apache/tapestry5/ioc/MessageFormatter.html > > When I look at the ivy dependency details (org.apache.tapestry, > tapestry-ioc, rev 5.4.1), I see the jar tapestry-ioc-5.4.1.jar, but package > org.apache.tapestry5.ioc does not contain MessageFormatter. If I download > the jar directly from http://mvnrepository.com/artif > act/org.apache.tapestry/tapestry-ioc/5.4.1, and look at it manually with > "jar tvf", there's no MessageFormatter. > > Has that interface been removed and replaced with something else? If so, > why would it still show up in the doc (1st link I referenced?) Or am I > simply doing something stupid? :-) > > TIA. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Tapestry 5.4.1, MessageFormatter gone?
Apologies in advance if I'm posting this incorrectly (in which case I welcome a link to any Tapestry-specific etiquette guide) -- my first post to this list. We are experimenting with upgrading from Tapestry 5.3.6 to 5.4.1, as part of our move from Java 7 to Java 8. The interface org.apache.tapestry5.ioc.MessageFormatter seems to have disappeared. Yet it is still listed, e.g. at https://ci.apache.org/projects/tapestry/current/apidocs/org/apache/tapestry5/ioc/MessageFormatter.html When I look at the ivy dependency details (org.apache.tapestry, tapestry-ioc, rev 5.4.1), I see the jar tapestry-ioc-5.4.1.jar, but package org.apache.tapestry5.ioc does not contain MessageFormatter. If I download the jar directly from http://mvnrepository.com/artifact/org.apache.tapestry/tapestry-ioc/5.4.1, and look at it manually with "jar tvf", there's no MessageFormatter. Has that interface been removed and replaced with something else? If so, why would it still show up in the doc (1st link I referenced?) Or am I simply doing something stupid? :-) TIA. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tapestry-hibernate + tapestry-cdi
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 tapestry-hibernate in my pom.xml, broke my app as my foo dependency could no longer bootstrap ITS hibernat
Re: tapestry-hibernate + tapestry-cdi
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
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
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
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
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
tapestry-hibernate + tapestry-cdi
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