After my recent exposure to the Geronimo core and after seeing how it manages component dependencies, lifecycle and management, container hierarchies, classloader assignment, configuration persistence and who knows what else, I'm taking another serious look at my work.

For starters, if I understood IoC-3 or Constructor Dependency Injector principles last month, this morning I grok them in their fullness.

The question, after having all of that infrastructure for free, becomes "how can I use dynamic rules to execute actions in sequence from different classloaders, how can I make a more robust representational model to reduce the burden and complexity of state transfer and odd state-coupling inconsistencies at runtime?

The geronimo core offers a more robust infrastructure than anything I've seen to date. I'm reworking a lot of my infrastructure to make it true IoC. Anyone should be able to just yank my components out of their environment and wire them up with Pico or Geronimo or whatever framework suits their fancy.

This could end up being an extremely good thing for Webwork users. I should, without a terrible amount of difficulty, be able to build some component adaptors for out-of-the-box webwork actions, as long as they define their dependencies in their constructors. Same should hold for struts actions, as long as they define their component dependencies in their constructors like good citizens.

I wish I'd known this stuff last summer, but you can't win them all. In my mad rush to "do it now!" I missed a lot of good information.

The project continues, meanwhile, to spiral toward a healthy and robust implementation. The difficulty of writing unit tests for this framework helped convince me that I was doing something wrong.

The original concept still holds, though. I'm experimenting with the representation interface, trying to figure out what's going to be the most useful means for giving action and presentation designers a clue how to easily get the data and how to get some context about its purpose.

And the dynamic rules integration? Well I'll keep you posted on that.

Or "dependency injection", if you want to call it that. I've been working with some testing code for the last several days and I had to do a bunch of funky constructor calls, then it struck me what the whole IoC-3 thing was all about.

Late last night I officially got the testing bug. Here are some things I've figured out thus far (notes for the road...)

Today I'm beginning the overdue process of determining a clean, reliable and relatively simple way to test the Shocks Framework, applications which run on it and feature platforms which plug into it. To do this will require not only Unit Tests, but also System-level tests and tests to ensure the backwards compatibility of future binary releases.

To do this I'm returning to Matt Albrecht's GroboUtils project. Matt's JUnit extensions show a level of insight into testing that I've not found anywhere else.