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]
