You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wes Wannemacher <we...@wantii.com> on 2007/11/12 16:05:51 UTC
JPA in mailreader
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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 <mu...@gmail.com> 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 <we...@wantii.com> 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 <sc...@gmail.com> 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 <we...@wantii.com> 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: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > --
> >
> > Wesley Wannemacher
> > President, Head Engineer/Consultant
> > WanTii, Inc.
> > http://www.wantii.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Musachy Barroso <mu...@gmail.com>.
+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 <we...@wantii.com> 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 <sc...@gmail.com> 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 <we...@wantii.com> 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
>
> Wesley Wannemacher
> President, Head Engineer/Consultant
> WanTii, Inc.
> http://www.wantii.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Musachy Barroso <mu...@gmail.com>.
I haven't used JpaTemplate at all so far.
musachy
On Nov 12, 2007 10:22 AM, Tom Schneider <sc...@gmail.com> wrote:
> 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 <we...@wantii.com> 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 <sc...@gmail.com> 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 <we...@wantii.com> 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: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > --
> >
> > Wesley Wannemacher
> > President, Head Engineer/Consultant
> > WanTii, Inc.
> > http://www.wantii.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Tom Schneider <sc...@gmail.com>.
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 <we...@wantii.com> 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 <sc...@gmail.com> 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 <we...@wantii.com> 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
>
> Wesley Wannemacher
> President, Head Engineer/Consultant
> WanTii, Inc.
> http://www.wantii.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Wes Wannemacher <we...@wantii.com>.
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 <sc...@gmail.com> 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 <we...@wantii.com> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Wesley Wannemacher
President, Head Engineer/Consultant
WanTii, Inc.
http://www.wantii.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: JPA in mailreader
Posted by Bob Tiernay <bt...@hotmail.com>.
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: schneidh@gmail.com
> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
_________________________________________________________________
Express yourself with free Messenger emoticons. Get them today!
http://www.freemessengeremoticons.ca/?icid=EMENCA122
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Tom Schneider <sc...@gmail.com>.
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 <we...@wantii.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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 <sc...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Tom Schneider <sc...@gmail.com>.
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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 <sc...@gmail.com> 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 <hu...@apache.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Tom Schneider <sc...@gmail.com>.
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 <hu...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Atomikos tutorials
Posted by Guy Pardon <fo...@opensymphony.com>.
Hi,
We (Atomikos) are still open source and we _are_ working on a tutorial/wiki at http://wiki.atomikos.org
However, this is a lot of work and it is still in progress. If you would like to help, feel free to register.
Then there are also the PDF manuals and examples that you get for free in the download. Actually, most people who download tell us these are more than enough to get started, so...
Best,
Guy
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=159095&messageID=240086#240086
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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 <ah...@cyberspaceroad.com>
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Dave Newton <ne...@yahoo.com>.
http://www.atomikos.com/products.html#ate
And whatever happened to JOTM, anyway?
d.
--- Adam Hardy <ah...@cyberspaceroad.com>
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:
> dev-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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 <we...@wantii.com> wrote:
> I think wesw@wantii.com should work as a google Id, if not, use
> techgeek@gmail.com. I don't have much, but it'd be nice to have a
> repository.
>
> -Wes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Wes Wannemacher <we...@wantii.com>.
I think wesw@wantii.com should work as a google Id, if not, use
techgeek@gmail.com. I don't have much, but it'd be nice to have a
repository.
-Wes
On 11/12/07, Ted Husted <hu...@apache.org> 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 <we...@wantii.com> wrote:
> > On 11/12/07, Ted Husted <hu...@apache.org> 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, I"ve 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> HTH, Ted <http://www.husted.com/ted/blog/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Wesley Wannemacher
President, Head Engineer/Consultant
WanTii, Inc.
http://www.wantii.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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 <we...@wantii.com> wrote:
> On 11/12/07, Ted Husted <hu...@apache.org> 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, I"ve 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Wes Wannemacher <we...@wantii.com>.
On 11/12/07, Ted Husted <hu...@apache.org> 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, I"ve 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: JPA in mailreader
Posted by Ted Husted <hu...@apache.org>.
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 <we...@wantii.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org