Thank you for sharing your valuable experience.
Pedro
El sáb, 18-02-2006 a las 07:42 -0500, James Carman escribió:
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
