Some random responses. Spring is good at two things. The core IoC container and TX mgmt. The way I use Spring for IoC is I always ensure there is no dependency on Spring itself. This means I don't really care too much about the Spring core IoC container and would be open to using a different container, but just for practical reasons its safer to stick with Spring because of the huge user base and excellent quality.
Even if you don't use Spring IoC, you can still use Spring TX. I have never found a better TX mgmt framework than Spring. It is extremely comprehensive. So if your not using container managed transactions (JEE and EJB nonsense), then I really think Spring TX is the only option. Spring MVC, Spring Batch, Spring WS, Spring [Whatever], are mostly nonsense in my mind and I don't care to use them. I don't subscribe to the whole Spring world. Just IoC (because IoC truly revolutionized Java) and TX. Regarding asserts. I don't care for Java asserts. Computers are fast and extra null checks here and there are fine to just have in the code. It is not like we are writing a stock trading platform. I would prefer we never use asserts. I hate to find bugs that only happen when asserts are on or off. If your not aware, Java asserts are turned on with a runtime option "-ea." They aren't a build time thing like you see in C macro based ASSERTS. Regarding what standard framework we should use. At the end of the day I'm trying to move towards Spring TX. The best way to use Spring TX is to use declarative transaction management. The existing ACS code base uses a lot of programmatic tx mgmt. Well, in reality its 100% programmatic. What I mean by programmatic is that in the code you do tx.start(), tx.commit(). With declarative tx mgmt you use AOP to isolate portions of code (like dao methods) to start/commit/rollback the TX. I don't think we will move away from programmatic tx mgmt anytime soon, so if we move to Spring I don't want us to suddenly start using Spring APIs everywhere. Instead I will propose we stay with a light wrapper, which will be the API I already proposed in Option B. It won't be 100% Spring, as we still have a custom light wrapper, but at least at that point, anybody who knows spring TX (or reads the docs) will understand what is going on. Also protects us in the future if some hot new framework comes along we should ideally be able to switch to it. (Random thing, I've noticed in the code instances where the code is doing txn.start() and then multiple txn.commit(). The transaction framework AFAIK wasn't built for this. The first commit will commit or not depending on if the tx was nested. The second commit will either not commit or will destroy the internal state stack of the transaction class as it will commit the parent tx. So, for example, I don't think AlertDaoImpl.archiveAlert() does at all what the programmer who wrote it thought. It's stuff like this that makes me think we just need to bite the bullet, do the hard work, and clean this up.) Darren
