Jedoch gibt es dabei auch falsche Warnmeldungen wenn JsLint nicht richtig konfiguriert ist. So warnt mich Netbeans 7.1 dann bei einer JavaScript Datei, als externe Ressource zusammen mit jQuery in eine Webseite eingebunden ist:

“$ was used before it was defined”

Dies lässt sich beheben, indem man die JSLint Konfiguration (Tools->Options->Misc->JSLint) aufruft und dort unter “predefined” das “$” deklariert. Leider wurde diese Einstellung bei mir  nicht korrekt gespeichert und hatte auch keine Auswirkungen auf das Verhalten von JSLint. Ich nehme an, dass der Fehler mit einem Update des Plugins behoben wird.

Artikel von: everflux.de

Netbeans 7.1, JSLint und jQuery: $ used before defined

Ähnliche Beiträge:

1. Netbeans JavaScript Support, PHP und andere Features
2. Netbeans 6.5 released
3. jQuery: HTML Inhalt einfärben
4. Fileupload für Bilder mit jQuery – dank Ajax mit Vorschaufunktion

Das ist nervig, denn bisher ging es auch ohne – dabei nutzt Netbeans die von modernen Betriebssystemen bereitgestellte native Infrastruktur um Passwörter zu speichern. (z.B. Keychain auf dem Mac, Gnome-Keyring o.ä.) Normalerweise funktioniert das auch – aber seit Gnome 3 hat sich da offenbar etwas geändert.

Debuggen kann man die Netbeans Keyring Integration indem man folgende Option in der etc/netbeans.conf zu den netbeans_default_options ergaenzt:

-J-Dorg.netbeans.modules.keyring.level=0

Anschließend sieht man in ~/.netbeans/7.0/var/log/messages

FINE [org.netbeans.modules.keyring.kde.KWalletProvider]: application exit with code 2 for commandString: [qdbus, org.kde.kwalletd, /modules/kwalletd, org.kde.KWallet.isEnabled]; errVal: Service 'org.kde.kwalletd' does not exist.
FINE [org.netbeans.modules.keyring.gnome.GnomeProvider]
java.lang.UnsatisfiedLinkError: Unable to load library 'gnome-keyring': libgnome-keyring.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:379)
at org.netbeans.modules.keyring.gnome.GnomeKeyringLibrary.<clinit>(GnomeKeyringLibrary.java:62)
[catch] at org.netbeans.modules.keyring.gnome.GnomeProvider.enabled(GnomeProvider.java:88)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:72)
at org.netbeans.api.keyring.Keyring.save(Keyring.java:109)
at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry$5.run(ServerRegistry.java:731)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)

Nachdem ich sichergestellt habe, dass die Library installiert ist:

sudo apt-get install libgnome-keyring0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgnome-keyring0 is already the newest version.

bleibt die Frage: Wieso findet Netbeans die gesuchte Library nicht? Die Lösung: Die Gnome Keyring Library ist nur noch mit einem anderen Dateinamen verfügbar, mit angehängter “0″. Das gab es zwar früher schon immer, dass die Libraries ohne Versionsnummer (oder was das ist) lediglich ein Symlink auf die “echte” Library waren, aber immerhin gab es die. (Da gibt es bestimmt einen guten Grund und viel Logik für, dass das abgeschafft wurde – mir erschließt sich das jedoch nicht.)
Der simple Work-Around ist daher:

sudo ln -s /usr/lib/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so

und danach funktioniert Netbeans wieder tadellos. Also gab es offenbar keine inkompatiblen API Änderungen, sondern “lediglich” eine Änderung des Library-Namens. Ob das ein Ubuntu/Debian Paketierungsproblem ist, oder ab Gnome 3 einfach die neue Marschrichtung, kann ich nicht sagen.

Update: Ich hab dazu ein Bug im Netbeans Issuetracker aufgemacht. Wer voten möchte – gerne: http://netbeans.org/bugzilla/show_bug.cgi?id=203735

Artikel von: everflux.de

Ubuntu Oneiric: Netbeans Master-Passwort / Keyring Integration

Ähnliche Beiträge:

1. Ubuntu Oneiric: Latex Papierformat
2. Ubuntu Lucid LTS Server auf Oneiric Updaten
3. Netbeans 6.5 released
4. Oneiric update auf VM Gast bricht ab

Beispielsweise so:

<dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>servlet-api</artifactId>
   <version>2.5</version>
   <scope>provided</scope>
</dependency>

Damit funktioniert die Entwicklung dann auch prinzipiell – bis auf rote Hinweise und Fehlermeldungen im Netbeans JSP Editor:

“package javax.servlet.jsp does not exist”
(cannot find symbol)

