Spring3.0官网文档学习笔记（二）

1.3 使用场景

      典型的成熟的spring web应用

   spring使用第三方框架作为中间层

   远程使用场景

EJB包装

1.3.1 依赖管理、命名规则（包）
    spring-*.jar *号代表的是模块的简写，如：spring-core, spring-webmvc, spring-jms
    可以在四个不同的地方找到Spring：
    http://www.springsource.org/downloads/community  所有的jar包被打包成zip，名称从3.0开始是： org.springframework.*-<version>.jar
    Maven Central, which is the default repository that Maven queries, and does not require any special configuration to use. Many of the common libraries that Spring depends on also are available from Maven Central and a large section of the Spring community uses Maven for dependency management, so this is convenient for them. The names of the jars here are in the form spring-*-<version>.jar and the Maven groupId is org.springframework.


    The Enterprise Bundle Repository (EBR), which is run by SpringSource and also hosts all the libraries that integrate with Spring. Both Maven and Ivy repositories are available here for all Spring jars and their dependencies, plus a large number of other common libraries that people use in applications with Spring. Both full releases and also milestones and development snapshots are deployed here. The names of the jar files are in the same form as the community download (org.springframework.*-<version>.jar), and the dependencies are also in this "long" form, with external libraries (not from SpringSource) having the prefix com.springsource. See the FAQ for more information.


    In a public Maven repository hosted on Amazon S3 for development snapshots and milestone releases (a copy of the final releases is also held here). The jar file names are in the same form as Maven Central, so this is a useful place to get development versions of Spring to use with other libraries depoyed in Maven Central.
1.3.2 Logging（日志）
    日志是Spring唯一的强制性外部依赖。
    Spring将其中一个模块设置成依赖于commons-logging（JCL的典型实现），然后让其他模块在编辑期依赖于这个模块。这个模块是 spring-core。
    commons-logging有一个运行时算法，可以用于运行时发现其他日志框架（位于classPath或者某个指定的地方）
1.3.2.1 不要使用Commons Logging
    如果将时间往回调，然后启动spring，那么应用程序会使用一个不同的日志依赖。最好的选择是SLF4J（Simple Logging Facade for Java）
1.3.2.2 使用 SLF4J
    SLF4J比commons-logging更加简洁、更加方便（因为用编辑期绑定替代了运行时发现整合的其他日志框架）
    A common choice might be to bridge Spring to SLF4J, and then provide explicit binding from SLF4J to Log4J. You need to supply 4 dependencies (and exclude the existing commons-logging): the bridge, the SLF4J API, the binding to Log4J, and the Log4J implementation itself.
    要引入common-logging,slf4j-api,log4j jar包
    A more common choice amongst SLF4J users, which uses fewer steps and generates fewer dependencies, is to bind directly to Logback. This removes the extra binding step because Logback implements SLF4J directly, so you only need to depend on two libaries not four (jcl-over-slf4j and logback). If you do that you might also need to exlude the slf4j-api dependency from other external dependencies (not Spring), because you only want one version of that API on the classpath.
1.3.2.3 使用log4j
    Runtime Containers with Native JCL
    Many people run their Spring applications in a container that itself provides an implementation of JCL. IBM Websphere Application Server (WAS) is the archetype. This often causes problems, and unfortunately there is no silver bullet solution; simply excluding commons-logging from your application is not enough in most situations.
    To be clear about this: the problems reported are usually not with JCL per se, or even with commons-logging: rather they are to do with binding commons-logging to another framework (often Log4J). This can fail because commons-logging changed the way they do the runtime discovery in between the older versions (1.0) found in some containers and the modern versions that most people use now (1.1). Spring does not use any unusual parts of the JCL API, so nothing breaks there, but as soon as Spring or your application tries to do any logging you can find that the bindings to Log4J are not working.
    In such cases with WAS the easiest thing to do is to invert the class loader hierarchy (IBM calls it "parent last") so that the application controls the JCL dependency, not the container. That option isn't always open, but there are plenty of other suggestions in the public domain for alternative approaches, and your mileage may vary depending on the exact version and feature set of the container.