git push versucht GIT alle lokalen Branches auf das Remote-Repository zu schieben. Diese Funktion lässt sich abschalten oder besser begrenzen. Mit
git config --global push.default currentschiebt GIT nur die Änderungen des aktuellen Branches auf das Remote-Repository. Ab GIT 2.0 wird diese Einstellung der Standard sein.
VT-x is disabled in the BIOS. (VERR_VMX_MSR_VMXON_DISABLED)Ein ähnliches Problem hatte ich vor einiger Zeit. Damals half es, die Benutzerrechte für die VMs neu zu setzen. Das hatte diesmal keine Wirkung. Im Netz bin ich auf die folgende Lösung gestossen: Zunächst muss die VBoxManage.exe im Dateipfad liegen. Ist das gegeben, kann man den folgenden Kommandozeilen Befehl ausführen:
VBoxManage list vmsDas liefert eine Liste aller registrierten VMs. Bei mir sieht das so aus:
"Oracle Developer Days" {de67fcab-5dce-4e21-bc4b-17e176dce2c3}
"ubuntu-laptop" {5c6e9005-4a1d-4163-833d-ede800a71f06}
"betoffice-server" {96319b3a-88b4-46ad-8e87-41e1d1d10ca1}
Für alle VMs habe ich dann das folgende Kommando ausgeführt:
VBoxManage modifyvm "Oracle Developer Days" --longmode off VBoxManage modifyvm "ubuntu-laptop" --longmode off VBoxManage modifyvm "betoffice-server" --longmode offUnd schon lassen sich die VMs wieder starten.
git config core.filemode false
At present, due to a bug in Firefox where .getAllResponseHeaders() returns the empty string although .getResponseHeader('Content-Type') returns a non-empty string, automatically decoding JSON CORS responses in Firefox with jQuery is not supported.Das Problem hatte ich mir natürlich selbst eingebrockt. Die Javascript Resource, die den Ajax Aufruf absetzen möchte, residiert unter der URL
Zu finden unter jQuery.ajax()
http://tippdiekistebier.localhost/aktuell/auto_1tipp.html
Der Ajax Aufruf ist ein POST an die URL
http://tippdiekistebier.localhost:8080/betoffice-jweb/tipp/submit
Damit handelt es sich um ein sogenanntes "Cross-Origin Resource Sharing". Die Server URL ist die vermeintlich Gleiche. Ausschlaggebend ist hier aber die zusätzliche Port Nummer für den POST Befehl. Damit der Browser die Response verarbeitet, muss der Server im Response Header die Eigenschaft
response.setHeader("Access-Control-Allow-Origin", "*");
setzen. Falls diese Eigenschaft nicht gesetzt ist, kann der Browser die Response verweigern, was die mir bekannten Browser auch alle so umsetzen. Zusätzlich dazu setze ich den Content-Type.
response.setHeader("Content-Type", "application/json; charset=UTF-8");
Die jQuery Ajax Funktion kann die Response dem JSON Format zuordnen und automatisch ein Javascript Objekt erzeugen. Das funktioniert mit einer aktuellen Chrome Version, wie auch mit dem Internet Explorer 9. Unter Firefox findet die automatische Konvertierung nicht statt. Einen Hinweis zu diesem Problem findet sich in der Doku von jQuery (siehe oben). Ich muss also unterscheiden, ob ich die JSON Konvertierung selbst durchführe oder diese bereits von jQuery durchgeführt wurde. Im Beispielcode frage ich das Transport Objekt nach einer erwarteten Eigenschaft ab. Ist diese nicht definiert, führe ich die Funktion $.parseJSON(...) aus. Danach kann die eigentliche Verarbeitung der Response erfolgen.
$.ajax({
type : 'POST',
url : 'http://tippdiekistebier.localhost:8080/betoffice-jweb/tipp/submit',
data : my_data,
cache : false,
success : function(transport) {
if (transport === undefined) {
_messageSender.successButNoResponse();
} else {
try {
var jsonResponse = transport;
if (transport.notOk === undefined
|| transport.ok === undefined) {
jsonResponse = $.parseJSON(transport);
}
if (jsonResponse.notOk) {
....
} else if (jsonResponse.ok) {
....
}
} catch (exception) {
_messageSender.unexpectedError(exception);
}
},
error : function(xhr, ajaxOptions, thrownError) {
_messageSender.unexpectedError(thrownError);
if (console && console.log) {
console.log("Ajax Request Status: " + xhr.status);
console.dir(thrownError);
}
});
Kennt man das Problem, ist die Lösung relativ naheliegend. Mich hat das jedoch einige Stunden Javascript Debugging gekostet.
org.codehaus.plexus.archiver.jar.Manifest.merge(org.codehaus.plexus.archiver.jar.Manifest) ... Maven Configuration ProblemProblematisch ist die folgende Konfiguration in meiner pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>de.awtools.basic.App</mainClass>
<packageName>de.awtools.basic</packageName>
<!-- options -->
<addClasspath>true</addClasspath>
</manifest>
<manifestEntries>
...
</manifestEntries>
<!-- HIER IST DAS PROBLEM: Maven jar plugin and Eclipse -->
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
An sich ist hier nichts außergewöhnliches deklariert. Problematisch ist das maven-jar-plugin in der Version 2.4. Das Plugin benutzt eine Funktion aus einem anderen Modul (org.codehaus.plexus.archiver.jar.Manifest), welches die MERGE Methode nicht mehr anbietet - zumindest nicht mehr öffentlich (siehe Github und m2eclipse). So kann das maven-jar-plugin die Informationen aus der MANIFEST.MF Datei nicht mit den Daten aus der POM Konfiguration miteinander mergen.
Eine Lösung wäre die Verwendung des maven-jar-plugins in der Version 2.3.2. Ich habe für mich entschieden, den Eintrag im POM mit einem Hinweis erst einmal zu deaktivieren und alle relevanten MANIFEST.MF betreffenden Informationen im POM anzulegen. Damit würde dann der MERGE Vorgang entfallen und alles wäre fein, bis mit Version 2.5.x dieses leidige Problem hoffentlich behoben ist.
UPDATE (28.01.2014):
Das alte Problem hat mich heute wieder eingeholt. Dabei ist mir aufgefallen, dass das Plugin immer noch in der Version 2.4. vorliegt. Da der oben beschriebene Fehler nicht ganz unerheblich ist, habe ich noch einmal nachgeforscht und bin auf den folgenden Link gestossen:
http://maven.apache.org (Examples)
Was soviel bedeutete, dass ein Merge der beiden Konfigurationen nicht vorgesehen ist.
localhost tippdiekistebier.localhost 127.0.0.1 tippdiekistebier.localhostUnter Windows 7 muss der Editor mit Administrator Rechten geöffnet werden. Im Editor dann die HOSTS Datei öffnen und bearbeiten. Der Dialog für das Öffnen von Dateien zeigt in der Regel nur Dateien mit der Endung .txt an. Um die HOSTS Datei zu finden, muss der Filter auf 'alle Dateien' gestellt werden. Im zweiten Schritt wird der XAMPP Apache so konfiguriert, daß er die URL tippdiekistebier.localhost mit dem entsprechendem Server Verzeichnis verbindet. In XAMPP gibt es die folgende Datei:
XMAPP/Apache/conf/extra/http-vhosts. In dieser werden die folgenden Einträge hinterlegt:
## Diese Zeile wird auskommentiert
NameVirtualHost *:80
## Ein Verzeichnis definieren, wo die HTML Dateien liegen werden
## und auf dem die URL tippdiekistebier.localhost verweisen wird.
<Directory "C:/www/lab/tippdiekistebier.localhost">
Order allow,deny
Allow from all
</Directory>
## Hier wird der default definiert. D.h. mit
## http://localhost/xampp/ kommst du auf die von XAMPP
## bereit gestellten Inhalte. (Nicht vergessen die Pfade
## an die lokalen Begebenheiten anzupassen!)
<VirtualHost *:80>
ServerAdmin postmaster@dummy-host.localhost
DocumentRoot "C:/development/devtools/xampp/htdocs"
ServerName localhost
ServerAlias www.localhost
ErrorLog "logs/localhost-error.log"
CustomLog "logs/localhost-access.log" combined
</VirtualHost>/Directory>
## Hier wird nun das Verzeichnis mit der URL verbunden.
<VirtualHost *:80>
ServerAdmin postmaster@dummy-host.localhost
DocumentRoot "C:/www/lab/tippdiekistebier.localhost"
ServerName tippdiekistebier.localhost
ServerAlias www.tippdiekistebier.localhost
ErrorLog "logs/tippdiekistebier.localhost-error.log"
CustomLog "logs/tippdiekistebier.localhost-access.log" combined
</VirtualHost>
Nach der Änderung der Konfiguration muss der XAMPP Apache neu gestartet werden. Falls der Apache nicht wieder hoch fährt, hat man sich vermutlich einen Vertipper eingefangen. In diesen Fällen ist ein Backup immer die erste Wahl!
UPDATE: 20.12.2014 Falls du dir nun mit dem Chrome Browser das Ergebnis betrachten möchtest, musst du die folgende Adresse im Browser eintragen:
tippdiekistebier.localhost/Das letzte / ist dabei entscheidend. Fehlt dieses sucht Chrome im Internet nach der passenden Adresse und wird sie im Anschluss nicht finden.
npm install bower -gIm ersten Versuch habe ich nach Anleitung jQuery installieren wollen. Auf meinem Notebook mit cygwin hatte ich keine Probleme (Bower macht regen Gebrauch von GIT und benötigt entsprechend eine Installation). Auf meinem Desktop Rechner erhielt ich aber die folgende Fehlermeldung:
$ bower install jquery bower cloning git://github.com/components/jquery.git bower cached git://github.com/components/jquery.git bower fetching jquery bower error status code of git: 128 There were errors, here's a summary of them: - jquery status code of git: 128 fatal: Not a git repository (or any parent up to mount parent /cygdrive) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).Die Lösung war der zusätzliche Parameter
--force:
bower --force install jqueryDas erzwingt das Anlegen eines lokalen GIT Repositories und jQuery findet sich in Unterverzeichnis components wieder. Wieso nun das Anlegen auf dem einen Rechner klappt, auf dem anderen der zusätzliche Parameter --force benötigt wird, dass kann ich leider nicht sagen. Eine Erklärung habe ich bisher über Google nicht gefunden.