While we're on the subject, am I correct in my assessment that the
only feature that hivemind has that spring does not is the whole
configuration point /contribution system? It's been a while since I've
really used hivemind so I may be wrong.

On 11/22/06, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
I think Sam put it pretty well. Cyrille, you should also read the other
thread "Tapernate access multiple database" that touches the Hivemind/Spring
subject. I often think the primary use scenarios of commons-logging and
log4j are analogous to Hivemind and Spring. If you are building a library or
framework with third-party extensibility in mind you want Hivemind (and
commons-logging), and if you are building a stand-alone web/J2EE application
Spring (and log4j) provides a better fit (because you gain less from
Hivemind/common-logging flexibility and because they don't have
out-of-the-box support for other frameworks you likely need).

Kalle

On 11/21/06, Sam Gendler <[EMAIL PROTECTED]> wrote:
>
> It depends entirely on the context of the app.  Tap has some
> dependancies on hivemind, so you will wind up dealing with hivemind
> and hivemind configs to some extent no matter which solution you use.
> However, the spring integration is very easy to use, and it is easily
> possible to keep all of the layers and support classes that aren't
> web/tapestry specific in your spring config and use them from within
> tapestry as easily as you can use objects managed by Hivemind.
> Fundamentally, Spring makes working with Hibernate based entities an
> absolute breeze, and that isn't something to be disregarded.  And AOP
> via AspectJ really simplifies some other things, such as changelogs
> and transaction management (spring will happily manage all your
> transactions for you via AOP, if you ask it to).  If you will be using
> hibernate for entity storage and/or want acegi or AOP, then the choice
> is made for you. Use Spring.  If not, hivemind is the solution that is
> native to tapestry, so you might as well use that. Another issue to
> consider is that Spring is probably more likely to crop up on other
> projects you may build in the future, so it may be useful to you,
> personally, to use it.
>
> --sam
>
> ---------------------------------------------------------------------
> 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]

Reply via email to