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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
