Ich verwende Glassfish schon seit geraumer Zeit um mittels “Continuous Deployment” für aktuell entwickelte Anwendungen eine separate Umgebung zu haben, in der ich und Kollegen testen können. Das ganze funktioniert mittels eine CI-Servers (Hudson Jenkins in diesem Fall), Maven und einem Deploy Plugin.

Auch mit Glassfish 3.1 funktionierte das Deployment prima – also hier war kein Update von Jenkins oder dem Deploy Plugin erforderlich. Auch die Anwendung startete – jedoch funktionierte nichts. Exceptions über ungültige Sessions gab es, auch Log-Einträge vom hier für Ajax eingesetzten DWR (Direct Web Remoting)

2011-02-28 18:57:13,037 [http-thread-pool-8090(2)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack.
2011-02-28 19:03:02,105 [http-thread-pool-8090(5)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack.

Dank Firebug etwas schlauem Rumraten und Probieren fand ich dann heraus: Glassfish 3.1 setzt Session Cookies per Default auf “HTTP Only”. Dazu gibt es bereits ein Ticket im Glassfish Tracker: GLASSFISH-15730

Es gibt nun mehrere Möglichkeiten für die nötige Kompatibilität mit Bestandsanwendungen zu sorgen:

Wird man die Anwendung zukünftig immer in einem Servlet 3.0 kompatiblen Container deployen, so kann man in der web.xml das Verhalten umkonfigurieren:

<web-app>
  <session-config>
    <cookie-config>
      <http-only>true</http-only>
    </cookie-config>
  </session-config>
</web-app>

Alternativ kann man bei DWR den CSRF Check deaktivieren, wovon ich jedoch abraten würde:

<servlet>
  <servlet-name>dwr-invoker</servlet-name>
  <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
  <init-param>
    <param-name>crossDomainSessionSecurity</param-name>
    <param-value>false</param-value>
  </init-param>
</servlet>

Die letzte Möglichkeit ist – in diesem Fall – auf DWR 3 umzustellen, hier wurde das Problem grundsätzlich gelöst, so dass nicht mehr per JavaScript auf den Session Cookie zugegriffen werden muss. (Siehe DWR-26) Leider gibt es von DWR 3 bisher noch kein Release, sondern lediglich vorab-Versionen.

Das Problem tritt übrigens auch mit Tomcat 7 auf, und nicht nur mit Glassfish 3.1 – ich frage mich, ob dies Verhalten am Ende sogar in der Servlet 3 Spezifikation vorgegeben ist.
Natürlich betrifft dies nicht ausschließlich DWR, sondern auch andere Anwendungen, die per JavaScript auf den Session Cookie zugreifen wollen/müssen.

Artikel von: everflux.de

Glassfish 3.1: Probleme mit DWR 2 (und mehr)

Ähnliche Beiträge:

1. Glassfish 3.1 und httpOnly Session Cookie
2. Netbeans 6.5 Milestone 1 PHP, Groovy, Glassfish und mehr
3. GlassFish v3 Prelude: Der neue Glassfish ist da
4. Glassfish remote Monitoring mit VisualVM auf Ubuntu

<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.2.1.v20101111</version>
<configuration>
  <webAppConfig>
    <sessionHandler implementation="org.eclipse.jetty.server.session.SessionHandler">
      <sessionManager implementation="org.eclipse.jetty.server.session.HashSessionManager">
      <storeDirectory>${basedir}/target/sessions/</storeDirectory>
    </sessionManager>
  </sessionHandler>
<contextPath>/${project.artifactId}</contextPath>
</webAppConfig>
<!--
<reload>automatic</reload>
<scanIntervalSeconds>2</scanIntervalSeconds>
<scanTargets>
<scanTarget>target/classes/</scanTarget>
</scanTargets>-->
</configuration>
</plugin>

Mit dieser Einstellung werden die Session Daten in dem Order “target/sessions” persistiert, und man kann bei einem Neustart dort weitermachen, wo man aufgehört hat.

Artikel von: everflux.de

Maven, Jetty und Reloads: Session persistieren

Ähnliche Beiträge:

1. Maven, Jetty und der ExtraClasspath
2. Jetty org.eclipse.jetty.io.EofException / Connection closed
3. Glassfish 3.1 und httpOnly Session Cookie
4. Maven Properties werden falsch gefiltert?

1. Das Default Servlet ersetzen, dazu wird auf den Root Pfad “/” in der web.xml ein Mapping angelegt:
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
2. Ab Servlet Spezifikation kann auch ein Servlet in der welcome-file-list in der web.xml gemappt werden:
   <welcome-file-list>
<welcome-file>myServlet</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Im folgenden beschreibe ich die Vor- und Nachteile der verschiedenen Ansätze, und welche Erfahrungen ich mit verschiedenen Web Containern dabei gemacht habe.Das Default Servlet wird in der Regel zur Auslieferung von statischen Ressourcen (z.B. Bilder, CSS Dateien) und dem Directory Listing verwendet. Ersetzt man das Default Servlet des Web Containers nun durch ein eigenes, muss man sich ggf. selber um die zusätzlichen Aufgaben kümmern, oder die statischen Inhalte über einen anderen Pfad ausliefern, z.B. “static” und diesen auf das Default Servlet mappen:

<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/static/*</url-pattern>
</servlet-mapping>

Da inzwischen wirklich überall Servlet 2.4 konforme Webcontainer im Einsatz sein dürften, ist der Web über ein Servlet als Welcome-File praktischer: Das vom Container bereitgestellte Default Servlet kommt weiterhin für die restlichen Ressourcen zum Einsatz, an der Struktur des Projektes muss nichts geändert werden. Die zugehörige Konfiguration in der web.xml für ein Spring Dispatcher Servlet könnte z.B. so aussehen:

<servlet>
<description>Spring Dispatcher Servlet</description>
<servlet-name>myServlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>

<welcome-file-list>
<welcome-file>myServlet</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Das funktioniert soweit in Tomcat und Glassfish auch – allerdings nicht in Jetty. Und Jetty verwende ich sehr gerne zum lokalen Testen, z.B. über das Jetty Maven Plugin. Zu dem Fehler von Jetty gibt es auch einen Bug in der Jetty Bug Datenbank (936), offenbar sind die Jetty Entwickler der Auffassung, dass die Spezifikation in diesem Punkt “stupid” sei, man weigert sich da auch in dem Codehaus Jetty 6.1.x das Defaultverhalten der Spezifikation gemäss anzupassen.
Um das Verhalten zu korrigieren, muss man das Jetty Default Servlet anders konfigurieren – damit bekommt das Projekt eine Jetty Abhängigkeit, die in meinen Augen nicht gewünscht ist, vor allem nicht, wenn Jetty lediglich zur Entwicklung eingesetzt wird.

Jetty ist nun zu Eclipse umgezogen und mit Jetty 7 ändert sich das Problem ein wenig: Jetty 7 akzeptiert nun im Default auch Servlets für ein Welcome-File-Mapping – jedoch findet vorher noch eine Prüfung statt, ob die Datei existiert. Existiert sie nicht, wird ein 404 HTTP Fehler erzeugt. Natürlich kann man dies über Konfiguration des Default Servlets ändern – aber dann hat man wieder die Jetty Abhängigkeit im Projekt. Hier hilft ein kleiner Trick: Man legt einfach eine leere Datei, z.B. index.html, an, gibt diese (zusätzlich) in der Welcome-File-List an, und mappt diesen Pfad auch noch auf das entsprechende Servlet. Diese Lösung funktioniert mit allen von mir getesteten Containern. Also kommt zusätzlich in die web.xml:

<!-- for stupid jetty -->
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/index.html</url-pattern>
</servlet-mapping>

Für das Maven Plugin von Jetty 7 hat sich der Artefakt Name geändert, und auch der Default Context ist “/” statt des Artefakt Namens – so sieht der Eintrag im POM daher aus:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <version>7.2.1.v20101111</version>
    <configuration>
      <webAppConfig>
        <contextPath>/${artifactId}</contextPath>
      </webAppConfig>
    </configuration>
</plugin>

Nun noch die Konfiguration für Spring 3 Controller, die auf den Root Path gemappt werden sollen. Ich verwende hier die Spring Annotationen für @Controller und @RequestMapping. Das Problem hier: Jetty ruft “natürlich” die “index.html” auf – auch hierfür muss der Controller dann ein Mapping haben. Die Lösung dafür ist ein Pattern zu verwenden, was Spring erlaubt:

@Controller
public class SampleController
{
   @RequestMapping(value = "*", method = RequestMethod.GET)
   public ModelAndView rootPathHandler()
   {
       //...
       return new ModelAndView("sample");
   }
}

Artikel von: everflux.de

Java Servlet (Spring Controller) auf Root Path mappen

Ähnliche Beiträge:

1. Netbeans: “package javax.servlet.jsp does not exist” (cannot find symbol)
2. web.xml Tag Reihenfolge: Relevant!
3. Heuschrecken @ SpringSource: Spring Framework lock-in
4. PHP FastCGI Path Bug (Ubuntu Hardy)

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

Also einfach darauf achten: Erst kommt der Servlet/Filter Name und dann die Zuordnung auf ein URL-Pattern bzw. bei Filtern auch auf einen Servlet Namen, wie im folgenden Beispiel:

<servlet-mapping>
<servlet-name>admin</servlet-name>
<url-pattern>/admin/*</url-pattern>
</servlet-mapping>

<filter-mapping>
<filter-name>cacheFilter</filter-name>
<servlet-name>print</servlet-name>
</filter-mapping>

Ab Servlet Spec 2.5 darf man übrigens auch mehrere Mappings auf einmal angeben – falls man noch mit der web.xml und nicht mit Annotationen arbeitet spart es Tipparbeit und ist übersichtlicher.

Artikel von: everflux.de

web.xml Tag Reihenfolge: Relevant!

Ähnliche Beiträge:

1. Ubuntu: Reihenfolge der Netzwerkkarten
2. Java Servlet (Spring Controller) auf Root Path mappen
3. Glassfish 3.1: Probleme mit DWR 2 (und mehr)
4. Netbeans: “package javax.servlet.jsp does not exist” (cannot find symbol)

Die Konfiguration dafür ist einfach:

<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>*.properties</include>
</includes>
</resource>
</resources>

Schon kann man z.B. in der version.properties dann revision = ${buildNumber} eintragen, und erhält nach jedem Build die inkrementierte Build-Nummer. (Vom Maven Buildnumber Plugin)

Nur funktionierte es plötzlich nicht mehr. Genauer gesagt, es funktionierte nicht mehr bei allen Dateien. Die Ursache (nach langem Suchen): Das Zeichen “@” ist als neuer Delimiter hinzugefügt worden. Enthielt jetzt eine der zu filternden Dateien ein “@” eben als solches, und nicht als Teil eines Patterns, wurde das Filtern abgebrochen. Eine Fehlermeldung oder Warnung habe ich nicht gesehen – mag aber sein, dass Maven die irgendwo mal ausgespruckt hat.

Abhilfe schafft hier die folgende explizite Konfiguration des Maven Resource Plugin:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<useDefaultDelimiters>false</useDefaultDelimiters>
<delimiters>
<delimiter>${*}</delimiter>
</delimiters>
</configuration>
</plugin>

Damit wird das das alte Verhalten des Plugins wieder hergestellt, und “@” Zeichen als Trennzeichen für Ersetzungen ignoriert.

Vielleicht gibt es auch mal einen offiziellen Code fix – Maven Bug: http://jira.codehaus.org/browse/MRESOURCES-117

Artikel von: everflux.de

Maven Properties werden falsch gefiltert?

Ähnliche Beiträge:

1. Maven, Jetty und der ExtraClasspath
2. Maven, Jetty und Reloads: Session persistieren
3. Hudson + Maven: java.net.SocketTimeoutException: Accept timed out
4. GridGain und Maven

Dabei spielt es keine Rolle, ob es um Entwickler geht, die Firebug mit den dafür ebenfalls verfügbaren diversen Erweiterungen nutzen, oder den Gelegenheitssurfer der dank Adblock-Plus schneller und weniger genervt das Internet konsumieren kann. Für andere Nischen und spezielle Bedürfnisse gibt es ebenso viele Plugins von “Spass” bis “Produktivität” ist alles vertreten.

Jedoch wuchs der Neid bei mir wenn ich auf Chrome / Chromium blickte – ich wollte Firefox auch etwas schneller haben. Bekannt für Nachteile bei der Performance sind eben gerade jene Erweiterungen, die einem das Leben so schön erleichtern. Also habe ich einige deaktiviert, es wurde in der tat etwas schneller. Damit war das erledigt. Erfolg!

Bis mir auffiel, dass irgendetwas nicht stimmte. Bei Downloads verschlang Firefox immense Mengen an Speicher – ein Vielfaches dessen, was die Datei selber haben würde. Und auch die CPU Belastung, vor allem bei Downloads, wuchs dramatisch.

Erst hatte ich das Flashplugin in Verdacht – in der Regel trifft man damit den Richtigen, genauso wie pauschal auf Windows schimpfen. Aber daran lag es nicht, ich hatte extra keine Flash Seiten aufgemacht.

Erst als ich alle von Firebug abhaengigen Erweiterungen (und nicht nur Firebug selber) deaktiviert hatte, sowie TamperData und LiveHttpHeaders war endlich alles wie es sein sollte. Firefox brauchte weder Unmengen an Memory noch ging die CPU Last bei Downloads in die Höhe. Welches Plugin tatsächlich verantwortlich war, habe ich nicht mehr untersucht. Vermutlich ist es nicht gut, wenn man Plugins, die Firebug benötigen, aktiviert lässt, aber Firebug selber deaktiviert.

Um mir Arbeit zu sparen (wer moechte schon immer alle Erweiterungen ein- und ausschalten) habe ich mir mittels eine zweiten Firefox Profils das Leben leichter gemacht: Es gibt jetzt ein “dev” Profil für Entwicklung, da ist dann alles aktiviert, dass sich der Web-Entwickler wünscht. Daneben sind auch deutlich weniger, bzw. andere Bookmarks gesetzt: “Führe mich nicht in Versuchung”.

Um den Entwicklungs-Firefox zu starten, habe ich mir eine zusaetzliche Verknuepfung (mit Werkzeug-Symbol) in der Ubuntu Linux Taskbar angelegt, diese ruft folgendes Kommando auf:
firefox -no-remote -P dev

Mittels “-P” kann man das Profil auswählen, welches verwendet werden soll, das “-no-remote” verhindert, dass bei einer bereits gestarteten Firefox Instanz (z.B. des default Profils) lediglich ein neues Fenster aufgemacht wird.

Probiert es mal aus – Kommentare und Feedback erwünscht!

Artikel von: everflux.de

Firefox langsam und braucht viel Speicher?

Ähnliche Beiträge:

1. Google: Langsam, langsamer, toooo slow
2. Firefox 4 als Ubuntu Paket installieren
3. Firefox 3.1 in Ubuntu
4. Speicher Depot (techimport) Spam: So kann man sich wehren!

Piwik ist übrigens eine interessante Alternative zu Google Analytics, es handelt sich um eine kostenlose OpenSource Software, die mittels JavaScript, PHP und MySQL Webseitenstatistiken erzeugt. Bei großen Projekten wird die Last auf der Datenbank allerdings deutlich spürbar – vielleicht ist eine relationale Datenbank für Webanalyse eben nicht so gut, wie BigTable (Google) oder andere NoSQL Systeme. Im Gegensatz zu Google Analytics liefert Piwik jedoch auch eine Backlink, Pagerank und Alexa Analyse direkt dazu.

Artikel von: everflux.de

Yahoo 1337 – Leet Backlinks

Ähnliche Beiträge:

1. Yahoo und Hadoop
2. Slurp 3.0 – Yahoo hat neuen Crawler
3. Yahoo steigt bei OpenID ein
4. Yahoo: Schneller Zugriff vs. Privacy

Die Vermutung lag nahe, dass entweder der Dump (mittels mysqldump erzeugt) defekt war, oder falsch importiert wurde. (Der Import wurde über den mysql Kommandozeilen Client gemacht, MySQL lag auf beiden Systemen in der Ubuntu Lucid Version 5.1.41 vor.). Das Thema MySQL, Encoding, Collation und Charset kann sich dabei als sehr verwirrend herausstellen.So sahen die Daten im phpmyadmin auf dem neuen Ubuntu Server aus:

Auf dem ursprünglichen Server standen hier lesbare Text. (Erst später sollte ich feststellen dass zwar die MySQL Datenbank auf beiden Systemen gleich war – nicht jedoch PHPMyAdmin: Auf dem ursprünglichen Server handelte es sich um ein PHPMyAdmin von der Projektseite, auf dem neuen Ubuntu System stammte sie aus dem Ubuntu Repository.)

Einen guten Überblick über Probleme mit Encodings im Zusammenhang mit MySQL gibt es hier: http://forge.mysql.com/wiki/How_to_Use_Charsets_and_Collations_Properly

Nun zur Lösung des Problems: Die Daten waren korrekt in der Datenbank, wie man sich mittels dem mysql client auch ansehen kann. Lediglich PHPMyAdmin stellte die Daten anders dar: Hex kodiert. Der Grund war, dass die Collation der Felder auf “utf8_bin” gesetzt war, und das Ubuntu PHPMyAdmin offenbar standardmäßig die Option “Show binary content as HEX” gesetzt hat. Typischer Fall von Verkettung unglücklicher Umstände.
Aendert man die Darstellungsoptionen oder setzt die (korrekte) Collation “utf_general_ci” werden die Daten auch von PHPMyAdmin korrekt angezeigt.

Dies zeigt, wie wichtig es ist, die Collation korrekt zu setzen – und dies natuerlich passend zur Konfiguration der jeweiligen Anwendung, die mit den Daten arbeitet.

Artikel von: everflux.de

Mysql und phpmyadmin: Daten encoded und falsch angezeigt?

Ähnliche Beiträge:

1. phpMyAdmin: blowfish_secret Fehler nach Update
2. Ubuntu: mysql und InnoDB nach Neuinstallation
3. Microsoft Access (mdb) konvertieren: ODB und MySQL unter Ubuntu
4. Sun kauft MySQL: Eine Milliarde Dollar

Hier der Ausschnitt aus der Webseite:

Selbst der Versuch SpringSource zu kontaktieren scheiterte an Google Analytics! Lediglich der Bereich “America Sales” der Kontaktseite konnte aufgerufen werden:

Für das Umschalten zwischen den verschiedenen Tabs wurde jeweils wieder ein JavaScript Aufruf an Google Analytics durchgeführt – und schlägt dieser fehl, funktioniert das eben nicht.

Wie kann man es nun besser machen? Eine Webseite sollte auch dann funktionieren, wenn kein JavaScript aktiviert ist. (Ok, da kann man je nach Zielpublikum noch drueber reden.)

In jedem Fall sollte aber eine Webseite nicht den Dienst quittieren, wenn eine JavaScript Bibliothek oder ein Statistiksystem (temporär)  nicht zur Verfügung steht. Defensives Programmieren sollte gerade bei Adservern und Analyticsoftware zum Einsatz kommen, denn immer mehr Benutzer legen großen Wert auf die Privatsphäre.

Eine Abfrage, ob das benutzte JavaScript Objekt existiert, hätte das gesamte Problem vermutlich vermieden.

Artikel von: everflux.de

SpringSource/Vmware: FAIL dank Google Analytics

Ähnliche Beiträge:

1. Gatineau – Microsoft reagiert auf Google Analytics
2. FedEx: Fail
3. Google: Tote gibts bei ebay (fail)
4. Fileupload für Bilder mit jQuery – dank Ajax mit Vorschaufunktion

Möchte man den Inhalt von HTML Elementen  nutzen, so nutzt man einfach die jQuery Filter, die auch auf HTML content zugreifen können.

Beispiel:

jQuery("tr>td:contains(Prem)").addClass("highlight");

Hier wird nun auf Tabellenzellen, die “Prem” als Inhalt haben, die CSS Klasse “highlight” angewendet.
Ein vollständiges Beispiel incl. CSS:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Content color</title>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<style type="text/css">
.highlight { color: red; }
</style>
</head>

<h1>Beispiel f&uuml;r jQuery</h1>
<table>
<tr>
<td width=40>Prem</td>
</td></tr></table>
</body>
</html>


Artikel von: everflux.de

jQuery: HTML Inhalt einfärben

Ähnliche Beiträge:

1. Fileupload für Bilder mit jQuery – dank Ajax mit Vorschaufunktion
2. Ajax File upload mit jQuery – ohne DWR
3. Netbeans 7.1, JSLint und jQuery: $ used before defined
4. JavaScript Error mit Google Admanager und adblock vermeiden

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…

In meinem Fall quittierte Webtest die Arbeit mit der hilfreichen Meldung
com.gargoylesoftware.htmlunit.ScriptException: Wrapped java.lang.NullPointerException
Der Grund für die NullPointerException im Webtest war dann auch (relativ) schnell identifiziert:
In der zu testenden Anwendung war ein wenig JavaScript eingebaut, genau genommen in einem Formularfeld, dass ich per Webtest ausfülle. Dabei wird per JavaScript der Blur Event abgefangen und dann “this.blur()” augerufen:
<input type="text" name="mail" onblur="this.blur();" size="25" />

Mir ist der Sinn davon zwar schleierhaft – jedoch bringt es Webtest dazu die Arbeit zu verweigern. (Oder HTMLUnit, ich habe das nicht weiter analysiert.)

Eine Lösung wäre nun das JavaScript Fragment aus der zu testenden Anwendung zu entfernen – doch die wollte ich nicht ändern. Somit bleibt nur den standardmäßig aktivierten JavaScript Support in Webtest für diesen Step zu deaktivieren. (Zum Glück handelt es sich um eine Web 0.9 Anwendung die kein JavaScript benötigt.)

Dafür bietet Webtest einen  “Extension Step” an: enableJavaScript. Damit könnte die Konfiguration so aussehen:


<webtest name="test without javascript">
<!-- import global config -->
&hostConfig;
<steps>
<!-- crashes with javascript -->
<enableJavaScript description="Disable javascript to avoid bugs" enable="false"/>

Wenn ich den Fehler genauer eingrenzen kann, wäre eine Fehlermeldung an Webtest oder HTTPUnit wohl angebracht.

Artikel von: everflux.de

Canoo Webtest: NullPointerException durch JavaScript

Ähnliche Beiträge:

1. Canoo Webtest: GUI monitor deaktivieren
2. Netbeans JavaScript Support, PHP und andere Features
3. JavaScript Error mit Google Admanager und adblock vermeiden
4. Zend Framework und PHP: Beschleunigung durch Caching

Die Dokumentation von Webtest läßt jedoch trotz der zeitlichen Reife des Projektes an einigen Stellen zu wünschen übrig. Hier kann ein Blick in “webtest.xml” sowie in “resources/build/WebTestReport.reference.xml” im Installationsverzeichnis von Webtest etwas inspirieren.In meinem konkreten Fall wollte ich den Webtest Monitor (ein kleines Groovy Fenster) deaktivieren. (Sobald das Fenster aufgeht schnappt es sich den Fokus und stört damit meinen Arbeitsablauf.)

Die Lösung dafür war – anders als erwartet – nicht eine XML <option>, sondern eine Änderung in der buil.xml in der ich ein ant Property setzen mußte um den Webtest Groovy Monitor zu deaktivieren:

<property name="wt.webtestMonitor.skip" value="skip" description="WebTestMonitor should not be started"/>

Damit kann jetzt nach Herzenslust getestet werden – und parallel weiter gechattet gearbeitet werden.

Artikel von: everflux.de

Canoo Webtest: GUI monitor deaktivieren

Ähnliche Beiträge:

1. Canoo Webtest: NullPointerException durch JavaScript
2. SpringSource kauft ein: Groovy und Grails G2One

JavaFX soll eine neue Generation von Internet Anwendungen einläuten, Desigern wie Entwicklern neue Möglichkeiten an die Hand geben. Und mit JavaFX mobile soll die Philosophie “write once, run everywhere” für mobile Anwendungen wahr(er) werden. JavaFX Mobile wird auf Blackberrys, Android und anderen Mobilgeräten laufen, solange zumindest JavaME vorhanden ist. (Die JavaFX Mobile runtime wird ggf. nachinstalliert) Auch wenn Nokia noch nicht offiziell im Boot ist, könnte ich mir eine entsprechende Ankündigung zur JavaOne gut vorstellen.

Doch was ist mit Java und dem iPhone von Apple? Auch der Apple ipod touch, der eine ähnliche Plattform wie das iPhone darstellt besitzt derzeit weder Flash noch Java Support. (Wenn man von einem Jailbreak Gerät absieht.)In meinen Augen besteht hier eine riesen Chance für Sun, Entwicklern eine wirklich attraktive Plattform an die Hand zu geben. Denn auch wenn Java auf dem iPhone derzeit nicht von Applet gestattet wird, ist der Anreiz immens: Der Umsatz der über den Apple Store mit dem iPhone erzielbar ist, ist immens. Außer dem Android Store (und vielleicht demnächst Nokia mit einem eigenen Süppchen) gibt es eine andere Lösung, die so einfach den Kauf und die Zahlungsabwicklung ermöglicht. Das mag ein Grund sein, weshalb iPhone Besitzer eher Anwendungen kaufen, als z.B. Symbian User.

Mich würde es daher nicht überraschen, wenn Sun zur JavaOne ein strategisches Abkommen mit Apple verkündet, dass Java Anwendungen zukünftig auf dem iPhone unterstützt werden. (Dabei mag es dann Einschränkungen geben, wie bei den nativen Cocoa iPhone Anwendungen auch, aber es wäre ein Anfang.)

Und auch wenn Apple nicht “mitspielt”, es gibt sicher noch weitere Möglichkeiten, einem JavaFX (mobile) Entwickler Werkzeuge an die Hand zu geben. Ich denke da z.B. an cross-compiler. Als Entwickler würde ich meine JavaFX mobile Anwendung entwickeln, und erhielte dann eine iPhone cocoa Anwendung zur Distribution. Klingt utopisch? Ein Indiz dafür könnte sein, dass Tor Norbeye, der für die Unterstützung zusätzlicher Sprachen an Netbeans gearbeitet hat, abgezogen und nun an einem (ganz geheimen) JavaFX Projekt arbeitet. Und so ist seit dem auch kein Blogeintrag bei Tor mehr zu lesen. Nachrichtensperre?

Dass sogar aus Java Bytecode eine Übersetzung zu Cocoa/iPhone Code möglich ist, zeigt Arno Puder in diesem Google Techtalk mit der xmlvm.

Gelingt Sun ein solcher Schachzug, wäre JavaFX die Plattform für mobile Geräte – und auch RIAs. Einmal dabei könnte dann noch zu Microsoft Silverlight mobile cross-compiliert werden. Ein Horror in der Wartung der Inkompatibilitäten – aber ein Segen für Entwickler, wenn alles tut. Zeit Sun Aktien zu kaufen?

Artikel von: everflux.de

Java/JavaFX -> iPhone + IpodTouch?

Ähnliche Beiträge:

1. Java auf den iPhone von Apple
2. Apple iPhone: “rger mit Akkulaufzeit
3. iPhone ohne Simlock
4. iPhone in Deutschland mit UMTS