Hi Renat,
I should have re-read that thread sooner - you are quite right, EJB 3
doesn't solve that problem at all.
Regards,
Geoff
On 04/08/2007, at 12:54 AM, Renat Zubairov wrote:
BTW
Could you, Geoff, comment on how EJB 3 solve Hibernate detached object
multi-thread access problem? I didn't got your point in this case.
Renat
On 03/08/07, Geoff Callender <[EMAIL PROTECTED]>
wrote:
Hi Kalle,
I guess my starting point is that I really like the discipline of
building a business facade for my system ie. a layer that says what
the system can do for you, irrespective of UIs. So then the question
for me is where to put that layer. Since EJB3 arrived, I've opted to
put the business layer in a container because:
- the configuration is almost nil
- the transaction boundary is clear and usually you have to do
nothing.
- you get remoting for free.
- you get JTA (transactions across multiple resources) for free.
- you get declarative security for free
- you get basic AOP for free
- the DAO pattern disappears - I treat each session bean as a
business service that manipulates entities directly. DAOs came into
existence to hide the persistence details. but now JPA does that for
you. No DAOs means one less layer of plumbing.
- the old concern of creating masses of DTOs that mimic your domain
model is gone, thanks to detached entities.
- session beans get their own thread, so you don't get complicated
problems like
http://thread.gmane.org/gmane.comp.java.tapestry.user/49915/
focus=50023
- you can turn a session bean into a web service with ease
I'm sure there's more that I can't think of right now. The only
downside I've come across is that testing relies on the container
running, but it looks like there are solutions to that just around
the corner.
HTH
Geoff
On 03/08/2007, at 1:27 PM, Kalle Korhonen wrote:
Hey Geoff,
could you comment on the reasons why you require an J2EE container.
Is it
just so that you don't need to deal with initializing the
EntityManager
yourself or do you see other compelling benefits in using the
container? I'm
asking because while we use EJB3 & Hibernate annotations in Trails (
trailsframework.org), we don't use an EntityManager at all (the
work had
started before EntityManager was born, much less the stand alone
EntityManager spec finalized), but we've been thinking of moving to
using it
as we start working on supporting transaction management patterns
other than
session-per-request.
Kalle
On 7/25/07, Geoff Callender <[EMAIL PROTECTED]>
wrote:
Hi Naz,
Is it possible for you to put some tips to use tomcat with your
JumpStart?
Sorry but I don't have any plans for doing a Tomcat-only
implementation, so the short answer is "no". The reason is that
JumpStart uses EJB3 for the business layer. That pretty much means
an application server has to be involved.
Today, the instructions cover just one app server: JBoss (note that
JBoss has Tomcat embedded in it to handle the web layer, and the
instructions cover this).
In future, instructions are planned for other EJB3 implementations:
Glassfish, JBoss MicroContainer, and perhaps one other app server
(JOnAS? OC4J?). If someone else would like to do instructions then
I'd really appreciate it, as my time for JumpStart is very limited.
I'm sure it would benefit many in the Tapestry community.
Regards,
Geoff
On 24/07/2007, at 10:51 AM, Bhuiyan, Nazmul wrote:
Hi,
Is it possible for you to put some tips to use tomcat with your
JumpStart?
Thanks
Naz
-----Original Message-----
From: Geoff Callender [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 24 July 2007 2:18 a.m.
To: Tapestry users
Subject: JumpStart v1.6 - for Tapestry 4.1.2
Hi all,
JumpStart v1.6.0 is now available. New features include: it works
with Tapestry 4.1.2, it has a more Maven-like project
structure, and
it builds its exploded EAR file on the fly. You'll find it at the
usual place:
http://files.doublenegative.com.au/jumpstart
JumpStart v1.5.0 has also been released today for those wanting to
stay with Tapestry 4.0.2 but get the other new features.
Comments and suggestions welcomed. Be brutal or helpful - I don't
care which, because it all helps to make this stuff more useful.
Cheers,
Geoff Callender
------------------------------------------------------------------
--
-
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]
-------------------------------------------------------------------
--
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]
--
Best regards,
Renat Zubairov
---------------------------------------------------------------------
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]
