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.