Brad, thanks for adding this information. This is very similar to an approach I've been thinking about. Barry Kaplan also prototyped an somewhat different approach and I've added his example configuration files for discussion purposes. I'd like to create an abstraction for the session settings so an application could either use an existing QF settings file, create the settings directly in a Spring configuration, or plug in an external session configuration provider (possibly supporting dynamic creation and deletion of sessions). I'll look into the Mina 0.9 Spring integration classes and see how those could be incorporated as well. I'm thinking of restructuring the QFJ project to allow a sibling quickfixj-spring subproject that would be released separately from the core quickfixj code. I also want to try using some of the new Spring 2.0 features to make the configuration file easier to manage. I'll add a page soon with ongoing experiments that I'm doing as well. Thanks again. Steve Bate
No worries. I agree that being able to supply other implementations of SessionSettings would be useful. It'd also be nice to have a common interface for initiator/acceptor.
I think in some ways SessionSettings is a bit anti-spring since you're not making use of dependency injection for most of the configuration. Moving away from SessionSettings takes you towards Example - Barry Kaplan which is more flexible at the expensive of a steeper learning curve for quickfix and spring newbies.
I guess it depends whether you want quickfixj powered by Spring internally or just Spring friendly for those who want to use it. Presumably the latter if you're leaning towards an optional subproject, which I think is a good idea.
Here's the basic application context. You supply an Application implementation and quickfix will start up once the application context is loaded. Aside from your Application you also need sample.QuickFixBean which does most of the work.