Re: JPA in mailreader
Ted, I finally had a chance to look at your JPA mailreader. I know this was in the original, but I really don't like the way that they have most of the functionality for the actions is in a superclass. To me, that's hiding functionality. (Especially when the domain model is in the super class) And this become problematic on bigger projects. Do you have multiple superclasses to extend from with different domain models? What if you need functionality from 2 different superclasses. At a certain size of project this technique breaks down and it irritates me that the standard example shows it this way. I also don't like having a separate create vs. update action. My general rule of thumb is: if the domain model is the same and the use cases are closely related, it should be the same action. I don't generally combine list and edit actions, but the create/edit/save functionality will all be in one class as would be the list/paging/sort use cases. Why are the name queries on the domain object? I don't dislike it, I'm just curious about why you took that approach. I think the validation annotations are ugly and hard to read, but others may disagree. I do like how grails uses enclosures to capture that information, can you convert this example to grails? :) I'm not a fan of having a separate interface for the Manager classes, just for the sake of having an interface. If it's unlikely that there will ever be another implementation, then it should just be a class. One argument you could make is: Well what if you switch data storage technologies? Well, we just did that in this example and the interfaces had to be redesigned, so did they really buy you anything? Again I cringe at seeing a superclass for all domain objects. I think it makes sense for the managers to have a superclass though. In my experience with big projects, having a superclass for domain objects doesn't make a lot of sense. I hope I haven't been too brutal with my comments. :) I'm so glad we finally have a mailreader example that uses JPA. A lot of what you see here is my experience from working with webwork on a large (200+ action) project. There's lots of things that seem fine on a small scale, but when you have to scale up to that size, lots of things become problematic. I'd also be curious to find out how others have structured larger projects in webwork/struts. I think that's helpful because we spent a lot of time reinventing the wheel when it comes to large project best practices. Tom Ted Husted wrote: The work-in-progress is checked into the sandbox now. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ I'll track further work through https://issues.apache.org/struts/browse/WW-1399 This is still very much a prototype, and I would gladly receive any suggestions. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
I very much appreciate the comments, Tom. Right now, I'm retreating into unit tests against the business logic. But once that's done, I'd to revisit your suggestions. I'm tempted to suggest that you go ahead and try some changes, but the application isn't fully functional right now, and we should probably fix that first. :) If anyone sees a quick fix for the persistence problems mentioned in the STATUS.txt, please feel free to make the change or submit a patch. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/STATUS.txt?view=markup Just to address a couple of points. The use case for the domain superclass is to share the code that handles the UUID primary keys. It's probably a fetish, but I seem to have an allergy to cut-and-paste reuse. :) The manager classes have an interface so that mock versions could be injected to test the actions directly, via the constructors, without engaging the persistence layer. Usually, I would have written those first, but this was a double-edged spike for me, in that I was tinkering with JPA and CodeBehind at the same time. -Ted. On Nov 21, 2007 11:20 AM, Tom Schneider [EMAIL PROTECTED] wrote: Ted, I finally had a chance to look at your JPA mailreader. I know this was in the original, but I really don't like the way that they have most of the functionality for the actions is in a superclass. To me, that's hiding functionality. (Especially when the domain model is in the super class) And this become problematic on bigger projects. Do you have multiple superclasses to extend from with different domain models? What if you need functionality from 2 different superclasses. At a certain size of project this technique breaks down and it irritates me that the standard example shows it this way. I also don't like having a separate create vs. update action. My general rule of thumb is: if the domain model is the same and the use cases are closely related, it should be the same action. I don't generally combine list and edit actions, but the create/edit/save functionality will all be in one class as would be the list/paging/sort use cases. Why are the name queries on the domain object? I don't dislike it, I'm just curious about why you took that approach. I think the validation annotations are ugly and hard to read, but others may disagree. I do like how grails uses enclosures to capture that information, can you convert this example to grails? :) I'm not a fan of having a separate interface for the Manager classes, just for the sake of having an interface. If it's unlikely that there will ever be another implementation, then it should just be a class. One argument you could make is: Well what if you switch data storage technologies? Well, we just did that in this example and the interfaces had to be redesigned, so did they really buy you anything? Again I cringe at seeing a superclass for all domain objects. I think it makes sense for the managers to have a superclass though. In my experience with big projects, having a superclass for domain objects doesn't make a lot of sense. I hope I haven't been too brutal with my comments. :) I'm so glad we finally have a mailreader example that uses JPA. A lot of what you see here is my experience from working with webwork on a large (200+ action) project. There's lots of things that seem fine on a small scale, but when you have to scale up to that size, lots of things become problematic. I'd also be curious to find out how others have structured larger projects in webwork/struts. I think that's helpful because we spent a lot of time reinventing the wheel when it comes to large project best practices. Tom Ted Husted wrote: The work-in-progress is checked into the sandbox now. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ I'll track further work through https://issues.apache.org/struts/browse/WW-1399 This is still very much a prototype, and I would gladly receive any suggestions. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
The work-in-progress is checked into the sandbox now. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ I'll track further work through https://issues.apache.org/struts/browse/WW-1399 This is still very much a prototype, and I would gladly receive any suggestions. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
I'm starting to make some progress on this again. I having great fun re-discovering how some of the S2 features work together. For example, custom type converters and persistence URL parameters are a great tag team. Given a converter for user, and a parameter like ?user=husted, S2 can automatically restore the husted user from the database, and any other url tags on the result page are also automatically embellished with ?user=husted again. Though, there's more to do, since the JPA merging isn't working quite right yet. :( -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Are you worried about optimistic locking at all? (I'm guessing not for this simple example) Although I think your technique is clever, in a situation where optimistic locking is used, you should really be editing the object that was originally read from the database. Might I suggest the scope plugin. :) I'm not sure we'd want to introduce optimistic locking in a simple example--although it would be good to have one example that uses it. Tom On Nov 15, 2007 2:54 AM, Ted Husted [EMAIL PROTECTED] wrote: I'm starting to make some progress on this again. I having great fun re-discovering how some of the S2 features work together. For example, custom type converters and persistence URL parameters are a great tag team. Given a converter for user, and a parameter like ?user=husted, S2 can automatically restore the husted user from the database, and any other url tags on the result page are also automatically embellished with ?user=husted again. Though, there's more to do, since the JPA merging isn't working quite right yet. :( -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
I'd be good with introducing optimistic locking, if we can do without complicating the design. It would be fun to have a standard example of doing something fancy like displaying both entries and letting the cilent choose one. The MailReader has always been a useful example, but it has always lacked a realistic edge. Of course, we also need to reintroduce authorization. :) AFAICT, the current design is strongly implied by a number of key Struts 2 features, like string-to-object type conversion and persistent URL attributes. I also tried using model driven, but that started to conflict with type conversion and the new i18n idioms. A key technique is accepting the notion of Transient properties as a valid approach to extending an entity object to include properties found only in the view. Since Transient is part of the JPA, the implication seems to be that entities are adapters between the one-true-model (the persisted database) and the view layer, meaning an entity object can contain properties from both worlds. Of course, whether Transient properties are a good idea is something one could take up with the expert group (along with the SQL tags in the JSTL!), but since this is a JPA MailReader, I'm comfortable adopting a JPA world view :) As mentioned, the merging is busted ATM. It was working, but then I started fussing with the high-level design. It was keeping a User and Subscription in session to edit, but that seems like such a heavy-handed restriction. -Ted. On Nov 15, 2007 10:58 AM, Tom Schneider [EMAIL PROTECTED] wrote: Are you worried about optimistic locking at all? (I'm guessing not for this simple example) Although I think your technique is clever, in a situation where optimistic locking is used, you should really be editing the object that was originally read from the database. Might I suggest the scope plugin. :) I'm not sure we'd want to introduce optimistic locking in a simple example--although it would be good to have one example that uses it. Tom On Nov 15, 2007 2:54 AM, Ted Husted [EMAIL PROTECTED] wrote: I'm starting to make some progress on this again. I having great fun re-discovering how some of the S2 features work together. For example, custom type converters and persistence URL parameters are a great tag team. Given a converter for user, and a parameter like ?user=husted, S2 can automatically restore the husted user from the database, and any other url tags on the result page are also automatically embellished with ?user=husted again. Though, there's more to do, since the JPA merging isn't working quite right yet. :( -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JPA in mailreader
I agree with using Spring. Also, using the jpaTemplate has little value as indicated in the Spring docs. Instead, use the @Repository annotation in your implementation class. Date: Mon, 12 Nov 2007 09:11:04 -0600 From: [EMAIL PROTECTED] To: dev@struts.apache.org Subject: Re: JPA in mailreader My vote is to just use spring, for both EntityManagerFactory injection and Transaction Management. As Richard and I were discussing this weekend, Spring is a very common framework when used with Struts. It will also provide a full stack Struts/Spring/JPA example. Tom On Nov 12, 2007 9:05 AM, Wes Wannemacher wrote: Hello, I've been quietly learning JPA / implementing a JPA struts2-mailreader. I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Express yourself with free Messenger emoticons. Get them today! http://www.freemessengeremoticons.ca/?icid=EMENCA122 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
I can agree with that... I'm still thinking of avoiding JpaTemplate though because they indicate that it only exists to help people used to HibernateTemplate / JdoTemplate. -Wes On 11/12/07, Tom Schneider [EMAIL PROTECTED] wrote: My vote is to just use spring, for both EntityManagerFactory injection and Transaction Management. As Richard and I were discussing this weekend, Spring is a very common framework when used with Struts. It will also provide a full stack Struts/Spring/JPA example. Tom On Nov 12, 2007 9:05 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: Hello, I've been quietly learning JPA / implementing a JPA struts2-mailreader. I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
+1 for using spring, the end result will be a lot better and with maven the dependencies are not a problem. musachy On Nov 12, 2007 10:17 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: I can agree with that... I'm still thinking of avoiding JpaTemplate though because they indicate that it only exists to help people used to HibernateTemplate / JdoTemplate. -Wes On 11/12/07, Tom Schneider [EMAIL PROTECTED] wrote: My vote is to just use spring, for both EntityManagerFactory injection and Transaction Management. As Richard and I were discussing this weekend, Spring is a very common framework when used with Struts. It will also provide a full stack Struts/Spring/JPA example. Tom On Nov 12, 2007 9:05 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: Hello, I've been quietly learning JPA / implementing a JPA struts2-mailreader. I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
I've also been working on an implementation over here: * http://sq1-struts2.googlecode.com/svn/trunk/articles/smart-urls/ that draws on the Shale MailReader JPA implementation. It's pretty close. I'm just working out a third-level update, where we need to update the Protocol object, which is part of the Subscription object, which is part of the User object :) The solution I'm working on now uses the custom type conversion features to look up the objects from the string ID. I use Spring and dependency-injection a lot, but I don't know see that injecting the EntityManager buys us very much, especially now that we have a standard API. So, Ive just been using a static class that instantiates the EM as a singleton. No big woof. I haven't been using DAOs per se. There is a Manager class for each Entity with the basic CRUD operations the application needs, and then a few helper methods on the Actions that add the error handling and such. One implementation issue is that it now assumes that we are only editing one User and one Subscription per session, and that the only User that can be edited in the logged-in user. I'd like to get away from both of those assumptions and merge It's also using the SmartURLs plugin right now, though I was planning to replace that with static mappings. I also have some notes regarding making the mappings RESTful, which is why I've already nested the namespaces. -Ted. On Nov 12, 2007 10:05 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: Hello, I've been quietly learning JPA / implementing a JPA struts2-mailreader. I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Yes, avoid JpaTemplate, just like HibernateTemplate should be avoided. Shouldn't be necessary with the latest versions of the respective frameworks. Tom On Nov 12, 2007 9:17 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: I can agree with that... I'm still thinking of avoiding JpaTemplate though because they indicate that it only exists to help people used to HibernateTemplate / JdoTemplate. -Wes On 11/12/07, Tom Schneider [EMAIL PROTECTED] wrote: My vote is to just use spring, for both EntityManagerFactory injection and Transaction Management. As Richard and I were discussing this weekend, Spring is a very common framework when used with Struts. It will also provide a full stack Struts/Spring/JPA example. Tom On Nov 12, 2007 9:05 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: Hello, I've been quietly learning JPA / implementing a JPA struts2-mailreader. I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
I'll finish up the Plain-Old-JPA version and check it into the sandbox. If someone wants to followup with a better Spring version, I'd love to see it :) -Ted. On Nov 12, 2007 10:19 AM, Musachy Barroso [EMAIL PROTECTED] wrote: +1 for using spring, the end result will be a lot better and with maven the dependencies are not a problem. musachy On Nov 12, 2007 10:17 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: I can agree with that... I'm still thinking of avoiding JpaTemplate though because they indicate that it only exists to help people used to HibernateTemplate / JdoTemplate. -Wes On 11/12/07, Tom Schneider [EMAIL PROTECTED] wrote: My vote is to just use spring, for both EntityManagerFactory injection and Transaction Management. As Richard and I were discussing this weekend, Spring is a very common framework when used with Struts. It will also provide a full stack Struts/Spring/JPA example. Tom On Nov 12, 2007 9:05 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: Hello, I've been quietly learning JPA / implementing a JPA struts2-mailreader. I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
On 11/12/07, Ted Husted [EMAIL PROTECTED] wrote: I use Spring and dependency-injection a lot, but I don't know see that injecting the EntityManager buys us very much, especially now that we have a standard API. So, Ive just been using a static class that instantiates the EM as a singleton. No big woof. I would be careful, Ted, there is a one-to-one relationship with the EM and the transaction - http://openjpa.apache.org/docs/latest/manual/jpa_overview_em.html I'll finish up this persistence layer (DAOs / Entities) today or tomorrow and put it out somewhere for you to take a look at. I don't mind if we don't use what I've got, since it's really more about me learning JPA than anything else. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Quite right. There's a static EntityManagerHelper that returns a fresh EM for each transaction. I think it would be great to have a couple of implementations to compare! If you'd like to park it at the sq1-struts2 site for now, just let me know your google ID. -Ted. On Nov 12, 2007 10:28 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: On 11/12/07, Ted Husted [EMAIL PROTECTED] wrote: I use Spring and dependency-injection a lot, but I don't know see that injecting the EntityManager buys us very much, especially now that we have a standard API. So, Ive just been using a static class that instantiates the EM as a singleton. No big woof. I would be careful, Ted, there is a one-to-one relationship with the EM and the transaction - http://openjpa.apache.org/docs/latest/manual/jpa_overview_em.html I'll finish up this persistence layer (DAOs / Entities) today or tomorrow and put it out somewhere for you to take a look at. I don't mind if we don't use what I've got, since it's really more about me learning JPA than anything else. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
I think [EMAIL PROTECTED] should work as a google Id, if not, use [EMAIL PROTECTED] I don't have much, but it'd be nice to have a repository. -Wes On 11/12/07, Ted Husted [EMAIL PROTECTED] wrote: Quite right. There's a static EntityManagerHelper that returns a fresh EM for each transaction. I think it would be great to have a couple of implementations to compare! If you'd like to park it at the sq1-struts2 site for now, just let me know your google ID. -Ted. On Nov 12, 2007 10:28 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: On 11/12/07, Ted Husted [EMAIL PROTECTED] wrote: I use Spring and dependency-injection a lot, but I don't know see that injecting the EntityManager buys us very much, especially now that we have a standard API. So, Ive just been using a static class that instantiates the EM as a singleton. No big woof. I would be careful, Ted, there is a one-to-one relationship with the EM and the transaction - http://openjpa.apache.org/docs/latest/manual/jpa_overview_em.html I'll finish up this persistence layer (DAOs / Entities) today or tomorrow and put it out somewhere for you to take a look at. I don't mind if we don't use what I've got, since it's really more about me learning JPA than anything else. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
wes@ seemed to work. You could just add something off the trunk for now. Just as an aside, in my own stuff, I don't consider serving the current MailReader API unchanged a target goal. The current implementation is working around some arbitrary restictions in the old DAO, and there's no compelling reason to carry that sort of thing forward. It looks and feels the same to the user, but the internals are being aligned with the JPA. -Ted. On Nov 12, 2007 2:42 PM, Wes Wannemacher [EMAIL PROTECTED] wrote: I think [EMAIL PROTECTED] should work as a google Id, if not, use [EMAIL PROTECTED] I don't have much, but it'd be nice to have a repository. -Wes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Wes Wannemacher on 12/11/07 15:05, wrote: I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. Hi Wes, didn't we chat on the OpenJPA list about this when we were both getting into the subject over the weekend? I haven't had time to finish my implementation of JPA + S2 yet but I'm getting close. I think your initial instinct to keep Spring to limited use only is good, since adopting the Spring framework without enough consideration invariably leads to a completely 'Springified' app which then creates immense inertia against moving it in any other direction. One thing that interests me is the ability to plug in any IoC container, but as you point out it's the transaction management which is key and it's foxing me at the moment. I've tried the hard-coding route - I ended up with 10 lines of code for every method of which only one was business code and then gave up because I don't want to write my own transaction management framework. I'm currently struggling to use Spring but without giving in to its demands to add in DAO superclasses and so forth. Unfortunately outside EJB containers, the only transaction management framework I know is Spring and it's not exactly snap-on. Presumably for the mail-reader it's sufficient to use transaction management in the OpenSessionInView, hard-coded with only one type of transaction with no authorisation management? Regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
http://www.atomikos.com/products.html#ate And whatever happened to JOTM, anyway? d. --- Adam Hardy [EMAIL PROTECTED] wrote: Wes Wannemacher on 12/11/07 15:05, wrote: I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. Hi Wes, didn't we chat on the OpenJPA list about this when we were both getting into the subject over the weekend? I haven't had time to finish my implementation of JPA + S2 yet but I'm getting close. I think your initial instinct to keep Spring to limited use only is good, since adopting the Spring framework without enough consideration invariably leads to a completely 'Springified' app which then creates immense inertia against moving it in any other direction. One thing that interests me is the ability to plug in any IoC container, but as you point out it's the transaction management which is key and it's foxing me at the moment. I've tried the hard-coding route - I ended up with 10 lines of code for every method of which only one was business code and then gave up because I don't want to write my own transaction management framework. I'm currently struggling to use Spring but without giving in to its demands to add in DAO superclasses and so forth. Unfortunately outside EJB containers, the only transaction management framework I know is Spring and it's not exactly snap-on. Presumably for the mail-reader it's sufficient to use transaction management in the OpenSessionInView, hard-coded with only one type of transaction with no authorisation management? Regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA in mailreader
Atomikos was apparently open source, but definitely not community software. I couldn't find any tutorials - presumably the company has a commercial model driven by income from paid-for support which they want everyone to buy, including all of us developers. JOTM is interesting. No fresh news on their site homepage for 2 1/2 years, but their jars are on the maven repository and are dependencies of a dozen different Spring jars! Interesting. Perhaps there is a sign of life there. Dave Newton on 12/11/07 22:07, wrote: http://www.atomikos.com/products.html#ate And whatever happened to JOTM, anyway? d. --- Adam Hardy [EMAIL PROTECTED] wrote: Wes Wannemacher on 12/11/07 15:05, wrote: I have a judgment call to make now and wanted some input. At first I was hoping to create this in a non-IoC fashion. This was simply to keep the dependencies at a minimum and concentrate on integrating JPA and struts2. But, in many spots, the JPA docs indicate that the EntityManagerFactory should be injected (although it isn't that hard to instantiate by hand). I've thought about using Spring, which will make things pretty easy with it's transaction management and DI. It has been suggested to me to use the JpaTemplate, but while I was reading the JavaDoc for it - http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html It indicates that new projects should use a DAO with a shared EM injected. If I make DAOs, I may skip Spring altogether. Also, I could do the transaction management in the DAO implementations or try to hook into the transactional management of an ee server. If I manage the transactions myself, it will make mailreader work in non-ee servers as well. However, if this is a best-practices example, I should probably use the ee server. What do you guys think will be the best approach. Hi Wes, didn't we chat on the OpenJPA list about this when we were both getting into the subject over the weekend? I haven't had time to finish my implementation of JPA + S2 yet but I'm getting close. I think your initial instinct to keep Spring to limited use only is good, since adopting the Spring framework without enough consideration invariably leads to a completely 'Springified' app which then creates immense inertia against moving it in any other direction. One thing that interests me is the ability to plug in any IoC container, but as you point out it's the transaction management which is key and it's foxing me at the moment. I've tried the hard-coding route - I ended up with 10 lines of code for every method of which only one was business code and then gave up because I don't want to write my own transaction management framework. I'm currently struggling to use Spring but without giving in to its demands to add in DAO superclasses and so forth. Unfortunately outside EJB containers, the only transaction management framework I know is Spring and it's not exactly snap-on. Presumably for the mail-reader it's sufficient to use transaction management in the OpenSessionInView, hard-coded with only one type of transaction with no authorisation management? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
