Last wednesday I have done a workshop for the Java User Group Görlitz with the topic "OSGi Serviceplatform und Spring DM".

OSGi is a specification for a service-based application framework for Java. While in pure Java you use packages to encapsulate code, with OSGi you have another abstraction layer called "bundles". These bundles can contain many packages and you can define that the bundle "exports" some of these packages. Other bundles can than "import" these exported packages to use that code. You can encapsulate different functionalities into different bundles.

One of the main features of OSGi is the ability to load a bundle at runtime. While the whole application is running you can install, update, start, stop or uninstall a bundle. So when you change some code inside a bundle or you fix a bug, the application don't have to be redeployed to get the new code running.

With Spring DM you can combine the features of OSGi with the Spring framework. This is a great combination to build modular business applications in Java.

• Workshop OSGi und Spring DM (german) as pdf

Last week I was coding a little bit on my music player and as everytime I used my little logging-library log4xul. Most of the time I have the Level of the logger set to "debug" so that it prints every message. Because of this I haven't noticed that I have made a really embarrassing mistake with the logging levels in Log4xul. I have mixed the hierarchy of the levels so that with the logging level set to "DEBUG" the logger only prints this debug-messages while when set to "ERROR" it prints everything.

Of cause this is wrong because you want the exactly reverse thing: When the level is set to "DEBUG" you want to get every message and with level set to "ERROR" you only want to get the error messages.

Now I have fixed this so the Log4xul should now work as expected.

Log4Moz

I have also found out that I have not searched enought for other logging frameworks at the time when I started to write Log4xul. In the meantime I have found the Log4Moz framework which is made for logging within firefox extensions. It is a lot more similar to the "original" Log4J and gives you the possibility to create hierarchically structured loggers for your files.

When I first used Log4Moz I was impressed and intended to use it in the future. But then I switched back to my own logger because Log4Moz has no ability to print the messages in a textbox but only to the JSConsole and to a logfile.

I have tried to write my own TextboxAppender for Log4Moz but it only worked till I hit the reload-button. After this it crashed. I don't know if it even would be possibile to write this kind of appender with the achitecture of Log4Moz.

Last week I finished my HideToolbarsByURL extension. Now I want to explain a little bit how it works. Because I have used this technique in my other project I thought this could probably be usefull for other people as well.

Hide the Toolbar

In Firefox 4 there was a new Addon-Manager introduced which opens itself in a new tab. If you have set your tabbar to be on top of the navigation bar this addons-manager tab has no navigationbar or bookmarksbar. This is realized with the new function hideChromeForLocation of the XULBrowserWindow object. This function is called everytime a tab is shown e.g. when you open a new tab or you switch to another tab. This function gets the current location (URL) of the tab as an argument of the type string. If this function returns true for the location then the toolbars are hidden.

If you want to hide your URL too you have to override this function so it returns true for your location. But if you simply replace this function with your own, other extensions and firefox itself wouldn't be able to use this feature anymore. The recommended way to get your location hidden is to chain your implementation of this function with the original one.

First you save a reference of the original implementation. Then you can override the function with your own. You have to determine if the given location is your desired location and return true. Otherwise call the original implementation.

var old = XULBrowserWindow.hideChromeForLocation

//override the hideChrome funtion with our logic
XULBrowserWindow.hideChromeForLocation = function (aLocation) {
  if (0 === aLocation.indexOf("http://www.lestard.eu")) {
    return true
  }
  //Call the original hideChrome-function
  return old.call(XULBrowserWindow, aLocation)
}

If the current location (aLocation) starts with "http://www.lestard.eu" then return true and hide the Toolbars. Otherwise call the old implementation with the aLocation as argument.

In my extension I put the URLs which should be hidden in an array. In my overridden hideChromeForLocation function I look if the current Location is in that array or not. Because I only want to check the first part of the URL (the domain) I use the nsIURI object from mozilla.

I have finished my work on the "hide-toolbars-by-URL" extension and also submitted it to addons.mozilla.org (AMO). Now they review the addon and look if it's working properly. Within the next days the review process should be finished and then the addon would be visible on the addons-page.

But you can use the addon anyway because it is already available on AMO but not visible in the search-results. So to use it you need the URL which is: https://addons.mozilla.org/de/firefox/addon/hide-toolbars-by-url/

UPDATE: The link isn't working anymore. To use the add-on you will have to download and install it on your own from github.

The code is available at github: https://github.com/manuel_mauky/Hide-Toolbars-by-URLs

Within the next days I want to write some lines on how the addon works so everybody who is interested in can use the code.

With the new Firefox 4 release mozilla has introduced some interesting new features and improvements. Particularly the changes to the GUI are interesting. Now you can pin a Tab as "App Tab" and so the tab is pinned on the left side of the tab-panel and you only see the favicon of this tab. I really like this for applications like google mail and google calender but also for news pages I regularly read.

But there are also problems with this approach. Sometimes I forget that I'm in an AppTab and that I don't want to switch to another page in this Tab. But because I have the URL-bar available it happens that I found another page in the Tab where my "App" should be.

Another issue is that the main goal of the AppTabs is saving space. To support this, wouldn't it be cool to hide the URL-bar and other toolbars when you are in an AppTab? You also couldn't change the location by accident. This is what I thought and so I begun to write a little extension to enable this.

Happily mozilla introduced a technique to do exactly this. For example when you open the new Addon-Manager you see that it is opened in a new tab. If you have set your tabpanel to be on top of the URL-bar you will see the toolbars hidden when you are inside of the Addon-Manager-tab. You can use this technique for every page you want ... at least on paper. Sadly there is no GUI with which you could enable hiding for a specified URL. This is what my extension is doing.

With my extension "Hide Toolbars by URL" you have a new entry in the context menu of every tab with which you can hide this URL. The hiding is connected to the URL, not to the tab. So if you open the same URL in another tab it will also be hidden. But because the exact URL will change when you use the page (i.e. when you follow a link on this domain you will be at another URL) it wouldn't be really cool. So only the first part of the URL is used to determine if the tab should be hidden. I only use "http://www.google.de" - everything behind is cut of. So every "subpage" of "http://www.google.de" will be hidden. I'm not sure if this approach is the bests so I would love to get feedback for this. Probably I will change this in the future.

Of cause the code is free and open source - you can get the code at github.com. There is also the xpi-file you need to install. I will give this extension to the addon-page of mozilla and probably they will add this to there page so you can easily install it the same way you install every extension.

Eine ganze weile schon habe ich hier nichts mehr geschrieben, was jedoch nicht heisst, dass ich völlig untätig war. Ich habe in den letzten Wochen immer wieder Zeit gefunden, um an meiner Idee weiter zu arbeiten, eine eigene Musik-Abspielsoftware zu entwickeln. Diese Fortschritte möchte ich nun auch hier im Blog kommunizieren.

Zunächst einmal etwas ernüchternd: Mein Programm spielt noch keine Musik ab. In der derzeitigen Form ist das Programm nach wie vor eher eine Art Mockup oder GUI-Prototyp dar. Es zeigt, wie ich mir die Programmoberfläche vorstelle und stellt auch einige Bedienkonzepte vor.

Realisiert ist der Player zur Zeit als Firefox-Addon und noch nicht als eigenständige Anwendung. Später wird der Player aber auch ohne Firefox lauffähig sein. Ich möchte aber auch die Variante als Addon beibehalten, weil ich dies fǘr eine Interessante Alternative halte.

Ich werde in den nächsten Tagen noch einmal in einem Artikel zusammenfassen, welche Ziele ich mir für das Projekt gesetzt habe und welche Anforderungen ich erfüllen möchte. Auch werde ich dann erklären, warum ich einen eigenen Player entwickeln möchte, obwohl es ja schon eine ganze Reihe von Playersoftware gibt. Ich möchte in der nächsten Zeit öffters den aktuellen Stand des Projekts hier beschreiben und so den Projektverlauf dokumentieren. Daneben habe ich ein Projekt auf github.com für den Player gestartet. Wer github.com nicht kennt: Dies ist eine Projekt-Hostingseite, die auf dem Verteilten Versionsverwaltungssystem git aufsetzt. Git ist von seinem Funktionsumfang und den dahinter liegenden Konzepten mit Mercurial vergleichbar, welches ich bisher verwendet habe. Ich bin nach wie vor ein Fan von Mercurial, wollte aber aus verschiedenen Gründen auch einmal git und auch github ausprobieren.

Ich habe nun eine erste Version von log4xul fertig gestellt und bei bitbucket hochgeladen. Bisher ist nur ein ein Log-Modus implementiert, bei dem die Meldungen ganz normal auf die JavaScript-Fehlerkonsole geschrieben werden. Ich habe als Log-Level DEBUG, INFO, WARN, ERROR sowie OFF vorgesehen. DEBUG ist für reine Debugging-Meldungen vorgesehen, die während der Entwicklung bei der Fehlersuche interessant sind. In der Regel könnte man diese Meldungen nach dem Finden des entsprechenden Fehlers wieder entfernen.

INFO ist für allgemeine Informationen zum Ablauf des Programms gedacht. Für Warnungen, die zwar kritisch sein können, jedoch das Programm nicht unbedingt am weiteren Ausführen hindern, ist das Level WARN gedacht. Sinnvoll ist dies auch beim Auftreten von Exceptions, die jedoch noch behandelt werden konnten.

Mit ERROR werden Fehlermeldungen gekennzeichnet, die ein weiteres Ausführen des Programms in der Regel unmöglich machen.

Die Level sind hierarchisch in der Reihenfolge DEBUG > INFO > WARN > ERROR > OFF gestaffelt wobei DEBUG das allgemeinste Level ist und alle anderen Level einschließt. Ist das Level beispielsweise auf DEBUG gestellt, werden alle Meldungen angezeigt. Ist das Level dagegen beispielsweise auf WARN gestellt, werden nur Meldungen der Stufe WARN und ERROR angezeigt, die darüber liegenden Meldungen der Stufe Info und Debug jedoch nicht.

Somit kann man beispielsweise während dem Entwickeln das Level auf DEBUG stellen und damit sämtliche Meldungen anzeigen lassen. Wenn die Entwicklung abgeschlossen ist, stellt man das Level zurück auf WARN und blendet damit alle DEBUG- und INFO-Meldungen aus und lässt nur die kritischen ERROR- und WARN-Meldungen anzeigen. Mit OFF wird das Logging komplett abgestellt.

Demo-Addon

Log4xul ansich ist kein Addon sondern nur eine JavaScript-Bibliothek, die in ein Addon eingebunden werden kann. Um dies zu demonstrieren, habe ich ein Demo-Addon geschrieben, welches die Bibliothek verwendet. Dabei sind in der GUI bereits weitere Logging-Modi (bei Log4j werden diese "Appender" genannt weshalb ich die Bezeichnung übernommen habe) vorgesehen, die aber erst noch implementiert werden müssen.

Man wählt in der Demo die Appender aus, die man testen möchte und stellt den LogLevel ein. Mit einem Klick auf "Log" wird die Meldung, die man in das Textfeld eingibt, geloggt. Intern werden dabei log-Aufrufe für alle Level ausgeführt, es werden aber nur die jenigen angezeigt, dessen Level eingestellt ist.

Um auf die Demo zuzugreifen muss diese mit der xpi-Datei installiert werden. Danach kann die Demo über die Adresszeile unter der URL "chrome://log4xul/content/log4xul_demo.xul" aufgerufen werden. Das Addon ist zwar prinzipiell kompatibel zur Firefox-Version 4, allerdings ist dort die JavaScript-Konsole wohl etwas umgebaut worden, sodass aktuell keine Meldungen angezeigt werden. Ausserdem fehlen noch Addons wie Console2 für FF4, die einen vernünftigen Umgang mit der JavaScript-Console bieten.

Zu finden ist das Addon inklusive der Bibliothek unter https://bitbucket.org/lestard/log4xul/overview

Viel Spaß beim Ausprobieren.

Heute bin ich auf ein interessantes Projekt namens "Promote JS" aufmerksam geworden, welches sich zum Ziel gesetzt hat, gute JavaScript-Dokumentationen zu fördern. Das Problem ist dabei nicht, dass es nicht solche erstklassigen Dokumentationen gäbe, sondern dass diese bei der normalen Sucher in den Googleergebnissen ziemlich weit hinten erscheinen. In den ersten Ergebnissen sind dagegen meistens nur mittelmäßige, mit Werbung überflutete und unübersichtliche Hilfeseiten. Erstklassige Dokumentationen wie die vom Mozilla-Developer-Center (MDC) sind oft erst weiter unten zu finden.

Da die Suchergebnisse bei Google bekanntlich unter anderem von der Anzahl der Verlinkungen abhängen, soll durch PromoteJS dazu aufgerufen werden, eben diese guten Dokumentationen auf dem eigenem Blog zu verlinken. Auf diese Weise soll die Dokumentation von MDC in den Suchergebnissen nach oben steigen. Da mir das MDC schon unzählige Male weiter geholfen hat und ich von der Qualität der Dokumentation überzeugt bin, halte ich das für eine gute Idee und möchte mich daran beteiligen. An der Seite gibts deshalb ab sofort einen Button, der auf ein Thema in der MDC-Dokumentation verlinkt.

Den Link zum PromoteJS-Projekt gibts hier: http://promotejs.com/

Vor kurzem hatte ich schon die Idee für ein XUL-Logging-Framework geäussert. In der vergangenen Woche habe ich schon ein wenig daran gearbeitet und bin auch zu ersten Ergebnissen gekommen. Ein solches Projekt macht aber natürlich nur dann Sinn, wenn es als OpenSource für jedermann zur Verfügung steht. Um das zu ermöglichen, habe ich heute bei bitbucket.org dafür ein Projekt erzeugt.

Für die, die bitbucket nicht kennen: Bitbucket.org ist eine Plattform zur gemeinsamen Entwicklung von freier Software, vergleichbar mit github oder dem etwas älteren sourceforge. Bitbucket setzt auf das verteilte Versionsverwaltungssystem Mercurial (kurz 'hg' genannt). Jeder kann den Programmcode online im Browser betrachten oder ihn sich per hg auf den eigenen Rechner ziehen.

Zum gegenwärtigen Zeitpunkt ist aber noch kein Code im Repository zu finden. Dies werde ich entweder heute Abend oder am Wochenende noch erledigen.

Die URL zum Projekt ist: https://bitbucket.org/lestard/log4xul

In meiner Freizeit bastel ich ja öffters mal mit XUL und Firefox-Addons herum. Da ich ja eigentlich Java-Programmierer bin, habe ich mich auch an die ein oder andere Annehmlichkeit gewöhnt, die dort üblich ist. Eine dieser Annehmlichkeiten ist das Logging, das ja quasi in jedem Projekt wie selbstverständlich mit benutzt wird.

Der Logger ist ein Programmteil, dem man einfache Meldungen mitgeben kann, welche dieser bei der Ausführung anzeigt. Man kann dabei verschiedene Wichtigkeits-Stufen für einzelne Meldungen bestimmen und so festlegen, ob eine Meldung nun "nur" ein Debug-Hinweis ist oder gar einen schweren Fehler anzeigt. Vor der Ausführung kann man dann auch einstellen, ob man diesmal nur schwere Fehler sehen möchte oder auch unwichtige Meldungen. Wenn man seine Software z.B. fertig zum Kunden gibt, sollte man diesen schließlich vor reinen Entwickler-Hinweisen verschonen, während man beim Entwickeln gerne die ein oder andere Statusmeldung sehen möchte.

Wie gesagt: In Java üblich, bei XUL aber zumindest in der Standardausführung des XUL-Runners nicht vorgesehen bzw. zumindest nicht in diesem Funktionsumfang. Bei meinen bisherigen Basteleien in XUL war einer der Ersten Schritte deshalb immer, mir erstmal eine eigene kleine Logger-Funktion zu schreiben, die Meldungen in einem Text-Feld in der GUI ausgibt. Den Funktionsumfang wie oben beschrieben hatte ich dabei natürlich nicht, obwohl das ja eigentlich schon auch praktisch wäre.

Aus diesem Grund bin ich der Sache mal nachgegangen und bin auf zwei Logging-Frameworks für JavaScript gestoßen. Zum einen Log4JS, welches ebenfalls wie Log4J - der Quasi-Standard bei JAVA - vom Apache-Team entwickelt wird. Zum anderen Log4JavaScript. Beide machten beim testen in einer Webseite eine gute Figur jedoch funktionierte die Einbindung in XUL nicht so wirklich. Das ist natürlich verständlich, da der Fokus der Frameworks natürlich bei HTML-Dokumenten liegt und diese darauf ausgelegt sind. Ein Großteil der Funktionalität der Frameworks wird für XUL auch nicht benötigt. So kann Log4JS z.B. Logmeldungen über AJAX an einen Server übertragen. Dies ist für Webseiten durchaus interessant, macht aus meiner Sicht für XUL-Anwendungen oder BrowserAddons aber wenig Sinn.

Die Überlegung ging deshalb in die Richtung, aus meinen eigenen kleinen Logger-Basteleien eventuell ein auf XUL angepasstes Logging-Framework zu entwickeln. Wenn die Freizeit das zulässt, wäre dies eins meiner nächsten Projekte.