und so weiter und so fort. Bei allen JSP Direktiven, JSP Deklarationen etc. gibt es einen Hinweis darauf, dass Netbeans da etwas im Classpath fehlt. Und Netbeans hat dabei auch Recht – wenn man die JSP API nicht ebenfalls als Projekt Abhängigkeit deklariert. Hier hilft also ein kleiner Zusatz in der Maven pom.xml, der so aussehen könnte:

<dependency>
   <groupId>javax.servlet.jsp</groupId>
   <artifactId>jsp-api</artifactId>
   <version>2.1</version>
   <scope>provided</scope>
</dependency>

Hier ist die JSP Version 2.1 passend zur Servlet API 2.5 gewählt. Anschließend einmal “clean and build” in Netbeans geklickt, und die “package javax.servlet.jsp does not exist” Fehler sind behoben.

Artikel von: everflux.de

Netbeans: “package javax.servlet.jsp does not exist” (cannot find symbol)

Ähnliche Beiträge:

1. Java Servlet (Spring Controller) auf Root Path mappen
2. Hamcrest, Junit: NoSuchMethodError zur Test Laufzeit
3. Maven2: javax transaction jta missing – not really.
4. GridGain und Maven

Hudson ist mein bevorzugter Buildserver (auch wenn Bamboo wirklich ansprechender ist, aber eben auch eine Ecke teurer und nicht OpenSource) – und es gibt auch ein Plugin fuer Hudson, mit dem man ein Deployment anstarten kann: http://wiki.hudson-ci.org/display/HUDSON/Deploy+Plugin
Leider funktioniert das bei dem Glassfish nicht, wenn Hudson nicht auf dem selben Server läuft, wie der Glassfish. (Das sollte/dürfte der Regelfall sein.)

Nachdem der Bug bei Hudson bekannt ist, wollte ich das “mal eben” beheben. Sollte keine so grosse Sache sein, zumindest für den Hausgebrauch:

• jelly File anpassen (fuer Eingabe des Hostnamens)
• Hostnamen verwenden um Cargo zu konfigurieren
• Plugin bauen und installieren

Leteres war am einfachsten. Hudson ist wirklich kinderleicht für Entwickler zugänglich, sogar wenn man nur ein einzelnes Plugin bauen möchte. Ich habe dazu einfach nur das Deploy Plugin aus dem Subversion bezogen:

svn co https://svn.java.net/svn/hudson~svn/trunk/hudson/plugins/deploy hudson-deploy

und anschließend mittels “mvn clean install” gebaut. Möchte man nur einmal kurz testen ob alles tut, kann man mittels

mvn org.jvnet.hudson.tools:maven-hpi-plugin:run

Hudson samt dem Plugin in einem Jetty lokal starten. Netbeans (und IntelliJ IDEA) können mit Maven Projekten gut umgehen, so kann man einfach das ausgecheckte Verzeichnis öffnen und direkt loslegen.
Der Plugin-Patch für einen Hostnamen im Hudson Glassfish Deploy Plugin ist relativ kurz und besteht im wesentlichen nur darin den zusätzlichen Konfigurationsparameter abzufragen und an @Property(GeneralPropertySet.HOSTNAME) zu binden.
Dann folgt schnell die Ernüchterung. Es gibt auch bei Codehaus Cargo, der Bibliothek die von dem Deploy Plugin verwendet wird, um das tatsächliche Deployment in einem Container durchzuführen, mehrere Tickets mit Fehlermeldungen, dass kein Remote-Deployment von Codehaus Cargo bei dem Glassfish Applikationserver unterstützt wird.
Hier bekomme ich jetzt die Sorge, dass ich mich auf den Weg mache einen Yak zu scheren.
Codehaus Cargo wird ebenfalls mit Maven gebaut und kann per Subversion ausgecheckt werden:

svn co http://svn.codehaus.org/cargo/trunks cargo-trunk

Das Bauen klappt “nicht so gut” – die Checkstyle Einstellungen sind so, dass der API Teil nicht baut. (“Logmeldungen sollten mit einem Punkt enden” und dergleichen besonders wichtige Regeln verhindern das.) Pragmatische Abhilfe hilft hier schnell das Testen und Checkstyle auszudrehen:

mvn -DskipTests=true -Dcheckstyle.skip=true install

Schön ist das nicht, aber es handelt sich eben um “trunk”. Der Build bricht auch dann noch ab, aber erst bei dem JBoss Container, und der Glassfish v3 Container für Cargo baut einwandfrei.
Der Code selber… mit spitzen Fingern und ohne das Gefühl wirklich zu wissen, was ich da tue finde ich mehrere Stellen an denen die Strings zum Aufruf von “asadmin”, dem Glassfish CLI Administrationstool zusammengebaut werden.
Ich wollte mich auch nicht tiefergehend mit dem Code beschäftigen, der Patch für Cargo ist relativ einfach gemacht (u.U. nicht vollständig, aber bei mir tat es):

