portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Evaluation of Spring Framework
Date Tue, 20 Jul 2004 15:49:53 GMT
I've also been reviewing Spring, and Im impressed.
I was also very happy to see how well our component design stood up to 
swapping container technologies out.
I would like to throw out a few issues to consider as a team:

1. Do we want to try to support 2 or more lightweight container 
frameworks, or keep it simple and support only one?
     Now that the groundwork is in place for swapping containers, I 
think we should also review Apache Geronimo's GBeans

2. Spring supports AoP, where some other containers do not. If we were 
to go with Spring's AoP for interceptive security,  how would this work 
in Pico or other containers?

     Lets learn and remember from this last lesson, and keep in mind 
that we may want to swap out Spring for something better in the future, 
and lets try to keep the couplings to a mimimal

On Jul 20, 2004, at 7:52 AM, Scott T. Weaver wrote:

> As much of a Pico fan as I am, I still felt it important that we 
> evaluate Spring Framework to see what all the noise was about, the 
> Spring guys are getting a helluva lot of good press these days.  We 
> initially decided against Spring in our initial framework evaluation 
> because, at the time, you had to download all of Spring, including 
> there web framework, to use it.  Spring has now separated the 
> framework into nice, bite-size pieces, so you only take what you need.
> I spent Friday and Saturday learning Spring Framework and took the 
> liberty of trying to get Jetspeed 2 to run on top of Spring.  By the 
> end of the day yesterday (Monday) I had Jetspeed 2 running using the 
> Spring Framework.  I would like to ask everyone to take a look at the 
> Spring Framework documentation and look at the 
> pooled-datasource-support.xml and jetspeed-spring.xml in 
> WEB-INF/assembly and get their thoughts on a possible move to Spring 
> as our primary light-weight container and to possibly deprecate the 
> Pico engine and ComponentManager.
> Here are some of the pluses I have found with Spring Framework:
> 1.  It has great documentation and a relatively small learning curve 
> (obviously, because I was able to get J2 running on it 3 days!).
> 2.  It has a very active community, the user list gets a ton of 
> traffic.
> 3.  Spring has a very full-featured, well-documented AoP api built 
> right into the framework.  We could take advantage of this for 
> security, caching, etc.
> 4.  Spring had a thread local factory implementation built-in with 
> examples were as in Pico I had to right a component adapter to perform 
> the same logic myself.
> 5.  As cool as Groovy is, IMOHO, the spring configuration is much more 
> readable and far easier to maintain.
> 6.  Pico has a lot of "moving" dependencies that, from time to time, 
> cause us build problems.  Spring is in release 1.0.2 and all its deps 
> are also release versions.
> 7.  Seems more efficient from a start up standpoint.  Spring is about 
> 2/3 faster if you look at the TestEngine (Pico) at 9~seconds versus 
> the TestSpringEngine at 3~ seconds.
> 8.  Spring has very nice support for adding properties straight into 
> your configuration.
> 9.  Pico requires that you implement the lifecycle interface, 
> Startable.  Spring allows you to define init and destroy methods in 
> the config.
> 10. I is very easy to mix constructor based dep injection with 
> property dep injection.
> By default the build is using the original PicoEngine so as not to 
> interfere with anyone's existing apps.
> Enabling SpringEngine:
> Go into the web.xml uncomment the init-param that specifies the 
> SpringEngine and comment out the one that is using the PicoEngine.  
> It's just that simple ;)
> p.s.
> I think it would be unfair to us (Jetspeed developers) to give all the 
> credit to Spring for the ease of transition.  We all have done a 
> tremendous job writing well-designed components that are portable and 
> that demonstrate low-coupling along with high re-useability.  This 
> just goes to reaffirm that Jetspeed 2 is moving in the right direction 
> in terms of design and architecture. Kudos to us all ;)
> Regards,
> -- 
> ******************************************
> *           Scott T. Weaver              *
> *         <weaver@apache.org>            *
> *     <http://www.einnovation.com>       *
> * -------------------------------------- *
> *   Apache Jetspeed Enterprise Portal    *
> *     Apache Pluto Portlet Container     *
> *                                        *
> * OpenEditPro, Website Content Mangement *
> *     <http://www.openeditpro.com>       *
> ******************************************
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

David Sean Taylor
Bluesunrise Software
[office]   +01 707 773-4646
[mobile] +01 707 529 9194

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message