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
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 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
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
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
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
: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
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
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
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
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
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
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
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,
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.
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
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
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
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
19 matches
Mail list logo
