No running
Aus sozialverträglichkeits Gründen werde ich am kommenden Wochenende nicht wie geplant bei der Berliner City-Night an den Start gehen.
Damit bleiben für 2007 noch folgende Starts:
- Helenesee-Triathlon (Olympische Distanz)
- Ironman 70.3 in Wiesbaden
und vielleicht der Berlin-Marathon
Für 2008 sind Moritz, Alex und ich schon für den Ironman 70.3 in Österreich angemeldet.
Es darf also weiter trainiert werden.
Foto Foo Flickr upload [update]
Die Jungs vom Prodev haben ihre Foto-Foo Anwendung um einen Flickr-Upload-Service erweitert.
Hier mein Testbild:
Hat garnicht weh getan.
weiter so Bois :)
unter http://foto-foo.com/portal/flickr-foo gibt’s die flickr-foo public timeline zu sehen.
acts_as_solr I like
Im Rahmen eines neuen Projekts bin ich zur Zeit am Evaluieren einer Suche auf Apache-Solr Basis um eine datenbankbasierte Suche zu vermeiden.
Ich bin ja ein Fan von Lucene. Solr ist eine Art “Server für Lucene” mit dem man XML sprechen kann.I m Hintergrund wird dann Lucene zum Suchen über einen Index verwendet. Update, select, delete etc. geht alles schön einfach via XML. Es gibt auch ein
JSON API.
Die Installation dauert ca. 5 Minuten. Die Solr-Distribution bringt einen eigenen AppServer (Jetty) mit und ist sogleich startbereit.
Ich habe Solr aber in meinen Tomcat (in dem auch meine Applikation läuft) mitlaufen lassen. slor.war ins /webapps und gut ist.
Mehr zur Solrintegration in die WebApp später.
Das eigentlich interessante ist aber, das ich beim stöbern im Netz auf eine Ruby on Rails Plugin gestoßen bin, das es mir erlaubt meine alte datenbankbasierte Suche in meinem domain_managr innerhalb von 10 Minuten gegen eine Solr-Suche auszutauschen.
acts_as_solr.
In kurzen Worten:
Vorraussetzung ist nicht einmal eine vorsinstallierte Solr-Instanz – das Plugin bringt eine eigene mit.
rake solr:start startet den eingebauten Solrserver.
Ich benutze aber weiterhin meinen bereits bestehenden Server – is ja schon da :)
nach der Installation des Plugins mittels:
script/plugin install svn://svn.railsfreaks.com/projects/acts_as_solr/trunk
reicht ein zartes: acts_as_solr im Model:
class Account < ActiveRecord::Base
acts_as_solr
has_many:invoices
end
und die Klasse ist nun für solr bekannt.
Die Änderungen an der Suche:
def search
@query = params[:query] # SQL search
# @accounts = Account.find(:all , :conditions => [ "domain like ? ", '%'+@query+'%'])
# Solr search
res = Account.find_by_solr(@query)
@accounts = res. records()
render_without_layout
end
Nach dieser Änderung benutzt die Suche nun meinen Solr-Server und ich kann dessen ganze "Macht" nutzen.
acts_as_solr I like
... to be continued ...
Spring Bean Instanzierung – wenn ein Singleton kein Singleton mehr ist
Der Anwendungsfall:
Ich möchte eine Klasse z.B. PropertyRepository (als Singleton implementiert) mittels des MBeanExporters von Spring als MBean exportieren. So kann man dann zum Beispiel mit Hilfe der jconsole diese Klasse managen.
Damit der MBeanExporter diese Klasse kennt, muss sie im applicationContext als bean gemapped sein (auch die Klasse eigentlich kein “Bean” ist !) :
Die klassische Singleton Implementation sieht ja wie folgt aus:
private static Singleton instance;
private Singleton(){}
public static Singleton getInstance(){
if (instance == null){
instance = new Singleton();
}return instance;
}
Wobei eine Instanz der Klasse nur über die statische getInstance() Methode geholt werden kann:
Singleton s = Singleton.getInstance();
Innerhalb der getInstance() Methode wird dann ggf. der private Konstruktor aufgerufen um eine Instanz der Klasse zu erzeugen und dem statischen Feld instance zugewiesen.
Der private Konstruktor kann also nur innerhalb der getInstance() Methode aufgerufen werden. So ist sichergestellt, das man es immer mit der selben Instanz zu tun hat. Sollte man meinen.
Da die Klasse aber im Spring applicationContext als bean gemapped ist, instanziert Spring beim Start alle Klassen, die gemapped sind. Hierbei wird auch der private Konstruktor unseres Singleton aufgerufen!
Das führt dazu, das bereits eine Instanz der Klasse erzeugt wird, das statische Feld instance aber immer noch null ist.
Dies führt wiederum dazu, das beim Aufruf von getInstance() die Abfrage : if (instance == null) zu true evaluiert und eine weitere Instanz erzeugt wird.
Jetzt wird diese Instanz auf dem statischen Feld instance zugewiesen. Man bekommt also genau 2 Instanzen des Singletons !
Der Hack um das oben beschriebene Verfahren (“MBean Export über beanmapping”) trotzdem zu verwenden ist:
Man weist die durch den privaten Konstruktor erzeugte Instanz der Klasse noch im Konstruktor der Feld inctance zu:
private Singleton(){So ist das Feld instance nicht null und es wird auch in getInstance() immer das selbe Objekt zurückgegeben – hoffentlich :)
instance = this;
}
