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, I"ve 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]
