>>IT security policies will never allow to let passwords and other top-secret info to be hard coded in java files Right now they're stored in text files ;)
The idea is that this JavaConfig isn't hard-compiled into your project with the rest of your classes... You would likely want this class to be compiled _by itself_, not _necessarily_ hard coded in the ear/war... I would hope you could deploy an ear/war once and reconfigure multiple times. A few more rebuttals: * Performance shouldn't be an issue. TomEE already does all sorts of scans on classes. We're reusing an asset we've already created :) * Typing "javac -cp ./tomee/lib/* MyAppsTomEEConfig.java" shouldn't be beyond the reach of server administrators. The idea would be to keep the API simple so it could be edited with VIM * The Java Config API could easily be the base for any text based implementation (XML or prop files) * Honestly, I'm tired of the old way of doing things. XML or prop files mean's we'll end up being a lot like Glassfish and JBoss. I'd rather experiment and try setting a new trend rather than imitating the competition. I come from a shop that was WebSphere/AIX based with strict deployment 'standards' and what not, so I think I understand why you're concerned. -- View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657104.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
