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
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
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
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
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
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
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
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
On Nov 16, 2007 8:02 PM, Korbinian Bachl [EMAIL PROTECTED] 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
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,
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
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,
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
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
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
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
[EMAIL PROTECTED] wrote:
Do you know if theres any plans on making a
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
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
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
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
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 [EMAIL PROTECTED] wrote:
You
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
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 [EMAIL
23 matches
Mail list logo
