All Packages from org.springframework.core.io.* to org.springframework.core.io.support.*

Home >> All >> org >> springframework >> [ core Javadoc ]

•

org.springframework.core.io.support.* (3)

• org.springframework.core: Javadoc index of package org.springframework.core.

Package Samples:

• org.springframework.core.io: Basic classes facilitating exception handling, and providing core interfaces that are not specific to any part of the framework.
• org.springframework.core.io.support: Generic abstraction for (file-based) resources, used throughout the framework.

Classes:

• PathMatchingResourcePatternResolver: ResourcePatternResolver implementation that applies Ant-style path matching, using Spring's PathMatcher class. Locations can either be suitable for ResourceLoader.getResource (URLs like "file:C:/context.xml", pseudo-URLs like "classpath:/context.xml", relative file paths like "/WEB-INF/context.xml"), or Ant-style patterns like "/WEB-INF/*-context.xml". In the pattern case, the location has to be resolvable to java.io.File or to a "jar:" URL (leading to a java.net.JarURLConnection ) to allow for searching though the specified directory tree. In particular, this is not guaranteed to work with a WAR ...
• NestedCheckedException: Handy class for wrapping checked Exceptions with a root cause. This time-honoured technique is no longer necessary in Java 1.4, which finally provides built-in support for exception nesting. Thus exceptions in applications written to use Java 1.4 need not extend this class. To ease migration, this class mirrors Java 1.4's nested exceptions as closely as possible. Abstract to force the programmer to extend the class. getMessage will include nested exception information; printStackTrace etc will delegate to the wrapped exception, if any. The similarity between this class and the NestedCheckedException ...
• NestedRuntimeException: Handy class for wrapping runtime Exceptions with a root cause. This time-honoured technique is no longer necessary in Java 1.4, which finally provides built-in support for exception nesting. Thus exceptions in applications written to use Java 1.4 need not extend this class. To ease migration, this class mirrors Java 1.4's nested exceptions as closely as possible. Abstract to force the programmer to extend the class. getMessage will include nested exception information; printStackTrace etc will delegate to the wrapped exception, if any. The similarity between this class and the NestedCheckedException ...
• ResourcePatternResolver: Strategy interface for resolving a location pattern (for example, an Ant-style path pattern) into Resource objects. This is an extension to the base ResourceLoader interface. A passed-in ResourceLoader (for example, an ApplicationContext passed in via ResourceLoaderAware when running in a context) can be checked whether it implements this extended interface too. Can be used with any sort of location pattern (e.g. "/WEB-INF/*-context.xml"): Input patterns have to match the strategy implementation. This interface just specifies the conversion method rather than a specific pattern format. This interface ...
• Constants: This class can be used to parse other classes containing constant definitions in public static final members. The asXXXX methods of this class allow these constant values to be accessed via their string names. Consider class Foo containing public final static int CONSTANT1 = 66; An instance of this class wrapping Foo.class will return the constant value of 66 from its asNumber method given the argument "CONSTANT1" . This class is ideal for use in PropertyEditors, enabling them to recognize the same names as the constants themselves, and freeing them from maintaining their own mapping.
• ResourceLoader: Interface to be implemented by objects that can load resources. An ApplicationContext is required to provide this functionality, plus extended ResourcePatternResolver support. DefaultResourceLoader is a standalone implementation that is usable outside an ApplicationContext, also used by ResourceEditor. Bean properties of type Resource and Resource array can be populated from Strings when running in an ApplicationContext, using the particular context's resource loading strategy.
• CollectionFactory: Factory for collections, being aware of JDK 1.4+ extended collections and Commons Collection 3.x's corresponding versions for older JDKs. Mainly for internal use within the framework. The goal of this class is to avoid runtime dependencies on JDK 1.4+ or Commons Collections 3.x, simply using the best collection implementation that is available. Prefers JDK 1.4+ collection implementations to Commons Collections 3.x versions, falling back to JDK 1.3 collections as worst case.
• InputStreamResource: Resource implementation for a given InputStream. Should only be used if no specific Resource implementation is applicable. In contrast to other Resource implementations, this is a descriptor for an already opened resource - therefore returning true on isOpen(). Do not use it if you need to keep the resource descriptor somewhere, or if you need to read a stream multiple times.
• ResourceEditor: Editor for Resource descriptors, to automatically convert String locations (e.g. "file:C:/myfile.txt" or "classpath:myfile.txt") to Resource properties instead of using a String location property. The path may contain ${...} placeholders, to be resolved as system properties: e.g. ${user.dir}. Delegates to a ResourceLoader, by default a DefaultResourceLoader.
• ResourceArrayPropertyEditor: Editor for Resource descriptor arrays, to automatically convert String location patterns (e.g. "file:C:/my*.txt" or "classpath*:myfile.txt") to Resource array properties. The path may contain ${...} placeholders, to be resolved as system properties: e.g. ${user.dir}. Delegates to a ResourcePatternResolver, by default a PathMatchingResourcePatternResolver.
• ClassPathResource: Resource implementation for class path resources. Uses either the thread context class loader, a given ClassLoader or a given Class for loading resources. Supports resolution as java.io.File if the class path resource resides in the file system, but not for resources in a JAR. Always supports resolution as URL.
• Resource: Interface for a resource descriptor that abstracts from the actual type of resource, like file or class path resource. An InputStream can be opened for every resource if it exists in physical form, but a URL or File handle can just be returned for certain resources. The actual behavior is implementation-specific.
• FileSystemResourceLoader: ResourceLoader implementation that resolves paths as file system resources rather than as class path resources (DefaultResourceLoader's strategy). FileSystemXmlApplicationContext is a full-fledged ApplicationContext implementation that provides the same resource path resolution strategy.
• AbstractResource: Convenience base class for Resource implementations, pre-implementing typical behavior. The "exists" method will check whether a File or InputStream can be opened; "isOpen" will always return false; "getURL" and "getFile" throw an exception; and "toString" will return the description.
• OrderComparator: Comparator implementation for Ordered objects, sorting by order value ascending (resp. by priority descending). Non-Ordered objects are treated as greatest order values, thus ending up at the end of the list, in arbitrary order (just like same order values of Ordered objects).
• ErrorCoded: Interface that can be implemented by exceptions etc that are error coded. The error code is a String, rather than a number, so it can be given user-readable values, such as "object.failureDescription". An error code can be resolved by a MessageSource, for example.
• DefaultResourceLoader: Default implementation of the ResourceLoader interface. Used by ResourceEditor, but also suitable for standalone usage. Will return an UrlResource if the location value is a URL, and a ClassPathResource if it is a non-URL path or a "classpath:" pseudo-URL.
• ControlFlowFactory: Static factory to conceal automatic choice of Java 1.4 or 1.3 ControlFlow implementation class. We want to use the more efficient Java 1.4 StackTraceElement if we can, but we don't want to impose a runtime dependency on JDK 1.4.
• Ordered: Interface that can be implemented by objects that should be orderable, e.g. in a Collection. The actual order can be interpreted as prioritization, the first object (with the lowest order value) having the highest priority.
• AbstractPathResolvingPropertyEditor: Abstract base class for PropertyEditors that need to resolve placeholders in paths. A path may contain ${...} placeholders, to be resolved as system properties: e.g. ${user.dir}.
• ControlFlow: Interface to be implemented by objects that can return information about the current call stack. Useful in AOP (as in AspectJ cflow concept) but not AOP-specific.
• JdkVersion: Helper class used to find the current Java/JDK version. Usually we want to find if we're in a 1.4 or higher JVM. (Spring does not support 1.2 JVMs.)
• UrlResource: Resource implementation for java.net.URL locators. Obviously supports resolution as URL, and also as File in case of the "file:" protocol.

Home | Contact Us | Privacy Policy | Terms of Service