Index: src/main/java/org/codehaus/cargo/container/glassfish/GlassFishInstalledLocalDeployer.java
===================================================================
--- src/main/java/org/codehaus/cargo/container/glassfish/GlassFishInstalledLocalDeployer.java (revision 2596)
+++ src/main/java/org/codehaus/cargo/container/glassfish/GlassFishInstalledLocalDeployer.java (working copy)
@@ -29,6 +29,7 @@
import org.codehaus.cargo.container.deployable.WAR;
import org.codehaus.cargo.container.deployer.DeployerType;
import org.codehaus.cargo.container.glassfish.internal.AbstractGlassFishInstalledLocalContainer;
+import org.codehaus.cargo.container.property.GeneralPropertySet;
import org.codehaus.cargo.container.property.RemotePropertySet;
import org.codehaus.cargo.container.spi.deployer.AbstractLocalDeployer;

@@ -201,6 +202,8 @@
args.add(this.getConfiguration().getPropertyValue(RemotePropertySet.USERNAME));
args.add(“–passwordfile”);
args.add(this.getConfiguration().getPasswordFile().getAbsolutePath());
+ args.add(“–host”);
+ args.add(this.getConfiguration().getPropertyValue(GeneralPropertySet.HOSTNAME));
}

}

Letztes wehwehchen: Da Codehaus Cargo mit Subversion Externals arbeitet, liefert ein “svn diff” im Rootverzeichnis erstmal keine Ausgabe. Nicht das letzte was an diesem Projekt verwirrend war.
Wer gerne den Erfolg testen möchte, hier ist ein fertig gepatchte Deployer Plugin für Hudson (deploy.hpi). Der Hostname kann unter “advanced” eingestellt werden. Keine Garantie, Verwendung auf eigene Gefahr. (Wer Lust hat, die Patches bei den jeweilligen Projekten als ersten Vorschlag einzureichen – nur zu!)

Fazit: So macht OpenSource Spass. Nicht zuletzt weil die Projekte entsprechend leicht zugaenglich sind (Subversion, Maven) und weil es gute freie Tools gibt (Maven, Netbeans) mit denen der Einstieg leicht fällt.

Artikel von: everflux.de

Yak scheren: Hudson remote Deploy auf Glassfish (v3)

Ähnliche Beiträge:

1. Glassfish remote Monitoring mit VisualVM auf Ubuntu
2. Hudson + Maven: java.net.SocketTimeoutException: Accept timed out
3. GlassFish v3 Prelude: Der neue Glassfish ist da
4. Glassfish 3.1: Probleme mit DWR 2 (und mehr)

Ganz neu ist der Java FX Composer: Bei dem JavaFX Composer handelt es sich um ein Layout-Tool mit dem grafische Anwendungen, die auf JavaFX basieren, erstellen lassen. der JavaFX Composer ist damit vergleichbar mit dem Swing Layout Tool Matisse, mit dem Netbeans bereits in der Vergangenheit viele Fans gewinnen konnte.

Oracle moechte mit JavaFX eine RIA (Rich Internet Application) Platform etablieren, die sich mit Flash/Air (Adobe) und  der Silverlight (Microsoft) Technologie konkurriert. Oracle möchte JavaFX auch fuer Enterprise Anwendungen etablieren, dabei sollen Data-Binding und eine umfangreiche Komponenten Bilbiothek helfen.

Ebenfalls für Java Enterprise Entwickler interessant ist der OSGi Support, der in Netbeans 6.9 erstmals Einzug hält. Damit können OSGi Bundles mit Netbeans erstellt und auch in Anwendungen integriert werden, die die Netbeans Platform als Framework nutzen. Dabei werden Equinox und Apache Felix als OSGi Container unterstützt.

Das Spring Framework wird nun in Version 3 unterstützt, und ein Entwickler kann dabei von Code-Completion als auch Applikationsvorlagen profitieren. Auch JSR 299 “Context and Dependency Injection” findet sich nun in Netbeans wieder.

Mein “Lieblingsfeature” ist die Möglichkeit per ctrl-alt-click auf eine Interface Methode direkt zu einer Implmentierung springen zu können. Das geht noch schneller als der in Eclipse übliche Weg über die quick-type-hierarchie – wer viel mit Interfaces (z.B. Spring) arbeitet, wird das Feature bald nicht mehr missen wollen.

