Consistent use of tabs for sample code in the reference documentation

Author: jhoeller

src/asciidoc/core-beans.adoc

@@ -370,7 +370,7 @@ delegates, e.g. with `XmlBeanDefinitionReader` for XML files:
 ----
 	GenericApplicationContext context = new GenericApplicationContext();
 	new XmlBeanDefinitionReader(context).loadBeanDefinitions("services.xml", "daos.xml");
-    context.refresh();
+	context.refresh();
 ----
 
 Or with `GroovyBeanDefinitionReader` for Groovy files:
@@ -380,7 +380,7 @@ Or with `GroovyBeanDefinitionReader` for Groovy files:
 ----
 	GenericApplicationContext context = new GenericApplicationContext();
 	new GroovyBeanDefinitionReader(context).loadBeanDefinitions("services.groovy", "daos.groovy");
-    context.refresh();
+	context.refresh();
 ----
 
 Such reader delegates can be mixed and matched on the same `ApplicationContext`,
@@ -1682,7 +1682,7 @@ The preceding example is equivalent to the following Java code:
 [source,java,indent=0]
 [subs="verbatim,quotes"]
 ----
-        exampleBean.setEmail("")
+	exampleBean.setEmail("");
 ----
 
 The `<null/>` element handles `null` values. For example:
@@ -1702,7 +1702,7 @@ The above configuration is equivalent to the following Java code:
 [source,java,indent=0]
 [subs="verbatim,quotes"]
 ----
-	exampleBean.setEmail(null)
+	exampleBean.setEmail(null);
 ----
 
 
@@ -3853,7 +3853,6 @@ Find below the custom `BeanPostProcessor` implementation class definition:
 	package scripting;
 
 	import org.springframework.beans.factory.config.BeanPostProcessor;
-	import org.springframework.beans.BeansException;
 
 	public class InstantiationTracingBeanPostProcessor implements BeanPostProcessor {
 
@@ -5261,6 +5260,7 @@ For details about the effects of combining various lifecycle mechanisms, see
 
 [[beans-classpath-scanning]]
 == Classpath scanning and managed components
+
 Most examples in this chapter use XML to specify the configuration metadata that produces
 each `BeanDefinition` within the Spring container. The previous section
 (<<beans-annotation-config>>) demonstrates how to provide a lot of the configuration
@@ -5427,7 +5427,7 @@ comma/semicolon/space-separated list that includes the parent package of each cl
 	@Configuration
 	@ComponentScan(basePackages = "org.example")
 	public class AppConfig  {
-    	...
+		...
 	}
 ----
 
@@ -5532,12 +5532,12 @@ and using "stub" repositories instead.
 [subs="verbatim,quotes"]
 ----
 	@Configuration
-    @ComponentScan(basePackages = "org.example",
-    		includeFilters = @Filter(type = FilterType.REGEX, pattern = ".*Stub.*Repository"),
-    		excludeFilters = @Filter(Repository.class))
-    public class AppConfig {
-    	...
-    }
+	@ComponentScan(basePackages = "org.example",
+			includeFilters = @Filter(type = FilterType.REGEX, pattern = ".*Stub.*Repository"),
+			excludeFilters = @Filter(Repository.class))
+	public class AppConfig {
+		...
+	}
 ----
 
 and the equivalent using XML
@@ -5767,10 +5767,10 @@ fully-qualified class name when configuring the scanner:
 [subs="verbatim,quotes"]
 ----
 	@Configuration
-    @ComponentScan(basePackages = "org.example", nameGenerator = MyNameGenerator.class)
-    public class AppConfig {
-    	...
-    }
+	@ComponentScan(basePackages = "org.example", nameGenerator = MyNameGenerator.class)
+	public class AppConfig {
+		...
+	}
 ----
 
 [source,xml,indent=0]
@@ -5824,8 +5824,8 @@ fully-qualified class name when configuring the scanner:
 	@Configuration
 	@ComponentScan(basePackages = "org.example", scopeResolver = MyScopeResolver.class)
 	public class AppConfig {
-    	...
-    }
+		...
+	}
 ----
 
 [source,xml,indent=0]
@@ -5849,8 +5849,8 @@ the following configuration will result in standard JDK dynamic proxies:
 	@Configuration
 	@ComponentScan(basePackages = "org.example", scopedProxy = ScopedProxyMode.INTERFACES)
 	public class AppConfig {
-    	...
-    }
+		...
+	}
 ----
 
 [source,xml,indent=0]
@@ -6108,7 +6108,7 @@ exact same way as when using Spring annotations:
 	@Configuration
 	@ComponentScan(basePackages = "org.example")
 	public class AppConfig  {
-    	...
+		...
 	}
 ----
 
@@ -6338,7 +6338,7 @@ To enable component scanning, just annotate your `@Configuration` class as follo
 	@Configuration
 	@ComponentScan(basePackages = "com.acme")
 	public class AppConfig  {
-    	...
+		...
 	}
 ----
 
@@ -6657,7 +6657,7 @@ method directly during construction:
 		public Foo foo() {
 			Foo foo = new Foo();
 			foo.init();
-		    return foo;
+			return foo;
 		}
 
 		// ...
@@ -6975,7 +6975,7 @@ another configuration class:
 	@Configuration
 	public class ConfigA {
 
-	 	@Bean
+		@Bean
 		public A a() {
 			return new A();
 		}
@@ -8645,18 +8645,18 @@ environment provides:
 [subs="verbatim,quotes"]
 ----
 	public class EntityCreatedEvent<T>
-    		extends ApplicationEvent implements ResolvableTypeProvider {
+			extends ApplicationEvent implements ResolvableTypeProvider {
 
-    	public EntityCreatedEvent(T entity) {
-    		super(entity);
-    	}
+		public EntityCreatedEvent(T entity) {
+			super(entity);
+		}
 
-    	@Override
-    	public ResolvableType getResolvableType() {
-    		return ResolvableType.forClassWithGenerics(getClass(),
-    				ResolvableType.forInstance(getSource()));
-    	}
-    }
+		@Override
+		public ResolvableType getResolvableType() {
+			return ResolvableType.forClassWithGenerics(getClass(),
+					ResolvableType.forInstance(getSource()));
+		}
+	}
 ----
 
 [TIP]

src/asciidoc/core-resources.adoc

@@ -3,8 +3,11 @@
 = Resources
 
 
+
+
 [[resources-introduction]]
 == Introduction
+
 Java's standard `java.net.URL` class and standard handlers for various URL prefixes
 unfortunately are not quite adequate enough for all access to low-level resources. For
 example, there is no standardized `URL` implementation that may be used to access a
@@ -15,6 +18,8 @@ quite complicated, and the `URL` interface still lacks some desirable functional
 such as a method to check for the existence of the resource being pointed to.
 
 
+
+
 [[resources-resource]]
 == The Resource interface
 
@@ -378,6 +383,7 @@ used. The following two examples show how to force a `ClassPathResource` and a
 
 [[resources-app-ctx-construction]]
 === Constructing application contexts
+
 An application context constructor (for a specific application context type) generally
 takes a string or array of strings as the location path(s) of the resource(s) such as
 XML files that make up the definition of the context.
@@ -439,8 +445,8 @@ this:
 ----
 com/
   foo/
-	services.xml
-	daos.xml
+    services.xml
+    daos.xml
     MessengerService.class
 ----
 
@@ -461,6 +467,7 @@ on the various constructors.
 
 [[resources-app-ctx-wildcards-in-resource-paths]]
 === Wildcards in application context constructor resource paths
+
 The resource paths in application context constructor values may be a simple path (as
 shown above) which has a one-to-one mapping to a target Resource, or alternately may
 contain the special "classpath*:" prefix and/or internal Ant-style regular expressions
@@ -481,6 +488,7 @@ a resource points to just one resource at a time.
 
 [[resources-app-ctx-ant-patterns-in-paths]]
 ==== Ant-style Patterns
+
 When the path location contains an Ant-style pattern, for example:
 
 [literal]
@@ -503,6 +511,7 @@ the wildcards.
 
 [[resources-app-ctx-portability]]
 ===== Implications on portability
+
 If the specified path is already a file URL (either explicitly, or implicitly because
 the base `ResourceLoader` is a filesystem one, then wildcarding is guaranteed to work in
 a completely portable fashion.
@@ -525,7 +534,7 @@ environment before you rely on it.
 
 
 [[resources-classpath-wildcards]]
-==== The Classpath*: portability classpath*: prefix
+==== The classpath*: prefix
 
 When constructing an XML-based application context, a location string may use the
 special `classpath*:` prefix:
@@ -565,13 +574,28 @@ strategy described above is used for the wildcard subpath.
 
 [[resources-wildcards-in-path-other-stuff]]
 ==== Other notes relating to wildcards
+
 Please note that `classpath*:` when combined with Ant-style patterns will only work
 reliably with at least one root directory before the pattern starts, unless the actual
 target files reside in the file system. This means that a pattern like
-`classpath*:*.xml` will not retrieve files from the root of jar files but rather only
-from the root of expanded directories. This originates from a limitation in the JDK's
+`classpath*:*.xml` might not retrieve files from the root of jar files but rather only
+from the root of expanded directories.
+
+Spring's ability to retrieve classpath entries originates from the JDK's
 `ClassLoader.getResources()` method which only returns file system locations for a
-passed-in empty string (indicating potential roots to search).
+passed-in empty string (indicating potential roots to search). Spring evaluates
+`URLClassLoader` runtime configuration and the "java.class.path" manifest in jar files
+as well but this is not guaranteed to lead to portable behavior.
+
+[NOTE]
+====
+The scanning of classpath packages requires the presence of corresponding directory
+entries in the classpath. When you build JARs with Ant, make sure that you do __not__
+activate the files-only switch of the JAR task. Also, classpath directories may not
+get exposed based on security policies in some environments, e.g. standalone apps on
+JDK 1.7.0_45 and higher (which requires 'Trusted-Library' setup in your manifests; see
+http://stackoverflow.com/questions/19394570/java-jre-7u45-breaks-classloader-getresources).
+====
 
 Ant-style patterns with `classpath:` resources are not guaranteed to find matching
 resources if the root package to search is available in multiple class path locations.
@@ -663,4 +687,3 @@ just force the use of a `UrlResource`, by using the `file:` URL prefix.
 	ApplicationContext ctx =
 		new FileSystemXmlApplicationContext("file:///conf/context.xml");
 ----
-