• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Bartender
Posts: 1971
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Mike London
Bartender
Posts: 1971
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic