public class MyApplicationContextAwareClass
{

  @Autowired(required = true)
  private ApplicationContext applicationContext;

  // ...
}

Probably not very usable if you like to test your class (or you have to made the property package visible). But if your class is a test it is very nice and quite usefull.

Schon vor einiger Zeit hatte ich bei Frank Westphal über Machine Tags gelesen. Geniales Konzept? Jain. Genial schon, aber eigentlich alles alte Bekannte. Worum geht es?

In Kürze: Normale Tags sind vollkommen ungeordnete Schlagwörter die entweder “vorhanden” oder “zugeordnet” sind oder nicht. Machine Tags haben auch einen Wert und sogar noch einen Namensraum:

<namespace>:<key>=<value>

Also zum Beispiel:

lang:name=java
lang:ver=1.5

Erinnert natürlich stark an XML oder? Oder auch an Properties-Dateien mit Prefixen, wie sie mein Chef gerne verwendet. (Prefixe beispielsweise für Staging, siehe auch Java Magazine 3/07.)

Sie heißen Machine Tags, weil man davon ausgegangen ist, dass sie hauptsächlich von Maschinen benutzt werden würden. Wie Westphals Artikel aber zeigt, ist dies absolut nicht der Fall und sie eröffnen eine ganz neue Dimension des Taggings.

Wie bin ich darauf gekommen diesen Artikel heute wieder auszugraben? Ich habe via iTunes Musik gehört, bewertet, kategorisiert und mich zum wiederholten Mal darüber geärgert, dass man hier nicht vernünftig taggen kann. Ich hatte mir vor einiger Zeit deshalb schon mal ein Tagging-System überlegt, welches ich den Jungs von Songbird vorgeschlagen habe, aber leider in den Wirren ihres beschi... bescheidenen Forums unterging. Und wenn ich drüber nachdenke ist es fast das gleiche.

Was ich würde gerne Tags wie folgend zu vergeben können:

dance:jive=4
dance:foxtrott=5
rating:jens=4
rating:nils=3
rating:jörg=5
rating:anna=4
rating:average=4
occasion:party=5
occasion:cocktails=4
occasion:work=1
...

Man sieht es: Kategorisierte Tags mit Gewichtung. (Hier mit dem praktikablen 1-5 Sterne Prinzip)

Vielleicht sogar:

occasion:party:jens=5
occasion:party:nils=4
occasion:party:joerg=5
...

Dann noch entsprechende Filtrierungen in “intelligenten Wiedergabelisten” und Ad-hoc.

Sahnehäubchen: Das ganze als p2p-social-tagging-community ...

This mornig I had to think a little about how to configure a particular system. Some parts of the system use different implementations of specific modules defined by interfaces. If there should be used a special implementation among the standard one, it is configured in a properties file. The value is the full qualified name of the implementing class, which is loaded and instanciated via reflection. Because we use Java and Java is a statically typed language, we have to cast the instance from Object to the interface.

This is a common pattern, I think. It is used by log4j for example.

Because we use a property configuration, which is not typed and validated against anything, the implementations can be configured as needed.

The opposite may be an XML configuration, which is validated against a schema. If we would use this and wanted to use it continuous for all modules, we had to design an universal schema for all modules or one for every implementation, which is imported into the main configuration.

It is very clear which one is faster and improves development speed. I have seen this pattern with dynamic configurations (even with an xml like syntax) several times in different Java applications and frameworks, but I just remember one with a statically typed, xml based configuration. But even this one used a universal, not really typed schema for the dynamic modules. So I think it’s just the same.

Applications, developed in a statically typed language, but dynamically typed. As I think about it, a common error in those applications are wrong configurations, mostly these little typos you do not find very fast and drive you crazy. Much like in dynamic languages. But would a strong and statically typed configuration, validated against some genius schemas, be worth the effort?

Just a little a thought, that crossed my mind.