the cause of most xml in spring has always been the transaction demarcation support, but that has already been in annotations for a while so really the xml is minimal. and for a portal this xml you /will/ want to have configurable at deployment time in order to configure what portlets/services are available to the portal - so even with ejb3 this kind of stuff still has to be in some external config.

-Igor


On 6/14/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
> agreed, and i might be interested in contributing to this also. but that
> depends on the stack you choose. i like spring+hibernate because it is more
> lightweight and can run off jetty and spring provides a better ioc container
> then ejb3 which might be important for autodiscovery/plugins architecture.
> but this is just talk :)

I'm familiar w/ Hibernate but unfortunately, know very little about
Spring and know nothing about Jetty.  I looked into Spring when I
first started using Hibernate because I hated manually juggling the
Hibernate Session/Transaction...apparently Spring has an elegant
solution through templates?  I was turned off by the amount of XML
required in Spring (and Hibernate) and that's what drove me to
appreciate EJB 3.0 - particularly JBoss.

You do make a good point about IOC, however, since portlets would need
to be very loosely coupled and Spring might remove a great deal of
that complexity.

Isn't the next version of Spring moving a great deal of the XML
necessary to annotations?  I don't follow Spring but I thought I had
read that somewhere?

Injection of resources in EJB3 is pretty slick even if it is lacking,
compared to Spring.


_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to