• Spring 2.0 – Configuration with high-level XML namespaces • Spring 2.5 – Annotation-Driven Injection with @Autowired – Support for JSR-250 @PostConstruct, et al • Spring 3.0 – Code-based config with @Configuration – Support for JSR-330 @Inject standard annotations – Rounded out annotation support 8
improve existing config functionality – Every so often, introduce truly new features – Start minimal, let the feature prove itself, iterate – Evolution, not revolution 9
– It's not going anywhere • @Autowired and component scanning also enjoy wide use – Especially in web tier with @Controller, etc – Stereotype annotations could be used more widely • @Service, @Repository, ... – Custom annotations and using Spring's support for meta- annotations could be used more widely 10 @Transactional @Service @Retention(RUNTIME) @interface MyService { }
XML configuration in src/main – Exposes abstract @Configuration classes as a type-safe contract for configuring Spring applications against RabbitMQ. – Leads to a natural, object-oriented style of dependency injection 11
atop JSR-330 – So any JEE 6 server provides support out of the box – Candi (Resin) – Or standalone implementations may be used • Weld • OpenWebBeans • Guice – JSR-330 "supported but discouraged" • Available only in Guice SVN • http://code.google.com/p/google-guice/wiki/JSR330 • http://stackoverflow.com/questions/1884437/jsr-330-and-guice- interoperability 13
request from community and customers • Specifics vary, but there are common use cases and themes – Promote a single binary through the deployment pipeline of dev -> qa -> staging -> prod. – Smarter support for properties, including hierarchical access, avoiding duplication, etc. • Just search JIRA for 'property' or 'environment' to get a taste. 18
most any environment- related need one way or another with Spring, using imports, property placeholders, etc. • But it's time to make things first class. • Let's take a look at the 'machinery' of Spring 3.1's Environment as it stands today. 19
ApplicationContext implementations – WebApplicationContext implementations – Bean definition readers and scanners • Provides a single access point for properties – Environment.getProperty(String) • As well as various conveniences – Environment.getProperty(String, Class<?>) – Environment.getRequiredProperty(String) 20
• Implementations for Map, Properties, ServletContext, etc – e.g., DefaultEnvironment registers one for system properties, one for environment variables • The Environment's collection of PropertySources is yours to manipulate at container bootstrap time 21
• System environment • System properties • LDAP / JNDI • ServletContext / ServletConfig params • Any Map or Property object instance • Each can be represented by a PropertySource and registered with the Environment 22
a singleton with the container, so can be accessed like any other bean. • #{environment['prop.key']} – translates to: Environment.getProperty("prop.key"); 24
bean definitions to be registered conditionally • Not just about dev->qa->prod • Could also be used to support – Customer A vs. Customer B deployment scenarios – Deploying to different production target platforms (WLS vs JBoss, etc) – Ad-hoc 'switching on' of JMX or other instrumentation 26
@Component public class MyComponent { ... } @Profile("development") @Configuration public class MyConfig { @Bean public TransferService transferService() { ... } } @Profile("development") @Component @Retention(RUNTIME) public @interface DevComponent { ... }
'conditional' constructs in XML • Always been able to defend Spring's XML syntax – not "programming in xml" • Avoid mistakes of Ant, Jelly, etc • Nested <beans> elements may occur only at the bottom of the file – To help mitigate any potential noise 30
all use of xsd:ID types has been removed from the core schemas • Allows for duplicating a bean id across nesting levels • Container still raises an error if a bean is duplicated within the same nesting level 31
If different bean definitions are loaded in production as opposed to testing, QA didn't really test an accurate configuration • Security vs. Convenience tradeoff – It's convenient 33
changing across test and production environments - only simple properties. • Creating a secure build probably involves efforts at the build system level • Don't include dev-only (or otherwise insecure) jars and profiles in the build to be promoted through testing and ultimately to production 34
• 3 'types' of Spring namespace elements – Purely declarative • <context:component-scan/> – References beans and/or methods • <tx:annotation-driven/> – Full-blown "DSLs in XML" • Spring Integration • Spring Batch • Spring Web Flow 41
string identifiers! • Think about – <tx:annotation-driven transactionManager="txManager"/> – Has to be a string in XML, should be a typesafe reference in Java – Therefore, annotations are no good – e.g.: • @AnnotationDrivenTx(transactionManager="txManager") • annotationDrivenTx().withTransactionManager(txManager ()) 44
specific language' for stateful web applications – No automatic way to translate into code – Requires careful design by the Web Flow team – @Flow definitions are here with Web Flow 3.0 45
XML with c: namespace • Introduce first-class environment support – Unified property access via the Spring Environment – Bean definition profile support with @Profile and 'profile' XML attribute • Translate XML namespaces into code – Where it makes sense • Provide deeper support for Groovy – Integrating the BeanBuilder API into core 47
into the usual Spring SVN repository shortly • In the meantime, 3.1.0 snapshots containing (just about) everything you've seen here are already available – http://maven.springframework.org/snapshots • Feedback, please! 48
cbeams
falcon8823
tomokusaba
taigakono
nealle
seike460
takuyakatsusa
chikuwait
zsmb
kohei3110
inusan
ryunen344
yceruto
danielanewman
tammyeverts
palkan
maltzj
holman
philnash
maggiecrowley
notwaldorf
geoffreycrofte
lauravandoore
andyhume
