Last night's talk went well (I think), more turnout than expected (~25 people showed up!).
ColdSpring Presentation
Sample Code
(the sample code loosely follows the presentation)
One really good question that was asked about ColdSpring was "when does it make sense?", meaning "at what level of application complexity should I start looking at ColdSpring?".
Now, you probably wouldn't want to use it on very small, simple applications. ColdSpring shines as complexity increases. However, one thing I mentioned is that ColdSpring doesn't have to be a choice you make in the beginning of a project. One of the biggest *wow* features of J2EE Spring to me was its ability to effectively tie together lots of "legacy" code with new development in a very clean fashion. I'd like ColdSpring to be similarly flexible, so that one could add it to an existing project when the need arises.
I also regret not showing some examples of using ColdSpring in a remoting environment, or it's integration with the 3 most popular MVC web-app frameworks (FB4,Mach-II,ModelGlue).
The AOP part of the presentation was interesting, because my grasp of AOP concepts is enough for *my own* understanding, but probably not good enough to be teaching others. The example worked flawlessly though, and sparked good discussion on potential uses of AOP.
Another good question was about performance... does ColdSpring slow down your app? NO! Why? Because ColdSpring is typically not involved at all during "runtime". All of the complex wiring (aka "dependency resolution") happens the *first* time you pull a bean out of the factory, which 99.999% of the time is during application startup. Thus, ColdSpring is not involved at all during a typical web request. AOP is an exception here, and that's why load/stress testing of ColdSpring's AOP classes is very important and will be done before the code is put in a "final" release.
| ||
| ||
| ||
| ||