David Sean Taylor wrote:
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
We should settle on one light-weight container as the default, just to keep things simple. I still would like to keep PicoEngine around if SpringEngine becomes the chosen path, or vice versa, just as a proof of concept. However, we would have to make it known that the actual assembly for the runner-up would not be maintained and if someone did decide to go with the runner up, they would be responsible for replicating the assembly themselves.
What would be great is having sub-projects for each "non-official" container. It would be each sub-projects responsibility to keep their respective assemblies in line with the primary one.
+1 on GBeans if they as robust as Spring/Pico is in terms of assembly.
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?
Pico does have support via nanning for the AoP alliance apis as does Spring. If you read the Spring AoP doc, they discuss how you can make portable advisors, pointcuts, etc. The bad thing about Pico and nanning is that there is relatively no documentation on how to implement it.
All that being said I agree that if we do decide to use AoP, we keep it to minimum and use for what those situations where it makes sense like security, caching and possibly some assistance on logging throwables.
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 * * <[EMAIL PROTECTED]> * * <http://www.einnovation.com> * * -------------------------------------- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEditPro, Website Content Mangement * * <http://www.openeditpro.com> * ******************************************
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ****************************************** * Scott T. Weaver * * <[EMAIL PROTECTED]> * * <http://www.einnovation.com> * * -------------------------------------- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEditPro, Website Content Mangement * * <http://www.openeditpro.com> * ******************************************
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
