You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Uwe Schäfer <sc...@thomas-daily.de> on 2007/11/09 13:52:30 UTC
JPA best-practices?
hi
i plan to use JPA together with Wicket. Are there any battle-proven
best-practices out there of how to handle EnityManagers and Transactions?
What do other people use (no, not the spring crowd ;) ?
One EntityManager per Request seems to be the obvious idea and a guice
Provider may help with that. Does anyone have serious experiences with
that or other suggestions?
cu uwe
--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E schaefer@thomas-daily.de
www.thomas-daily.de
Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Uwe Schäfer <sc...@thomas-daily.de>.
Nino Saturnino Martinez Vazquez Wael schrieb:
> That could be great, that way we could support each other.. Do you have
> an idea on how to get started?
i´ll contact you in private on sunday.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
That could be great, that way we could support each other.. Do you have
an idea on how to get started?
regards Nino
Uwe Schäfer wrote:
> Nino Saturnino Martinez Vazquez Wael schrieb:
>> Im actually about to write a tutorial thing about howto
>> JPA-HIBERNATE-SPRING in wicket... It could be something worth looking
>> at, Im trying to have a clean seperation of domain / database and
>> frontend (wicket).
>
> interesting. i could write a WICKET-JPA-GUICE thingy. Maybe we could
> join efforts?
>
> cu uwe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Uwe Schäfer <sc...@thomas-daily.de>.
Nino Saturnino Martinez Vazquez Wael schrieb:
> Im actually about to write a tutorial thing about howto
> JPA-HIBERNATE-SPRING in wicket... It could be something worth looking
> at, Im trying to have a clean seperation of domain / database and
> frontend (wicket).
interesting. i could write a WICKET-JPA-GUICE thingy. Maybe we could
join efforts?
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Im actually about to write a tutorial thing about howto
JPA-HIBERNATE-SPRING in wicket... It could be something worth looking
at, Im trying to have a clean seperation of domain / database and
frontend (wicket).
A few things that seems cant be seperated, the
openEntityManagerInView(in your web.xml) filter and spring context has
to get loaded via wicket spring packaged, otherwise than that its nice
to work with:)
regards Nino
Al Maw wrote:
> Uwe Schäfer wrote:
>>> Subclass WebRequestCycle, and construct it with an EntityManager.
>>
>> thanks! That may well be an alternative to the common
>> ServletFilter-pattern.
>
> Well, err, yes. ;-)
>
>> One question: isn´t it a little better to have the ThreadLocal Holder
>> for the EntityManager separate from the RequestCycle, but notified of
>> its events? Somewhat a 'listener' that registers itself ?
>
> If you have one, then sure. Whatever feels cleanest to you. There is
> no single best way with all this stuff.
>
> My DAOs actually use Spring's HibernateTemplate, so getting hold of a
> session in there is done using sessionFactory.getCurrentSession().
> It's a bit different in your case with JPA stuff.
>
>> This would decouple things as well as make configuration at runtime
>> easier. (The 'Favor decoration over inheritance' thing.)
>>
>> What am i missing?
>
> Nothing, it sounds like. ;-)
>
> Regards,
>
> Al
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Al Maw <wi...@almaw.com>.
Uwe Schäfer wrote:
>> Subclass WebRequestCycle, and construct it with an EntityManager.
>
> thanks! That may well be an alternative to the common
> ServletFilter-pattern.
Well, err, yes. ;-)
> One question: isn´t it a little better to have the ThreadLocal Holder
> for the EntityManager separate from the RequestCycle, but notified of
> its events? Somewhat a 'listener' that registers itself ?
If you have one, then sure. Whatever feels cleanest to you. There is no
single best way with all this stuff.
My DAOs actually use Spring's HibernateTemplate, so getting hold of a
session in there is done using sessionFactory.getCurrentSession(). It's
a bit different in your case with JPA stuff.
> This would decouple things as well as make configuration at runtime
> easier. (The 'Favor decoration over inheritance' thing.)
>
> What am i missing?
Nothing, it sounds like. ;-)
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Uwe Schäfer <sc...@thomas-daily.de>.
Al Maw schrieb:
Hi Al
> Subclass WebRequestCycle, and construct it with an EntityManager.
thanks! That may well be an alternative to the common
ServletFilter-pattern.
One question: isn´t it a little better to have the ThreadLocal Holder
for the EntityManager separate from the RequestCycle, but notified of
its events? Somewhat a 'listener' that registers itself ?
This would decouple things as well as make configuration at runtime
easier. (The 'Favor decoration over inheritance' thing.)
What am i missing?
--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E schaefer@thomas-daily.de
www.thomas-daily.de
Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Francis De Brabandere <fr...@gmail.com>.
On Nov 16, 2007 8:02 PM, Korbinian Bachl <ko...@whiskyworld.de> wrote:
> > That project needs an update for 1.3
> > Add wicket-ioc dep / remove spring dep + some other unneeded deps /
> > fix package names, I contacted the author but got no response.
> > Plus you have to define all beans in the web.xml which is not needed
> > when you work with jsf for example (tested on glassfish). Does anybody
> > know why that is?
>
> err, you need to checkout the trunk version for 1.3, built is for 1.2 !
> the trunk works perfect with 1.3, but its noted on the page AFAIK
>
hmm, the pom still needs an update to use ioc instead of swing + what
are those servlet/portlet api dependencies doing there?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Francis De Brabandere schrieb:
>> if you use EJB3 you really want to use the wicket-contrib-javaee project
>> (wicketstuff) all you need to do is call you @EJB and rest is handled
>> automatically !
>>
>
> That project needs an update for 1.3
> Add wicket-ioc dep / remove spring dep + some other unneeded deps /
> fix package names, I contacted the author but got no response.
> Plus you have to define all beans in the web.xml which is not needed
> when you work with jsf for example (tested on glassfish). Does anybody
> know why that is?
err, you need to checkout the trunk version for 1.3, built is for 1.2 !
the trunk works perfect with 1.3, but its noted on the page AFAIK
>
> but since this thread is about jpa+guice+wicket on lightweight
> container and not j2ee + wicket I suppose that wicket-contrib-javaee
> is not what they are looking for.
well, for me ejb3 is as lightweight as spring is.... sorry to say that,
but spring is IMHO XML nightmare while ejb3 seems very easy for me..
>
> On Nov 16, 2007 4:45 PM, Korbinian Bachl <ko...@whiskyworld.de> wrote:
>>
>> Uwe Schäfer schrieb:
>>> Maris Orbidans schrieb:
>>>> Let's remember good old EJB's. Inject an EntityManager in a session
>>>> bean facade and EJB container will handle all concurrency issues. No
>>>> need to write any boilerplate code.
>>> that´s where i come from. problem is, that you domain object aren´t able
>>> to lazily fetch attached data from database, unless you manage the EM
>>> yourself (maybe via Stateful SB, like seam does you encourage to).
>
>> see yourself:
>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee
>>
>> i love this thing!
>>
>> Best,
>>
>> Korbinian
>>
>>> there are situations in which SBs are the best way to implement DAOs. I
>>> doubt, these are the majority.
>>>
>>>> BTW I have seen that some people use OpenEntityManagerInViewFilter
>>>> and map it to url pattern "/*". It seems that an EntityManager would
>>>> be created every time a static web resource is accessed. Isn't that
>>>> terrible ?
>>> i don´t know if OpenEntityManagerInViewFilter actually opens an EM.
>>> my solution wont, but instead provide a Context for EMs, so that they
>>> can be created and managed (and yes, more than one ;) automatically on
>>> demand.
>>>
>>> cu uwe
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
new release of wicket-contrib-javaee
Posted by Maris Orbidans <sm...@ime.lv>.
hi
I have just created a new release of wicket-contrib-javaee. I have
fixed POM file and made it compatible with wicket 1.3.
Here is wiki page
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee
And to answer your question about EJB references in web.xml. They are
required because we need to lookup EJBs to create proxies for them.
In JSF it's responsibility of app. server to inject EJB references.
Maris
>> if you use EJB3 you really want to use the wicket-contrib-javaee project
>> (wicketstuff) all you need to do is call you @EJB and rest is handled
>> automatically !
>>
>>
>
> That project needs an update for 1.3
> Add wicket-ioc dep / remove spring dep + some other unneeded deps /
> fix package names, I contacted the author but got no response.
> Plus you have to define all beans in the web.xml which is not needed
> when you work with jsf for example (tested on glassfish). Does anybody
> know why that is?
>
> but since this thread is about jpa+guice+wicket on lightweight
> container and not j2ee + wicket I suppose that wicket-contrib-javaee
> is not what they are looking for.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Francis De Brabandere <fr...@gmail.com>.
> if you use EJB3 you really want to use the wicket-contrib-javaee project
> (wicketstuff) all you need to do is call you @EJB and rest is handled
> automatically !
>
That project needs an update for 1.3
Add wicket-ioc dep / remove spring dep + some other unneeded deps /
fix package names, I contacted the author but got no response.
Plus you have to define all beans in the web.xml which is not needed
when you work with jsf for example (tested on glassfish). Does anybody
know why that is?
but since this thread is about jpa+guice+wicket on lightweight
container and not j2ee + wicket I suppose that wicket-contrib-javaee
is not what they are looking for.
On Nov 16, 2007 4:45 PM, Korbinian Bachl <ko...@whiskyworld.de> wrote:
>
>
> Uwe Schäfer schrieb:
> > Maris Orbidans schrieb:
> >>
> >> Let's remember good old EJB's. Inject an EntityManager in a session
> >> bean facade and EJB container will handle all concurrency issues. No
> >> need to write any boilerplate code.
> >
> > that´s where i come from. problem is, that you domain object aren´t able
> > to lazily fetch attached data from database, unless you manage the EM
> > yourself (maybe via Stateful SB, like seam does you encourage to).
>
> see yourself:
> http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee
>
> i love this thing!
>
> Best,
>
> Korbinian
>
> >
> > there are situations in which SBs are the best way to implement DAOs. I
> > doubt, these are the majority.
> >
> >> BTW I have seen that some people use OpenEntityManagerInViewFilter
> >> and map it to url pattern "/*". It seems that an EntityManager would
> >> be created every time a static web resource is accessed. Isn't that
> >> terrible ?
> >
> > i don´t know if OpenEntityManagerInViewFilter actually opens an EM.
> > my solution wont, but instead provide a Context for EMs, so that they
> > can be created and managed (and yes, more than one ;) automatically on
> > demand.
> >
> > cu uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Uwe Schäfer schrieb:
> Maris Orbidans schrieb:
>>
>> Let's remember good old EJB's. Inject an EntityManager in a session
>> bean facade and EJB container will handle all concurrency issues. No
>> need to write any boilerplate code.
>
> that´s where i come from. problem is, that you domain object aren´t able
> to lazily fetch attached data from database, unless you manage the EM
> yourself (maybe via Stateful SB, like seam does you encourage to).
if you use EJB3 you really want to use the wicket-contrib-javaee project
(wicketstuff) all you need to do is call you @EJB and rest is handled
automatically !
see yourself:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee
i love this thing!
Best,
Korbinian
>
> there are situations in which SBs are the best way to implement DAOs. I
> doubt, these are the majority.
>
>> BTW I have seen that some people use OpenEntityManagerInViewFilter
>> and map it to url pattern "/*". It seems that an EntityManager would
>> be created every time a static web resource is accessed. Isn't that
>> terrible ?
>
> i don´t know if OpenEntityManagerInViewFilter actually opens an EM.
> my solution wont, but instead provide a Context for EMs, so that they
> can be created and managed (and yes, more than one ;) automatically on
> demand.
>
> cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Uwe Schäfer <sc...@thomas-daily.de>.
Maris Orbidans schrieb:
>
> Let's remember good old EJB's. Inject an EntityManager in a session
> bean facade and EJB container will handle all concurrency issues. No
> need to write any boilerplate code.
that´s where i come from. problem is, that you domain object aren´t able
to lazily fetch attached data from database, unless you manage the EM
yourself (maybe via Stateful SB, like seam does you encourage to).
there are situations in which SBs are the best way to implement DAOs. I
doubt, these are the majority.
> BTW I have seen that some people use OpenEntityManagerInViewFilter and
> map it to url pattern "/*". It seems that an EntityManager would be
> created every time a static web resource is accessed. Isn't that
> terrible ?
i don´t know if OpenEntityManagerInViewFilter actually opens an EM.
my solution wont, but instead provide a Context for EMs, so that they
can be created and managed (and yes, more than one ;) automatically on
demand.
cu uwe
--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E schaefer@thomas-daily.de
www.thomas-daily.de
Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Maris Orbidans <sm...@ime.lv>.
Let's remember good old EJB's. Inject an EntityManager in a session
bean facade and EJB container will handle all concurrency issues. No
need to write any boilerplate code.
BTW I have seen that some people use OpenEntityManagerInViewFilter and
map it to url pattern "/*". It seems that an EntityManager would be
created every time a static web resource is accessed. Isn't that terrible ?
Maris
> Uwe Schäfer wrote:
>> i plan to use JPA together with Wicket. Are there any battle-proven
>> best-practices out there of how to handle EnityManagers and
>> Transactions?
>>
>> What do other people use (no, not the spring crowd ;) ?
>>
>> One EntityManager per Request seems to be the obvious idea and a
>> guice Provider may help with that. Does anyone have serious
>> experiences with that or other suggestions?
>
> Subclass WebRequestCycle, and construct it with an EntityManager.
>
> In onBeginRequest(), create a transaction, storing it in a private
> variable.
>
> In onEndRequest(), commit the transaction if it hasn't already been
> rolled back and clean up the EntityManager.
>
> In onRuntimeException(...), rollback the transaction and then return
> super.onRuntimeException(...).
>
> You'll need to inject a Provider<EntityManager> into your
> WebApplication subclass such that you can call .get() on it when you
> make your custom WebRequestCycle. You'll need to configure that
> provider in a Guice module somewhere, obviously. You should be able to
> figure that out. ;-)
>
> How do you inject things into your WebApplication? Well, you can use
> the new GuiceWebApplicationFactory, which unfortunately didn't quite
> make it into 1.3.0-rc1 but is in trunk. However, you can copy that
> class from trunk and use it in your own project quite happily - it has
> no extra dependencies.
>
> If you need to integrate with your container-managed JTA transactions
> you'll need something a little different (the container may well start
> and commit the tx for you), but the principle is roughly the same.
>
> Alternatively, you can take Wicket out of the picture and do stuff
> using a ServletFilter (like Spring's OpenEntityManagerInView).
>
> Regards,
>
> Al
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Al Maw <wi...@almaw.com>.
Uwe Schäfer wrote:
> i plan to use JPA together with Wicket. Are there any battle-proven
> best-practices out there of how to handle EnityManagers and Transactions?
>
> What do other people use (no, not the spring crowd ;) ?
>
> One EntityManager per Request seems to be the obvious idea and a guice
> Provider may help with that. Does anyone have serious experiences with
> that or other suggestions?
Subclass WebRequestCycle, and construct it with an EntityManager.
In onBeginRequest(), create a transaction, storing it in a private variable.
In onEndRequest(), commit the transaction if it hasn't already been
rolled back and clean up the EntityManager.
In onRuntimeException(...), rollback the transaction and then return
super.onRuntimeException(...).
You'll need to inject a Provider<EntityManager> into your WebApplication
subclass such that you can call .get() on it when you make your custom
WebRequestCycle. You'll need to configure that provider in a Guice
module somewhere, obviously. You should be able to figure that out. ;-)
How do you inject things into your WebApplication? Well, you can use the
new GuiceWebApplicationFactory, which unfortunately didn't quite make it
into 1.3.0-rc1 but is in trunk. However, you can copy that class from
trunk and use it in your own project quite happily - it has no extra
dependencies.
If you need to integrate with your container-managed JTA transactions
you'll need something a little different (the container may well start
and commit the tx for you), but the principle is roughly the same.
Alternatively, you can take Wicket out of the picture and do stuff using
a ServletFilter (like Spring's OpenEntityManagerInView).
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: JPA best-practices?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> Evan Chooly wrote:
> >
> >> Do you know if theres any plans on making a maven2 archetype for
> qwicket?
> >
> > That's a definite feature i plan on adding as soon as I can. As a
> > noted maven hater, though, it'll take some time and libations to
help
> > me swallow my pride. :)
> >
>
> Good luck! Archetypes are really a pain, because of the template text
> strings in the source that keep them from compiling in place, so
they're
> hard to code, test, and maintain. I just abandoned mine.
> People can almost as easily rename classes and packages after the
fact, I've rationalized.
>
Alleluia brother - I hear what you're saying! Whoever decided declaring
stuff in type safe, compile time checked Java was hard? I've certainly
never found writing or updating Java classes hard - probably because
that's what I do every day!
Give me Java config over XML config any day.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by n8han <na...@technically.us>.
Evan Chooly wrote:
>
>> Do you know if theres any plans on making a maven2 archetype for qwicket?
>
> That's a definite feature i plan on adding as soon as I can. As a
> noted maven hater, though, it'll take some time and libations to help
> me swallow my pride. :)
>
Good luck! Archetypes are really a pain, because of the template text
strings in the source that keep them from compiling in place, so they're
hard to code, test, and maintain. I just abandoned mine. People can almost
as easily rename classes and packages after the fact, I've rationalized.
Nathan
--
View this message in context: http://www.nabble.com/JPA-best-practices--tf4777536.html#a13708172
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Evan Chooly <ev...@gmail.com>.
That's a definite feature i plan on adding as soon as I can. As a
noted maven hater, though, it'll take some time and libations to help
me swallow my pride. :)
On Nov 12, 2007 3:47 AM, Nino Saturnino Martinez Vazquez Wael
<ni...@jayway.dk> wrote:
> Do you know if theres any plans on making a maven2 archetype for qwicket?
>
> Evan Chooly wrote:
> > There's also qwicket.sf.net that specifically uses JPA+spring. I'm
> > finishing up updates now for 1.3 support and improved project setup.
> > SVN is your best bet there but I'm hoping to put up the new version
> > this weekend.
> >
> > On Nov 9, 2007 10:04 AM, Francis De Brabandere <fr...@gmail.com> wrote:
> >
> >> You might want to have a look at http://databinder.net, that project
> >> is using hibernate but the setup should be similar?
> >> The big problem is that a EntityManager is not thread-safe and should
> >> indeed be created per request. Let me know if you get there!
> >>
> >> On Nov 9, 2007 1:52 PM, Uwe Schäfer <sc...@thomas-daily.de> wrote:
> >>
> >>> hi
> >>>
> >>> i plan to use JPA together with Wicket. Are there any battle-proven
> >>> best-practices out there of how to handle EnityManagers and Transactions?
> >>>
> >>> What do other people use (no, not the spring crowd ;) ?
> >>>
> >>> One EntityManager per Request seems to be the obvious idea and a guice
> >>> Provider may help with that. Does anyone have serious experiences with
> >>> that or other suggestions?
> >>>
> >>> cu uwe
> >>> --
> >>>
> >>> THOMAS DAILY GmbH
> >>> Adlerstraße 19
> >>> 79098 Freiburg
> >>> Deutschland
> >>> T + 49 761 3 85 59 0
> >>> F + 49 761 3 85 59 550
> >>> E schaefer@thomas-daily.de
> >>> www.thomas-daily.de
> >>>
> >>> Geschäftsführer/Managing Directors:
> >>> Wendy Thomas, Susanne Larbig
> >>> Handelsregister Freiburg i.Br., HRB 3947
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> >>
> >> --
> >> http://www.somatik.be
> >> Microsoft gives you windows, Linux gives you the whole house.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Do you know if theres any plans on making a maven2 archetype for qwicket?
Evan Chooly wrote:
> There's also qwicket.sf.net that specifically uses JPA+spring. I'm
> finishing up updates now for 1.3 support and improved project setup.
> SVN is your best bet there but I'm hoping to put up the new version
> this weekend.
>
> On Nov 9, 2007 10:04 AM, Francis De Brabandere <fr...@gmail.com> wrote:
>
>> You might want to have a look at http://databinder.net, that project
>> is using hibernate but the setup should be similar?
>> The big problem is that a EntityManager is not thread-safe and should
>> indeed be created per request. Let me know if you get there!
>>
>> On Nov 9, 2007 1:52 PM, Uwe Schäfer <sc...@thomas-daily.de> wrote:
>>
>>> hi
>>>
>>> i plan to use JPA together with Wicket. Are there any battle-proven
>>> best-practices out there of how to handle EnityManagers and Transactions?
>>>
>>> What do other people use (no, not the spring crowd ;) ?
>>>
>>> One EntityManager per Request seems to be the obvious idea and a guice
>>> Provider may help with that. Does anyone have serious experiences with
>>> that or other suggestions?
>>>
>>> cu uwe
>>> --
>>>
>>> THOMAS DAILY GmbH
>>> Adlerstraße 19
>>> 79098 Freiburg
>>> Deutschland
>>> T + 49 761 3 85 59 0
>>> F + 49 761 3 85 59 550
>>> E schaefer@thomas-daily.de
>>> www.thomas-daily.de
>>>
>>> Geschäftsführer/Managing Directors:
>>> Wendy Thomas, Susanne Larbig
>>> Handelsregister Freiburg i.Br., HRB 3947
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> http://www.somatik.be
>> Microsoft gives you windows, Linux gives you the whole house.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: JPA best-practices?
Posted by dtoffe <dt...@yahoo.com.ar>.
I've found jPersist very interesting:
http://sourceforge.net/projects/jpersist
It's a different concept, it works by matching entity and attribute
names between POJOs and database metadata names, and doesn't need xml
configuration files at all. I like to think of it as "the wicket of
persistence frameworks".
It was open sourced in july and the community seems to be very small. I
would gladly appreciate to hear what others think about it.
BTW, I'm not in any way related to the project and/or its authors, just
an user.
Cheers,
Daniel
Chris Colman wrote:
>
> Have you seen exPOJO (http://expojo.com) yet? It an open source, very
> lightweight framework, free for use in commercial and open source apps,
> which sounds like what you're looking for.
>
> It allows you to build a completely POJO object model and persist it via
> a generic transparent persistence interface that has plugins for the
> various popular transparent persistence engines: Hibernate
> (implemented), JDO/JPOX (implemented) and JPA (will be implemented if
> sufficient demand)
>
>
--
View this message in context: http://www.nabble.com/JPA-best-practices--tf4777536.html#a13818521
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: JPA best-practices?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> And you need a framework for this? Come on!
>
An extremely lightweight framework that gives me dependency injection
and helps manage the myriad of repository and service classes I end up
with in large enterprise systems? All without the need for heavyweight
Swing and the XML hell and runtime error opportunities that delivers...
Need a lightweight framework that gives me all that and lets me port my
apps between JDO <-> Hibernate with miniscule effort? Hell yeah!
We're also about to open source some key infrastructure libraries that
are deployed to exPOJO which means that JDO (JPOX, Kodo etc.,) users can
use them as well as Hibernate users.
A big issue with the adoption of many Java libraries is that they hard
code dependence on a particular persistence solution: JDBC, EJBs,
Hibernate, JDO etc., which limits their appeal if you happen to have a
"favorite" that isn't their favorite ;)
Deploying to exPOJO means a library developer can expose their wares to
the maximum audience possible by providing repository components for the
major transparent persistence engines (Hibernate, JDO etc.,).
It's also useful if you want to go with an ORM but your company or
client hasn't decided on one yet - just pick your favorite ORM and then
start development while you're waiting on their decision. When they
finally make up their mind you'll have an easy time porting your app.
>
> Chris Colman wrote:
> >
> > exPOJO is a lightweight, dependency injection framework with support
for
> > the "exposed POJO domain model pattern" for highly productive app
> > development. It provides a very concise and simple interface
declaring
> > the essential generic services of a transparent persistence engine.
> > 'Transparent' is the key word here so the interface needs only be
> > extremely minimal but this generic interface is massively powerful.
Out
> > of the box it has JDO and Hibernate implementations of this
interface
> > and others (including JPA) can be supported in under 60 minutes if
> > required.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: JPA best-practices?
Posted by Craig Lenzen <le...@visi.com>.
And you need a framework for this? Come on!
Chris Colman wrote:
>
>> Chris Colman wrote:
>>
>> It seems it's also possible for a few other ORM tools to conform to
> that
>> standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne
> and
>> others.
>
> That's my point.
>
>>
>> Which would you rather depend on; exPOJO or JPA?
>
> Two different things:
>
> exPOJO is a lightweight, dependency injection framework with support for
> the "exposed POJO domain model pattern" for highly productive app
> development. It provides a very concise and simple interface declaring
> the essential generic services of a transparent persistence engine.
> 'Transparent' is the key word here so the interface needs only be
> extremely minimal but this generic interface is massively powerful. Out
> of the box it has JDO and Hibernate implementations of this interface
> and others (including JPA) can be supported in under 60 minutes if
> required.
>
> JPA is a different thing altogether - it's an ORM standard. The trouble
> is that it had to make compromises to allow certain popular ORMs to
> implement it. exPOJO does not try to be another ORM standard. It just
> takes the best the exposed domain model pattern has to offer and uses
> that such that the only components with engine specific references are
> the repository components that you build that have engine specific
> queries in them. All the rest can be handled generically.
>
>
>>
>> /Anders
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/JPA-best-practices--tf4777536.html#a13800920
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: JPA best-practices?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> Chris Colman wrote:
>
> It seems it's also possible for a few other ORM tools to conform to
that
> standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne
and
> others.
That's my point.
>
> Which would you rather depend on; exPOJO or JPA?
Two different things:
exPOJO is a lightweight, dependency injection framework with support for
the "exposed POJO domain model pattern" for highly productive app
development. It provides a very concise and simple interface declaring
the essential generic services of a transparent persistence engine.
'Transparent' is the key word here so the interface needs only be
extremely minimal but this generic interface is massively powerful. Out
of the box it has JDO and Hibernate implementations of this interface
and others (including JPA) can be supported in under 60 minutes if
required.
JPA is a different thing altogether - it's an ORM standard. The trouble
is that it had to make compromises to allow certain popular ORMs to
implement it. exPOJO does not try to be another ORM standard. It just
takes the best the exposed domain model pattern has to offer and uses
that such that the only components with engine specific references are
the repository components that you build that have engine specific
queries in them. All the rest can be handled generically.
>
> /Anders
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Anders Peterson <an...@optimatika.se>.
Chris Colman wrote:
>>> The obvious benefit in such an approach is that your POJO model and the
>>> services that you provide to implement business rules etc., remain
>>> completely portable to different persistence engines - ie., no vendor
>>> lock in.
>> well, i thought that was JPA was all about !?
>
> No, definitely not! JPA was all about creating a standard that Hibernate could conform to. Remember there *already* was a standard for Java persistence: JDO. JDO implementations such as JPOX and others implement both JDO (obviously) and JPA but it is not possible for Hibernate to provide all the features of JDO and so it could never implement the JDO standard - hence a less powerful standard had to be created so that Hibernate could play the "standards" game.
It seems it's also possible for a few other ORM tools to conform to that
standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne and
others.
Which would you rather depend on; exPOJO or JPA?
/Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: JPA best-practices?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> Chris Colman schrieb:
>
> > The obvious benefit in such an approach is that your POJO model and the
> > services that you provide to implement business rules etc., remain
> > completely portable to different persistence engines - ie., no vendor
> > lock in.
>
> well, i thought that was JPA was all about !?
No, definitely not! JPA was all about creating a standard that Hibernate could conform to. Remember there *already* was a standard for Java persistence: JDO. JDO implementations such as JPOX and others implement both JDO (obviously) and JPA but it is not possible for Hibernate to provide all the features of JDO and so it could never implement the JDO standard - hence a less powerful standard had to be created so that Hibernate could play the "standards" game.
Enough of the history lesson already ;)
> > As well as "wrapping" the various persistence engines it also provides
> > dependency injection without resorting to separate XML/bean mania - it's
> > all done very quickly and concisely and automatically in Java -
>
> Thanks, that´s what guice is great for, and it is really neatly
> integrated with wicket.
Yes, exPOJO and guice are great alternatives to a heavyweight and XML based approach like Spring.
exPOJO, being a lightweight implementation of the "exposed POJO domain model pattern" has the benefit of making it easy to port apps between Hibernate, JDO and JPA without changing any of your model code or 'Service' classes. You only need to implement an engine specific Repository class as repositories are the only classes that contain engine specific API calls - ie., mainly the queries.
If the slow performance of Hibernate's "reflection based" dirty state checking on large object graphs has you worried then you can quickly change your underlying persistence engine over to a "byte code enhanced" solution, like for example JPOX, with the lightning fast dirty state checking and other performance gains that brings.
>
> > http://expojo.com
>
> I´ll take a look anyway, thanks.
>
> cu uwe
>
> --
>
> THOMAS DAILY GmbH
> Adlerstraße 19
> 79098 Freiburg
> Deutschland
> T + 49 761 3 85 59 0
> F + 49 761 3 85 59 550
> E schaefer@thomas-daily.de
> www.thomas-daily.de
>
> Geschäftsführer/Managing Directors:
> Wendy Thomas, Susanne Larbig
> Handelsregister Freiburg i.Br., HRB 3947
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Uwe Schäfer <sc...@thomas-daily.de>.
Chris Colman schrieb:
> The obvious benefit in such an approach is that your POJO model and the
> services that you provide to implement business rules etc., remain
> completely portable to different persistence engines - ie., no vendor
> lock in.
well, i thought that was JPA was all about !?
> As well as "wrapping" the various persistence engines it also provides
> dependency injection without resorting to separate XML/bean mania - it's
> all done very quickly and concisely and automatically in Java -
Thanks, that´s what guice is great for, and it is really neatly
integrated with wicket.
> http://expojo.com
I´ll take a look anyway, thanks.
cu uwe
--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E schaefer@thomas-daily.de
www.thomas-daily.de
Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: JPA best-practices?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> > > i plan to use JPA together with Wicket. Are there any
battle-proven
> > > best-practices out there of how to handle EnityManagers and
> Transactions?
> > >
> > > What do other people use (no, not the spring crowd ;) ?
> > >
> > > One EntityManager per Request seems to be the obvious idea and a
guice
> > > Provider may help with that. Does anyone have serious experiences
with
> > > that or other suggestions?
> > >
Have you seen exPOJO (http://expojo.com) yet? It an open source, very
lightweight framework, free for use in commercial and open source apps,
which sounds like what you're looking for.
It allows you to build a completely POJO object model and persist it via
a generic transparent persistence interface that has plugins for the
various popular transparent persistence engines: Hibernate
(implemented), JDO/JPOX (implemented) and JPA (will be implemented if
sufficient demand)
The obvious benefit in such an approach is that your POJO model and the
services that you provide to implement business rules etc., remain
completely portable to different persistence engines - ie., no vendor
lock in.
As well as "wrapping" the various persistence engines it also provides
dependency injection without resorting to separate XML/bean mania - it's
all done very quickly and concisely and automatically in Java - which
means you have the benefit of compile time error checking instead of
finding out about configuration errors at run time as you do in Spring.
The only XML config is the usual configuration of an exPOJO filter and
start up/shut down (ServletContextListener) listener in your web.xml.
These are just a few lines that only need to be set up once and never
need adjusting no matter how big your project grows.
You can read more about it and download (~200kb!) from:
http://expojo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Evan Chooly <ev...@gmail.com>.
There's also qwicket.sf.net that specifically uses JPA+spring. I'm
finishing up updates now for 1.3 support and improved project setup.
SVN is your best bet there but I'm hoping to put up the new version
this weekend.
On Nov 9, 2007 10:04 AM, Francis De Brabandere <fr...@gmail.com> wrote:
> You might want to have a look at http://databinder.net, that project
> is using hibernate but the setup should be similar?
> The big problem is that a EntityManager is not thread-safe and should
> indeed be created per request. Let me know if you get there!
>
> On Nov 9, 2007 1:52 PM, Uwe Schäfer <sc...@thomas-daily.de> wrote:
> > hi
> >
> > i plan to use JPA together with Wicket. Are there any battle-proven
> > best-practices out there of how to handle EnityManagers and Transactions?
> >
> > What do other people use (no, not the spring crowd ;) ?
> >
> > One EntityManager per Request seems to be the obvious idea and a guice
> > Provider may help with that. Does anyone have serious experiences with
> > that or other suggestions?
> >
> > cu uwe
> > --
> >
> > THOMAS DAILY GmbH
> > Adlerstraße 19
> > 79098 Freiburg
> > Deutschland
> > T + 49 761 3 85 59 0
> > F + 49 761 3 85 59 550
> > E schaefer@thomas-daily.de
> > www.thomas-daily.de
> >
> > Geschäftsführer/Managing Directors:
> > Wendy Thomas, Susanne Larbig
> > Handelsregister Freiburg i.Br., HRB 3947
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> http://www.somatik.be
> Microsoft gives you windows, Linux gives you the whole house.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: JPA best-practices?
Posted by Francis De Brabandere <fr...@gmail.com>.
You might want to have a look at http://databinder.net, that project
is using hibernate but the setup should be similar?
The big problem is that a EntityManager is not thread-safe and should
indeed be created per request. Let me know if you get there!
On Nov 9, 2007 1:52 PM, Uwe Schäfer <sc...@thomas-daily.de> wrote:
> hi
>
> i plan to use JPA together with Wicket. Are there any battle-proven
> best-practices out there of how to handle EnityManagers and Transactions?
>
> What do other people use (no, not the spring crowd ;) ?
>
> One EntityManager per Request seems to be the obvious idea and a guice
> Provider may help with that. Does anyone have serious experiences with
> that or other suggestions?
>
> cu uwe
> --
>
> THOMAS DAILY GmbH
> Adlerstraße 19
> 79098 Freiburg
> Deutschland
> T + 49 761 3 85 59 0
> F + 49 761 3 85 59 550
> E schaefer@thomas-daily.de
> www.thomas-daily.de
>
> Geschäftsführer/Managing Directors:
> Wendy Thomas, Susanne Larbig
> Handelsregister Freiburg i.Br., HRB 3947
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org