You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ted Husted <hu...@apache.org> on 2007/11/16 11:36:39 UTC
[S2] Struts/JPA Design Practices
Over on dev@, a couple of us are working on a JPA MailReader. Rather
than just try and port the old version, we're also refactoring the
internal design so that it's more in line with the JPA overall.
I know the JPA is growing in popularlity among Struts developers. I
was wondering if there are certain Struts 2 features that people where
finding useful in using JPA or Hibernate 3 with Struts 2. Are you
using custom interceptors?, type converters?, Spring?, Guice?,
model-driven? the scope plugin? Something else? Any slick, reusable
workflows for handling optimistic locking collisions?
Of course, I expect Struts 1 developers may also be moving to the JPA
too. Any S1 war stories would be interesting too.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Struts/JPA Design Practices
Posted by Ted Husted <hu...@apache.org>.
On Nov 16, 2007 11:09 AM, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> To answer your question, I haven't had to do much to plug in OpenJPA and Struts2
> together - in fact, I haven't had to do anything apart from decide whether I
> wanted to have a filter or a Struts2 interceptor or a Spring interceptor for
> OpenEntityManagerInView.
>
> I chose the filter because it implements a standard (Servlet) and would cater
> for DWR integration too.
I started with an Inteceptor, but now I'm thinking of a filter too,
since, as you say, it would support service-type uses, like DWR or
XFire.
If you'd like to share your filter implementation, feel free to attach
it to https://issues.apache.org/struts/browse/WW-1399
> Concerning optimistic locking, I've got version fields on all my persistent
> objects, mapped to version columns. I haven't got this whole thing working yet
> since it's in the process of migrating from Spring MVC / non-JPA Hibernate and
> there's alot of testing framework code to put through the mangler first. So I've
> yet to overhaul the versioning or the identity fields (praying for smooth passage).
I'm thinking that it would be nice to have some sort of stock Result
that could be used in the event of a optimistic locking exception, and
at least try to display the affected values, or perhaps even offer to
recover if the edit values are not the same ones that the other user
changed.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Struts/JPA Design Practices
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Hi Ted,
I'm developing a framework (which someone else called 'featherweight') to
integrate 'your package of choice' of IoC, JPA, transaction management,
domain-driven tiers and servlet MVC without EJB.
To answer your question, I haven't had to do much to plug in OpenJPA and Struts2
together - in fact, I haven't had to do anything apart from decide whether I
wanted to have a filter or a Struts2 interceptor or a Spring interceptor for
OpenEntityManagerInView.
I chose the filter because it implements a standard (Servlet) and would cater
for DWR integration too.
Concerning optimistic locking, I've got version fields on all my persistent
objects, mapped to version columns. I haven't got this whole thing working yet
since it's in the process of migrating from Spring MVC / non-JPA Hibernate and
there's alot of testing framework code to put through the mangler first. So I've
yet to overhaul the versioning or the identity fields (praying for smooth passage).
regards
Adam
Ted Husted on 16/11/07 10:36, wrote:
> Over on dev@, a couple of us are working on a JPA MailReader. Rather
> than just try and port the old version, we're also refactoring the
> internal design so that it's more in line with the JPA overall.
>
> I know the JPA is growing in popularlity among Struts developers. I
> was wondering if there are certain Struts 2 features that people where
> finding useful in using JPA or Hibernate 3 with Struts 2. Are you
> using custom interceptors?, type converters?, Spring?, Guice?,
> model-driven? the scope plugin? Something else? Any slick, reusable
> workflows for handling optimistic locking collisions?
>
> Of course, I expect Struts 1 developers may also be moving to the JPA
> too. Any S1 war stories would be interesting too.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Struts/JPA Design Practices
Posted by Ted Husted <hu...@apache.org>.
> Hopefully that's the sort of stuff you're interested in hearing about.
Yes, thanks!
By "custom interceptors" I meant strategies like Open Session In View,
which can be used to implement One Transaction Per Request
* http://struts.apache.org/2.0.11/docs/non-ioc-version-of-opensessioninviewinterceptor.html
* http://struts.apache.org/2.x/docs/hibernateandspringenabledexecuteandwaitinterceptor.html
* http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/hibernate3/HibernateInterceptor.html
* http://struts.apache.org/2.x/docs/adminapp.html
I've seen various other references on the list to people using custom
interceptors to help with data access.
> We do find that doing the params/prepare/params interceptor sandwich is
> a fairly elegant way to hydrate from a form-provided ID and then let
> other fields inject into that newly hyrdated object on the second params
> pass.
Yes, that does work well. The type converters can be used to do the
same sort of thing. For example, to hydrate (and dehydrate) a entity
based on a primary key, we can do something like this
public Object convertFromString(Map context, String[] values,
Class toClass) {
ProtocolManagerInterface manager = new ProtocolManager();
String id = values[0];
Protocol target = manager.find(id);
return target;
}
public String convertToString(Map context, Object o) {
Protocol value = (Protocol) o;
String id = value.getId();
return id;
}
This tells the framework to write out the primary key when the
Protocol object is referenced in a JSP, and then, on the way back, to
lookup the Protocol object using the key.
If an Action has a reference to, say, a User object, we can do things like
<s:hidden name="user"/>
<s:textfield key="user.fullName"/>
<s:textfield key="user.fromAddress"/>
In which case, the framework will first hydrate the user object (the
string ID will be written out at the hidden field), and then update
the user's properties.
Of course, if the user field were left out, the framework will simply
create a blank user object (automatic lazy instantiation).
Elegant indeed :)
-Ted.
On Nov 17, 2007 1:00 AM, Gary Affonso <gl...@greywether.com> wrote:
> Ted Husted wrote:
> > I know the JPA is growing in popularlity among Struts developers. I
> > was wondering if there are certain Struts 2 features that people where
> > finding useful in using JPA or Hibernate 3
>
> For us it's Hibernate 3 still. We'll be moving to JPA in the code (with
> Hibernate as the underlying implementation) soon.
>
> > with Struts 2. Are you
> > using custom interceptors?
>
> Er, why?
>
> Or, more specifically, yah we have some customer interceptors, they
> don't have anything to do with our persistence layer, though.
>
> We are using Spring's OSIV filter if that's of interest to you.
>
> >, type converters?
>
> Nothing related to persistence.
>
> > Spring?
>
> Absolutely, and heavily. Spring for DI, DAO layer, service layer,
> integration testing, Spring AOP for the fault barrier (advice on the
> execute method of the Actions) and various Spring "utilities" like the
> scheduling integration.
>
> > model-driven?
>
> I don't find the "formal" model driven stuff in S2 to be of much benefit
> ("formal" meaning the interceptor combined with a getModel method
> implementation in the Actions).
>
> But we do a lot of direct-injection into model objects from the view
> layer simply using OGNL expressions for our field names and ensuring the
> model-object is a property of the action with getters/setters. Most of
> the model objects we inject into (from forms in the view) are persisted.
>
> We do find that doing the params/prepare/params interceptor sandwich is
> a fairly elegant way to hydrate from a form-provided ID and then let
> other fields inject into that newly hyrdated object on the second params
> pass.
>
> > the scope plugin?
>
> Not quite yet. But very soon.
>
> I've been seriously playing with WebFlow and will probably use *some*
> sort of framework-provided scoping very soon (WebFlow or the scope
> plug-in). I'm soooo tired of managing conversation scopes by hand.
>
> ---
>
>
> Hopefully that's the sort of stuff you're interested in hearing about.
>
> - Gary
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Struts/JPA Design Practices
Posted by Gary Affonso <gl...@greywether.com>.
Ted Husted wrote:
> I know the JPA is growing in popularlity among Struts developers. I
> was wondering if there are certain Struts 2 features that people where
> finding useful in using JPA or Hibernate 3
For us it's Hibernate 3 still. We'll be moving to JPA in the code (with
Hibernate as the underlying implementation) soon.
> with Struts 2. Are you
> using custom interceptors?
Er, why?
Or, more specifically, yah we have some customer interceptors, they
don't have anything to do with our persistence layer, though.
We are using Spring's OSIV filter if that's of interest to you.
>, type converters?
Nothing related to persistence.
> Spring?
Absolutely, and heavily. Spring for DI, DAO layer, service layer,
integration testing, Spring AOP for the fault barrier (advice on the
execute method of the Actions) and various Spring "utilities" like the
scheduling integration.
> model-driven?
I don't find the "formal" model driven stuff in S2 to be of much benefit
("formal" meaning the interceptor combined with a getModel method
implementation in the Actions).
But we do a lot of direct-injection into model objects from the view
layer simply using OGNL expressions for our field names and ensuring the
model-object is a property of the action with getters/setters. Most of
the model objects we inject into (from forms in the view) are persisted.
We do find that doing the params/prepare/params interceptor sandwich is
a fairly elegant way to hydrate from a form-provided ID and then let
other fields inject into that newly hyrdated object on the second params
pass.
> the scope plugin?
Not quite yet. But very soon.
I've been seriously playing with WebFlow and will probably use *some*
sort of framework-provided scoping very soon (WebFlow or the scope
plug-in). I'm soooo tired of managing conversation scopes by hand.
---
Hopefully that's the sort of stuff you're interested in hearing about.
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org