wood burning stoves*
The moose likes Ant, Maven and Other Build Tools and the fly likes Confused by the Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "Confused by the "${var}" notation and "classpath:" in XML config files (log4j, maven, etc.)" Watch "Confused by the "${var}" notation and "classpath:" in XML config files (log4j, maven, etc.)" New topic
Author

Confused by the "${var}" notation and "classpath:" in XML config files (log4j, maven, etc.)

Mike London
Ranch Hand

Joined: Jul 12, 2002
Posts: 1043
Hello,

Our application uses lots of property files that are resolved in xml config files using the "${var}" notation.

I'm not sure exactly how this mechanism works or how the properties are "found" to insert into the "${var}" notation elements.

Also, prefixes like "classpath:" are confusing. Yes, I know what the classpath is, but, again, I'm not sure on the mechanism of how these configuration files use it or resolve it. I'm assuming these are JDK environment variables, but where are they all listed (and, how resolved, etc.).

I've looked at a couple of references online, but can't yet find a clear explanation of this part of XML configuration.

Would appreciate any help or suggestions.

Thanks very much in advance,

mike
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30085
    
149

Mike,
It depends on the technology. In Maven, variables are resolved from properties defined in the pom.xml or settings.xml. I don't recall seeing ${var} in log4j. Can you give an example of something that is confusing you?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Mike London
Ranch Hand

Joined: Jul 12, 2002
Posts: 1043
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.


Tim,

Thank you for such an excellent response!!!

I'm still a bit stuck on how I can really master all these conventions. Presumably, though, most people start with scripts with these notations and just modify or add on to them (like we would do with an Ant script), not do them from scratch. Does that sound right?

I really appreciate the time you took to send me this detailed answer. Very helpful.

Thanks,

mike
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Confused by the "${var}" notation and "classpath:" in XML config files (log4j, maven, etc.)
 
Similar Threads
Using PropertyPlaceholderConfigurer to read in external properties - not working
Usage of FileSystemXmlApplicationContext?
How to run EJB on WEbLogic Application Server??
hibernate.cfg.xml not found
Resource bundle in Prime faces