Auch die Performance ist gut, und Kleinigkeiten wie CSS Refactoring und verbesserte Maven Unterstützung runden den insgesamt guten Eindruck ab.

Netbeans 6.9 gibt es auf http://www.netbeans.org/ kostenlos zum Download für alle Plattformen, lediglich Java muss installiert sein.

Artikel von: everflux.de

Oracle veröffentlicht Netbeans 6.9

Ähnliche Beiträge:

1. OpenJDK, Java 7 und Oracle
2. Oracle Coherence/Fusion Middleware Wettbewerb
3. Java 6u15: Oracle Branding
4. Zend Framework 1.5 für PHP 5 veröffentlicht

Doch an einer Stelle hakt es etwas: Moechte von Maven dependencies auch den Source Code bzw. JavaDoc zur Verfuegung haben, reicht es nicht, wenn man (wie üblich) ueber die Maven Properties
<downloadSources>true</downloadSources> und <downloadJavadocs>true</downloadJavadocs> den Download aktiviert.

Klickt man noch auf die Libraries in der Projektansicht mit der rechten Maustaste, so kann man die Einbindung von JavaDoc und Sourcecode aktivieren, und es funktioniert auch das Maus+Ctrl+Click um in den Quellcode der verwendete Typen zu springen.

Eine Alternative dazu besteht in den allgemeinen Maven Einstellungen, hier kann man JavaDoc und Quellcode checks für Maven Artefakte und Abhängigkeiten aktivieren. So kann man einstellen, dass beim ersten Öffnen eines Projektes, oder bei jedem Projektöffnen nach aktuellen JavaDoc und Java Sourcen gesucht werden soll.

Dies verlängert natürlich das Öffnen von Projekten, hier muss jeder Entwickler selber entscheiden, wie er gerne vorgehen möchte.

Artikel von: everflux.de

Netbeans: Maven Source und JavaDoc

Ähnliche Beiträge:

1. GridGain und Maven
2. Netbeans JavaScript Support, PHP und andere Features
3. Netbeans: “package javax.servlet.jsp does not exist” (cannot find symbol)
4. Spring Framework: SNAPSHOT Versionen per Maven

In diesem Fall ging es darum, dass mit Netbeans /ant produzierte Artefakte als einzelne JAR Datei verteilbar sein sollten. D.h. alle Bibliotheken bzw. Library JAR Files sollten in einem einzelnen, ausführbaren JAR landen.Die Lösung dafür erfordert (minimalen) manuellen Aufwand, doch funktioniert es dafür tadellos. Die Netbeans Entwickler haben mehrere Phasen im Ant Build vorgesehen, an dem man sich einklinken kann, und Erweiterungen vornehmen kann. Davon mache ich Gebrauch, und ergänze einen “Hook” in der Phase “post-jar”.

In dieser Phase ist eigentlich das ausführbare JAR gebaut, und auch die nötigen Bibliotheken im “lib” Ordner als JAR Dateien verfügbar. Nun gilt es diese – einzeln – aufzuzählen, zusammen mit dem eigentlichen JAR Inhalt zusammenzupacken und anschließend noch die “Main-Class” anzugeben, damit das JAR weiterhin ausführbar ist.

Das könnte dann so aussehen (build.xml, am Ende der Datei)

<target name="-post-jar">
<jar jarfile="${dist.dir}/dist.jar">
<zipfileset src="${dist.jar}" excludes="META-INF/*" />
<zipfileset src="${dist.dir}/lib/notify.jar" excludes="META-INF/*" />
<manifest>
<attribute name="Main-Class" value="jotify.JNotify"/>
</manifest>
</jar>
</target>

In diesem Fall gibt es nur die “notify.jar” als externe Abhängigkeit zu ergänzen, die Main-Class wird wie gewohnt incl. Package angegeben. Über “jar jarfile=” kann man den endgültigen Namen des zusammengepackten JAR festelegen.

Artikel von: everflux.de

Netbeans: jar Erstellung mit abhängigen library jar Dateien

Ähnliche Beiträge:

1. Netbeans: Maven Source und JavaDoc
2. Netbeans: “package javax.servlet.jsp does not exist” (cannot find symbol)
3. OpenMPI – MPI-2 kompatible Library unter Ubuntu
4. Netbeans 6.5 Milestone 1 PHP, Groovy, Glassfish und mehr

Doch es gibt eine Sache, die mich unter Ubuntu in den absoluten Wahnsinn getrieben hat: Ich habe zwei Ubuntu Rechner, einen Server und meinen Arbeitsplatz. Auf dem Server läuft Apache und Mysql – auf meiner Arbeitsstation möchte ich keinen Apache laufen lassen, so dass ich alle Dateien auf den Server lade.

Das ist auch kein Problem, Netbeans hat vorgesorgt und kennt sich offenbar mit den typischen Setups aus. So kann man die PHP Sourcen mit einerm anderen Ordner synchronisieren. (Per NFS habe ich so den Server lokal eingebunden.) Sogar per FTP oder SFTP lassen sich die Sourcen publizieren, um z.B. direkt auf dem “echten” Webserver arbeiten zu können. Ein echter Segen!

Doch das lokale Synchronisieren schlägt bei mir regelmäßig fehl. Es kommt die Meldung “Copy support failed. Continue?”. Und egal was man dann klickt “yes” oder “no” – vom “copy support” oder Synchronisierung merkt man nicht mehr viel. Selbst, wenn die Fehlermeldung nicht erscheint, werden Dateien bei der Synchronisierung “vergessen”, oder nach einer Änderung lediglich gelöscht aber nicht neu einkopiert. Damit wird die Entwicklung mit Netbeans vom Traum zu einem echten Alptraum. (Manche mögen sagen, dies sei bei PHP der Normalfall, aber ich bin da unreligiös.)
Dies betrifft übrigens auch Windows Entwickler, die per SMB (Windows Netzwerk) ein ähnliches Setup verwenden, wie ich.

Doch es gibt Abhilfe! Denn Netbeans ist “nicht so ganz” Schuld an der Misere. Genau genommen ist es eine andere Komponente, die Versionsverwaltung. Diese macht etwas Magie und Hokuspokus und bringt damit einiges durcheinander – vor allem scheinbar wenn Netzwerkverbindungen zusätzliche Latenz einbringen. Konfiguriert man Netbeans so, dass es die Ordner bei der Versionsverwaltung ausschließt, sind die Probleme weg.

Dazu geht man in das Netbeans Installationsverzeichnis (bei mir ~/.netbeans/6.7/ ) und legt die Datei “config/Preferences/org/netbeans/modules/versioning.properties” an. Dort kann man die Pfade aufführen, die bei der Versionsverwaltung komplett ignoriert werden sollen. (Da dort ja sowieso die Sourcen nur hinkopiert werden, macht das in so fern auch Sinn.) In meinem Fall also einfach “/remote” eingetragen, Netbeans neu gestartet – und gut.

Artikel von: everflux.de

Netbeans: Copy support failed. Continue?

Ähnliche Beiträge:

1. Netbeans JavaScript Support, PHP und andere Features
2. Cisco 7960 “Semantic check failed for NTP packet”
3. Netbeans 6.5 released
4. Google Support – getestet und für gut befunden

Doch geht es ums “herumklicken” und Ausprobieren ist meiner Erfahrung nach der chromium-browser ungeschlagen schnell. (Vermutlich auch weil er bei mir absolut ohne Addons, Plugins und Erweiterungen läuft.) Der Browser ist unter Ubuntu/Linux zwar noch sehr beta, doch immerhin gibt es für Ubuntu ein PPA, so dass die Installation der Chromium Beta 3 kein Problem darstellt.

Die Installation des chromium Browsers (Entwicklerversion) geht am einfachsten über das PPA mit den folgenden Befehlen:

echo "deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu `lsb_release -cs` main" > /tmp/chromium.list
sudo mv /tmp/chromium.list /etc/apt/sources.list.d/
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 5A9BF3BB4E5E17B5
sudo apt-get update
sudo apt-get install chromium-browser

Auch sehr praktisch: Man kann den Browser so starten, dass er alle während der Tests erzeugten Daten in ein temporäres Verzeichnis legt und so keine großen Altlasten bleiben. Eine beispielhafte Konfiguration in Netbeans 6.7 mit Chromium als Browser sieht so aus:

Netbeans weist den Chromium Browser hier an sein Profil unterhalb von /tmp anzulegen. So muss man zwar einmalig “nichts importieren” und “nicht als Default Browser” anklicken, dafür bleibt jedoch auch wenig übrig, wenn die Entwicklung fertig ist. Zum Debugging (Ajax, JavaScript etc. pp) kann man natürlich dann auf den Firefox oder Tests zurückgreifen.

Damit soll übrigens nicht gesagt sein, dass Firefox insgesamt schlecht oder langsam wäre. Sicherlich wird die nächste Version von Firefox auch nochmal deutlich schneller werden, und zum täglichen Gebrauch werde ich ganz sicher (so bald) nicht zu Chromium wechseln. Für diesen speziellen Zweck macht sich Chromium bei mir jedoch sehr bezahlt. (In so fern mein “Dankeschön” an Google für die Entwicklung des Google Chrome Browsers, ohne den es auch kein Chromium gäbe.)

Artikel von: everflux.de

Chromium Browser: Schneller Entwickeln!

Ähnliche Beiträge:

1. Google Chrome: Extensions kommen für Chromium
2. Browser Speed – was ist drann an Chrome, V8 und Co?
3. Yahoo: Schneller Zugriff vs. Privacy
4. Browser Malware mit einem Klick entfernen…

Die Neuerungen sind vor allem “Cloud” (Kenai) Integration, bessere CI Integration (Hudson z.B.) und Integration mit Issuetrackern. (Bei einem Commit können dann direkt Issues geschlossen werden.) Aber auch die Unterstützung für verschiedene Sprachen und Frameworks (PHP, Rails, Groovy, Grails, …) wurde stark verbessert. Details finden sich auf der Übersichtsseite zum Netbeans 6.7 Release und in den Release Notes zu Netbeans 6.7, wer Netbeans noch garnicht kennt kann einen Blick auf die Features werfen.

Und meine Liebslingsneuerung: Dateien können nun inklsusive Dateiendung umbenannt werden….

Artikel von: everflux.de

Netbeans 6.7 release

Ähnliche Beiträge:

1. OpenSolaris Release 2008.11 – Jericho
2. GWT 1.5 release!
3. Oracle veröffentlicht Netbeans 6.9
4. Netbeans 6.5 kommt: RC1

Auch dem Pavillion habe ich dieses Jahr deutlich mehr Zeit als im letzten eingeräumt, und so eine Menge interessanter Gespräche geführt. Starkes Augenmerk habe ich auf Tipps und Erfahrungsberichte zum Thema User-Group-Building gerichtet, doch auch OpenSolaris und VirtualBox bekamen verdiente Aufmerksamkeit. Java selbst war in so fern weniger in meinem Fokus als das “drumherum”. Auch die Neuerungen die Sun für den “Sun certified Java Programmer plus” einführen möchte, konnte ich eingehend anschauen. Hierzu kann ich nur sagen: Klasse Idee, ich bin gespannt wie die Umsetzung wird.

Dass sich auch ein Talk der CommunityOne mit “Ubuntu in the clouds” beschäftigte, in dem Ubuntu One und die weitere Strategie von Canonical für Ubuntu und Cloudcomputing erörtert wurde fand ich sehr angenehm. Das zeigt, dass Sun sich hier wirklich offen gibt. (Hier könnte sich der OpenSolaris Produktmanager auch noch abgucken OpenSolaris security updates zur freien Verfügung zu stellen, und schon könnte OpenSolaris eine interessante Alternative zu Ubuntu auch für den tatsächlichen Einsatz werden.)

Schade, dass es Netbeans nicht zur JavaOne mit einem 6.7 Release geschafft hat – aber lieber einen RC als einen Flickenteppich.

Für alle an den Sessions interessierten: Die JavaOne 2009 Slides sind bei Sun online einsehbar, die aufgezeichneten Sessions folgen vermutlich in Kürze.

Wer Lust hat, beim die Münsteraner Java User Group beim Java Stammtisch zu besuchen sei hiermit herzlich dazu eingeladen.

Artikel von: everflux.de

JavaOne 2009

Ähnliche Beiträge:

1. Norovirus @ JavaOne 2008
2. OpenSolaris 2010.03 kommt…
3. Apple: Geldsklaven kaufen WWDC Videos
4. OpenSolaris Release 2008.11 – Jericho

Insbesondere die Kombination von jUnit Tests und verschiedenen Logleveln bzw. Loghandlern kann das Leben eines Entwicklers drastisch vereinfachen und oft auch einen Debugger überflüssig machen.Zum Verständnis eine kurze Einführung in das Java Logging API. (Weitere Infos in der offiziellen Dokumentation zu Java Logging und der Java Logging Overview) Es gibt Produzenten von Logdaten, Formatter, die die Nachrichten formatieren und Konsumenten (Handler), die die Lognachrichten dann verarbeiten.

Sowohl bei der Generierung von Lognachrichten als auch beim Konsumieren (dem Loghandler) kann man ein Loglevel angeben. Alle Nachrichten, die ein niedrigeres Loglevel haben, werden ausgefiltert. Für Handler kann man Formatter definieren, um die Logdaten in ein genehmes Format zu konvertieren. (XML, eigenes plain-text, …). Für eine bessere Übersicht und Details zu der Hierarchie sei auf die offizielle Dokumentation verwiesen.Die Standardkonfiguration von Java Logging definiert einen ConsoleHandler und Level INFO. (Im Installationsverzeichnis der Java JRE kann man in der Datei logging.properties auch die Konfiguration einsehen oder zentral ändern.)

Möchte man dies lokal ändern, so kann dies programmatisch erfolgen, doch komfortabler macht man dies über eine Konfigurationsdatei die man der JVM beim Starten mitgeben kann. So lassen sich auch für einzelne Programmstarts – oder Testläufe – eigene Konfigurationen aktivieren.

Die Konfigurationsdatei für das java.util.logging Framework wird in einem normalen “Properties” Format abgelegt. Dort können Handler, Formatter und Loglevel definiert werden. Praktisch: Pro Package oder sogar für einzelne Klassen kann das Loglevel geändert werden.
Die Datei wird dann per JVM Argument (System Parameter) spezifiziert:

-Djava.util.logging.config.file=logging.properties

Eine beispielhafte Anwendung kann dann so aussehen, dass ich in dem Package “de.everflux.foo” eine zu testende Klasse habe, und einen jUnit Test habe, der diese Klasse aufruf. So kann ich dann mittels

handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = ALL
de.everflux.foo.level = FINEST
.level = INFO

Das Loglevel für die generierten Nachrichten in dem Package “de.everflux.foo” auf FINEST stellen, während für alle anderen (bzw. das Wurfel Package) das Level INFO konfiguriert wird.

Als Handler wurde lediglich der ConsoleHandler definiert, und dieser so eingestellt, dass alle Meldungen ausgegeben werden sollen, also hier keine Filterung mehr stattfindet.

In Netbeans, bzw. auch in Eclipse, kann ich dann über die “Project / Run Configuration” oder “Launch Configuration” entsprechende Parameter setzen. So ist dann für einzelne Testläufe schnell das Loglevel angepaßt. Berücksichtigt man schon beim Schreiben von Tests und Klassen, dass man ruhig Debugging-Ausgabe per FINER oder FINEST Loglevel Informationen loggen kann, dann ist das spätere Debugging einfacher.

Auch in Produktion – eben das Loglevel erhöhen und sich (hoffentlich hilfreiche) Daten zusenden zu lassen ist allemal einfacher, als dem Endanwender zu erklären wie man einen Debugger startet.

Artikel von: everflux.de

Java logging: Netbeans, Eclipse und java.util.logging im Einsatz

Ähnliche Beiträge:

1. Java (JVM) und Eclipse Abstürze mit Ubuntu Hardy Heron
2. Eclipse RCP/SWT Fehler java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk
3. Ubuntu Oneiric: Netbeans Master-Passwort / Keyring Integration
4. PHP Entwicklung: Firebug logging mit PHP

Openfire ist ja schnell eingerichtet, jedoch hatte ich das Problem, stets die Meldung zu bekommen: “object does not represent a valid jid”Leider ist im aktuellen Netbeans Collaboration Plugin auch die Möglichkeit, sich an einem Jabber Server zu registrieren entfernt worden.

Folgende Schritte haben bei mir geholfen, das Problem mit dem “object does not represent a valid jid” zu lösen:

1. Zum User gehörige JID mit Benutzernamen und E-Mail Adresse versehen
2. Den Openfire Cache leeren bzw. Openfire neu starten

Außerdem sollte man darauf achten, dass die zugehörigen Domains (DNS) korrekt auflösen. ( search.$HOST, pubsub.$HOST und auch der groupchat etc.)

Jedoch besteht bei mir weiterhin das Problem, dass ich NPE Exceptions in Netbeans bekomme – ein Problem, dass offenbar schon lange bekannt ist. Doch auch ein Haufen Fehlermeldungen im Openfire lassen mich daran zweifeln, dass es wirklich am Netbeans liegt, sondern eher am Openfire. (Oder der Konfiguration.)

Dazu gesellen sich SQL Integrity Exceptions von Openfire, die sowohl bei der integrierten HSQLDB als auch MySQL auftauchen:

[org.jivesoftware.openfire.spi.PresenceManagerImpl.userUnavailable(PresenceManagerImpl.java:271)] Error storing offline presence of user: olli
com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException: Duplicate entry 'olli' for key 1
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2985)

Vermutlich hängt es also an der Kombination aus Netbeans Collaboration und einem Problem von Openfire und dem MUC Chat. Das Problem ist auch seit 2006 bei IgniteRealtime im Issuetracker unter JM-921, doch ein Fix ist nicht in Sicht. (Interessanterweise ist auch hier im Report zu lesen, dass es durch Netbeans ausgelöst wird.)

Ich habe es somit leider nicht fertig gebracht, eine funktionierende Installation von Openfire und Netbeans zusammenzustellen.

