[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:XML does not define the constructs that you are asking about. The various products such as Maven, log4j are actually passing the XML through a macro substitution engine that replaces the "${var}" references with their defined values in order to generate the effective working XML. Each of these products has their own substitution engine and dictionary resources, although for convenience, they all stick to pretty much the same standard notational conventions - themselves derived from Unix shell conventions. Had life been a little different, we'd be using "%var%" notation instead.
Another reason why the macro notations for all these products is similar is that often these products are pulling in public library components and thus share common behaviors are supplied by those components. Sometimes the Velocity macro engine is used, for example.
That's the explanation behind the variable substitution part of your question. The "classpath:" part is another story.
In the beginning, resource references were generally pretty simple. For example, you'd get properties from a property file, so your resource reference would be simply the filename path.
However, as time went by, we networked stuff, then we further interconnected stuff via various types of Internet services. The end result of that was the Uniform Resource Locator (URL) notation.
In full, a URL looks like this: "protocol:user@password:server:port/context/resource". One or more of these components may be omitted. For the most part, for example, the user and password parts aren't required. Port is only required if your service has a commonly accepted default port (such as 80 for http or 443 for https) and you wish to override it. For example, 8080 for http on Tomcat.
The actual set of protocols supported by a given system is up to the system implementor as are the places where an application will accept a resource reference in URL form. Common URL protocols include "http", "https", "ldap", "jdbc", "file", and many others. For java systems like the Spring framework, the "classpath" protocol can be used to tell the Spring resource locator to look in the application's classpath for a resource. Since parts of a URL are optional, cases where resources are mostly expected to be in the classpath mean that URLs for these items may omit the "classpath:". Which is useful, since often URL-based definition options are later additions to a more limited earlier resource location function.
Although classpaths are a common case, file-based resource locations being expanded to provide non-file resources are even more common.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |