I am currently developing an application using Tapestry, HiveMind,
Hibernate, and Spring. I am one of the committers on the HiveMind project
and I still use Spring for my DAOs, because its Hibernate support is just
REALLY nice. The one feature that they have which we don't (we meaning
HiveMind) is the ability to "autoproxy" something based on annotations.
Here's a snippet of my applicationContext.xml file which illustrates what I
mean...
<bean id="autoproxy"
class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCr
eator"
autowire="autodetect"/>
<bean id="transactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor"
autowire="autodetect"/>
<bean id="transactionAdvisor"
class="org.springframework.transaction.interceptor.TransactionAttributeSourc
eAdvisor"
autowire="autodetect"/>
<bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager"
autowire="autodetect"/>
<bean id="transactionAttributeSource"
class="org.springframework.transaction.annotation.AnnotationTransactionAttri
buteSource"/>
Of course, my session factory is also set up (that's why the
HibernateTransactionManager works). Now, the real beauty of this happens
when I write one of my DAOs...
public class PersonDao extends HibernateDaoSupport
{
@Transactional(readOnly=true)
public Person getPersonById( Long id )
{
return ( Person )getSession().get( Person.class, id );
}
}
And, put them into the mix with the other Spring-managed beans...
<bean id="PersonDao" class="com.myco.dao.PersonDao" autowire="autodetect"/>
That's all there is to it! Spring will automatically put a transaction
interceptor around my DAO because it has a method which states that it's
transactional. It makes adding new DAOs to the system really easy, once you
get the other stuff set up. My "rule of thumb" is that I use Spring for
everything "domain-related" and HiveMind for all "web-related" stuff like
extending the Tapestry framework and what-not. Well, hope this helps
someone get off to a good start, because it took me a while to get this all
working. :-)
James
-----Original Message-----
From: Jim Steinberger [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 18, 2006 6:41 AM
To: Tapestry users
Subject: RE: [OT] Re: Best practice - Integration Hibernate/Tapestry
Please excuse the following info-dump :)
To gank Howard Lewis Ship's wording from his Java Posse interview a few
weeks ago, Hivemind was designed for building frameworks and Spring was
designed for building applications. I'm less familiar with Hivemind
than I am with EJBs, unfortunately, but I'm sure it would work just fine
in Spring's place, and vice versa, with tradeoffs either way.
Spring has a lot of utility functionality built in, though, that I like
a lot, particularly with regard to Hibernate. E.g. the
HibernateTemplate & TransactionTemplate & JdbcTemplate classes, which
ridiculously simplified my data access objects (DAOs) by keeping
boilerplate (i.e. code you find yourself typing [copy-pasting] over and
over to accomplish the same thing) code out. It's also just easier, in
my opinion, to configure the Hibernate SessionFactory via Spring's
AnnotationSessionFactoryBean and LocalSessionFactoryBean classes. This
is likely where HLS's description comes into play -- I would guess
Hivemind handles creating modules and namespaces and wiring more
elegantly, but lacks the application-easing utility code that Spring
provides.
Neither is really a replacement for the other -- you can use either of
them exclusively or not at all, though you'll want to be familiar with
Hivemind to help you accomplish some Tapestry tasks, as the two
technologies are, understandably, intimately linked.
With regard to Tapestry, it's very slick and easy to have Tapestry start
the Spring engine, which in turn starts the Hibernate engine. It's
similarly effortless to access Spring-managed beans from Tapestry pages,
etc. From what I saw about using Hibernate with Tapestry directly, it
just seemed messier, but I admit I've never tried it.
I believe I'm ganking more of HLS's phrasing ... but it was said (also
on that podcast) that EJBs were built to handle all the concerns that a
very large enterprise would have to deal with, e.g. transactions
distributed over servers across the country, etc. This is overkill for
most Java-based web applications, as your small-business e-Commerce site
isn't going to benefit from all that, and meanwhile your application's
development will slow to a painful trudge as you have to deal with all
the complexity.
It is my understanding (and experience) that for medium-sized projects,
Spring and Hibernate can give you most of the help the EJB framework
would, but with much less impact on your code and a generally
more-pleasant experience. For huge enterprise-scale projects, EJB might
be a consideration, but if you can wait until EJB 3.0 is released, that
would be nice, as allegedly EJB 3.0 is much simpler, taking cues from
all the lightweight frameworks it found itself losing to. (btw, the
creator of Hibernate [Gavin King] is heavily involved in EJB 3.0
persistence -- so the difference is going to be much less substantial
very soon; I'd use Hibernate now and then take a gander at EJB 3.0 when
it comes out and decide then ... it should fortunately be pretty easy to
switch over, especially considering Hibernate supports EJB 3.0
Annotations on your POJOs)
Personally, I am heavily biased toward the Spring/Hibernate/Tapestry
stack -- my DAOs are extremely readable and easy to manage and test ...
what used to take 30-40 lines of JDBC code took 12 using Hibernate, and
then 1-2 lines when I further worked in Spring's HibernateTemplate
class. And Tapestry's component framework means I can have my
developers creating components independently, and my web designer making
everything pretty, without everyone stepping on each other's toes. It
really makes development fun again (Struts was really nice at first but
then it made me cry), which is probably why I'm approaching my 24th
voluntary straight hour here at the office and it's Saturday morning
now.
Regarding performance, I have zero understanding of EJB's performance.
Speed-wise, I haven't run into issues yet with
Spring/Hibernate/Tapestry; though granted, my web applications have very
small audiences, but all three technologies are designed to scale well.
My only issue has been having to completely stop hot-deploying to
Tomcat, as all three technologies exacerbate a memory-leak issue with
Java's classloader that takes Tomcat down rather unelegantly after 6-7
deploys of a modest application. And even then, as the applications are
used, more and more proxy-classes are loaded and after a few days Tomcat
would run out of memory even after a clean restart. But this was
largely my issue -- I was squeezing two S/H/T applications onto a server
with about 10 other (Struts) applications on it, with only a Gig to
share among them all. You just have to be honest about load-testing and
monitoring your application to see how much memory it uses, is all, and
I'm sure that is true for an EJB application, though I can't say with
any authority whether it experiences the same kind of issues.
But the bottom-line was that the hours and hours of development-time
saved (particularly with regard to maintenance -- a S/H/T application is
marvelous when it comes to having to change it later, compared to a
Struts application [at least, the Struts I was using a year ago]) more
than compensated for the financial cost of installing more RAM on the
production server mentioned above.
And that's everything your e-mail inspired me to say so far : )
Jim
-----Original Message-----
From: Andreas Bulling [mailto:[EMAIL PROTECTED] On Behalf Of
Andreas Bulling
Sent: Saturday, February 18, 2006 5:32 AM
To: Tapestry users
Subject: Re: [OT] Re: Best practice - Integration Hibernate/Tapestry
Hi Jim,
first, thanks _a lot_ for your quick and helpful answer which
I appreciate a lot!
It made me feel a little bit happier again after this painful day as
there's a small light at the end of the tunnel, now ;)
Especially as you mentioned some of the terms I've read over the
day but could not class correctly so far...
So, that means basically I have to decide whether I need the
EJB functionality or if a POJO-based approach is enough
for my application
*thinking*
Perhaps someone else can answer the following questions then:
Why should I use EJB's at all now that Hibernate does such a great
job? Is there a situation where using EJBs _and_ Hibernate makes sense
and if yes, how can they be brought together? Are there performance
issues using a POJO-based approach and perhaps EJBs should
by all means be used in bigger applications or shouldn't that be
a problem? What are your experiences?
What about the idea to use one single session bean providing all
methods needed to handle the POJOs and hibernate?
Jim, you mentioned Spring and I'm wondering what Spring is good
for? How does it "bridge" between Tapestry and Hibernate, how did
it make your life easier? Which role plays Hivemind in this whole
constellation? I'm not sure but perhaps Hivemind is just a replacement
for Spring?
Thanks again!
Andreas
On 17. Feb 2006 - 19:19:50, Jim Steinberger wrote:
| Hi Andreas,
|
| Hibernate is an alternative to EJB CMP, though I'm sure you could use
| the two solutions together if you had/wanted to. Both are a way of
| bridging your Java classes and your database tables by mapping them --
| the goal is to not have to write SQL manually ... or rather, the goal
is
| to not to even have to think about the database as anything besides a
| place where your Java objects go to ... hibernate :)
|
|
| EJB2 CMP was very intrusive, from what I've heard, requiring you to
| extend certain classes and/or implement various interfaces, ensuring
| that your basic domain-model classes would only be relevant inside an
| EJB container. Hibernate, on the other hand, lets you simplify your
| domain-model back to plain-old-Java-objects (POJOS). Your objects
are,
| therefore, relevant anywhere, and you get the Object-Database bridge
| without having to deal with the complexity of an EJB container.
|
|
| I've never used EJB, let alone with Tapestry, so I can't really say
much
| about that. But I can say that if you were interested in creating an
| application without EJB CM, I personally use Spring to bridge
Hibernate
| and Tapestry together and I'm enormously happy with how well my code
is
| organized/modularized as a result.
|
| Integrating Tapestry and Spring:
| http://wiki.apache.org/jakarta-tapestry/Tapestry4Spring
|
| Integrating Spring and Hibernate:
|
http://static.springframework.org/spring/docs/1.2.x/reference/orm.html#o
| rm-hibernate
|
| Feel free to e-mail me directly if you'd like me to go further into
| Tapestry-Spring-Hibernate; sorry I can't help with EJB questions.
|
| Jim
---------------------------------------------------------------------
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]