Update: Dank der netten Hilfe von einem XMPP und Openfire Experten ist die Situation nun etwas besser analysiert. Erstmal: Niemals den Openfire Cache leeren. Danach sind die Dienste nicht mehr richtig announced und es passieren wunderliche Dinge. Aber: Der Login mit dem Netbeans Collaboration Plugin tut danach tatsächlich.
Das liegt daran, dass eben kein Groupchat mehr vom Openfire announced wird  – findet Netbeans nämlich einen, wird eine extrem merkwürdige XMPP Anfrage gesendet, auf die der Openfire (verständlicherweise) auch etwas reserviert antwortet.

Anschließend beendet Netbeans die Verbindung und meldet “object does not represent a valid jid” Wenn ich etwas Zeit habe, werde ich mal schauen was da im Quellcode vermerkt ist, vielleicht ist das ja einfach zu beheben. Schade, dass Sun nicht die Smack XMPP Library verwendet, sondern etwas eigenes. (Ich nehme an, dass es zu den Zeiten als Netbeans Collaboration gestartet wurde, noch keine ausgereiften Java XMPP Libraries gab.)

Artikel von: everflux.de

Netbeans Collaboration mit Openfire

Ähnliche Beiträge:

1. Openfire 3.6.1 fixt Sicherheitslücke
2. Netbeans 6.5 released
3. Oracle veröffentlicht Netbeans 6.9
4. Netbeans 6.7 release

Beispielsweise: hsperfdata_johndoe, wenn der Benuter “johndoe” die zugehören Java Prozesse gestartet hat. In dem Ordner befinden sich dann Dateien mit 16kb oder 32kb Größe, der Dateiname besteht aus einer Nummer. Die Nummer ist die Prozess-ID (PID) des zugehörigen Java Prozesses. Die Datei selber besteht scheinbar nur aus unlesbaren binärdaten gemischt mit ein paar Strings.

Diese hsperfdata Dateien sind in Wahrheit Auszüge aus der JVM die z.B. für Laufzeitanalyse und Prozessmanagement genutzt werden. (s. auch das zugehöre FAQ von Sun.) Lädt man sich das separate jvmstat Paket herunter, so bekommt nan auch den visualgc, ein experimentelles Tool zur visuellen Analyse des Garbage Collectors. VisualGC ist auch als Netbeans Modul verfügbar, s. Screenshot.

Eigentlich sollten die hsperf Ordner automatisch gelöscht werden, wenn der zugehörige JVM Prozess beendet wird, jedoch kann dies bei einem System-Crash schonmal ausbleiben. In diesem Fall kann man bei Bedarf den Ordner von hand löschen – da die Dateien jedoch sehr klein sind und zudem in einem temporären Verzeichnis angelegt werden, kann man diese getrost rumliegen lassen.

Möchte man das Feature komplett deaktivieren, so kann man bei den Java Optionen auf der Kommandozeile zusätzlich angeben:

-XX:-UsePerfData

Dann werden die Ordner nicht angelegt, jedoch stehen die Analysefunktionen auch nicht zur Verfügung. Auf der anderen Seite ist die VisualVM als neueres Tool ebenfalls verfügbar und ermöglicht fast die gleichen Einblicke in die Java Virtual Machine. (Etwas geringere Detaillierung der einzelnen Spaces, jedoch meist reicht ein Blick auf den Classloader und PermGen um Memory Leaks zu finden.)

Artikel von: everflux.de

hsperfdata und VisualGC

Ähnliche Beiträge:

1. Babylon: Eclipse Projekt mit verschiedenen Projekt-Typen
2. Netbeans: jar Erstellung mit abhängigen library jar Dateien
3. Ubuntu: Papierkorb leeren – Dateien von Hand löschen
4. Netbeans 6.5 kommt: RC1

Ein häufiges Szenario bei der Arbeit mit (fremden) Quelltext ist, dass man diesen Überarbeitet, und Zeilen löscht. Stellt sich im Nachhinein raus, dass es vielleicht keine so gute Idee war, hilft in Eclipse die “Compare with local history” oder im Notfall ein SVN diff.

Netbeans hält ebenfalls eine “Diff” Ansicht und eine “local History” bereit, doch gelöschte Zeilen können schneller und einfacher wiederhergestellt werden: Ein Klick auf den rot markierten Bereich, der eine Löschung anzeigt, und schon kann der betreffende Bereich wieder eingefügt werden.

Artikel von: everflux.de

Netbeans Features: Edit Review

Ähnliche Beiträge:

1. Netbeans JavaScript Support, PHP und andere Features
2. Netbeans 6.5 released
3. Netbeans: Klassen zum Interface finden
4. Netbeans 6.5 Milestone 1 PHP, Groovy, Glassfish und mehr