> > > Both would actually function. User preference would dictate which is used. > > Thoughts? Given the choice, which would you use? See any third options > that might be cooler? > > AppContext, ModuleContext, and BeanContext would each get a > `<Configuration>` bucket. There might be a better name than > `<Configuration>`. Maybe `<Properties>` or perhaps even better, > `<Options>` ? >
I prefer the properties tag first because we always used it, then (as already mentioned) because it reinforce the syntax we wanna use, and last because almost all the container can the configured (overridden) by system properties. The fully qualified names is better IMO. Ideas on something better? Better names maybe? Perhaps `<PojoContext>` > for consistency. Perhaps get really basic and `<ClassContext>` ? > ClassContext is ok for me as soon as we allow inheritance. I mean, define ClassContext (even for an ejb or an abstract name) and allow ejb (ie. BeanContext) inherit from it. That's useful when configurations are similar and painful to maintain for a lot of ejbs (wss4j for example) or when we want to deploy an ejb more than one. > ## Standalone apps vs apps with many modules > > No special opinion. I'd say more or less like Karan, the less to remember, the better. With the validation framework and good messages, that should work fine. Otherwise a new root tag is also great. BTW, like exabrial sample (on pastee). Would be great to also support such a mechanism. Regarding XSD versus properties, definitely +1 for properties. XSD can be fine in IDE, but it will be painful for end users and for use to maintain and move forward. Hope it helps. I'm happy to contribute if necessary. Jean-Louis
