Beiträge mit dem Stichwort ‘Bug’

Symfony2: Could not parse object ’303b8a83c87d5c6d749926cf02620465a5dcd0f2′

Veröffentlicht am 26. August 2011 um 21:39 by Fabian Martin Permalink

Beim updaten meiner Projekte auf Symfony 2.0.1 ist mir eben die folgende Fehlermeldung ins Auge gestochen:

Could not parse object '303b8a83c87d5c6d749926cf02620465a5dcd0f2'

Scheinbar gibt es Probleme beim Aktualisieren von monolog. Alle anderen Abhängigkeiten werden ordentlich aktualisiert.

Was kann man tun?

Ein kurzer Blick in die Ankündigung bringt auch schon die Lösung. Löscht einfach den Ordner vendor/monolog und führt noch einmal bin/vendors install aus. Monolog sollte jetzt ebenfalls aktuell sein.

Windows/TortoiseGit: Ordner wird verwendet

Veröffentlicht am 31. Januar 2011 um 20:35 by Fabian Martin Permalink

Wir Windows User machen uns das Leben echt einfach. Für alles muss eine GUI her. Konsole? Ihh, nää, kann ich nicht. Ich brauch eine schicke Oberfläche.

Das gilt natürlich auch bei der Arbeit mit der Versionsverwaltung. Selbst wenn es sich um Git dreht, das man eigentlich nur auf der Konsole richtig nutzen kann. Nein, auch da muss eine GUI her, also greift man zu TortoiseGit.

Commit, Push, Pull, Log, alles kein Problem, aber schon mal versucht auf einem System mit TortoiseGit ein Repository/Projektordner zu löschen?

ordner-wird-verwendet

Wie „erfreulich“ diese Meldung doch ist, und dank TortoiseGit sieht man sie sogar regelmäßig. Was macht man jetzt? Wie bekloppt auf „Wiederholen“ klicken, bis es irgendwann klappt?
weiterlesen »

VS 2010: Pakete werden nicht ordnungsgemäß geladen

Veröffentlicht am 11. September 2010 um 15:12 by Fabian Martin Permalink

Das “RadLangSvc.Package, RadLangSvc.VS, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91″-Paket wurde nicht ordnungsgemäß geladen.

Solltet ihr auch von Fehlermeldungen dieser Art geplagt werden und eine Reparatur von Visual Studio keinen Erfolg gebracht haben, dann schnappt euch eure Installations DVD und installiert die folgenden Pakete nach. Zu finden sind sie im Pfad x:\WCU\DAC.

  • DACFramework_deu.msi
  • DACProjectSystemSetup_deu.msi
  • TSqlLanguageService_deu.msi

Die Meldungen sollten, nach der Installation, verschwunden sein.

PHP + PDT: Probleme bei der Installation des Zend Debuggers

Veröffentlicht am 18. Juni 2010 um 23:44 by Fabian Martin Permalink

Wer derzeit versucht den Zend Debugger über die Update Seite zu installieren, wird das Problem bereits bemerkt haben. Es funktioniert nicht.

Scheinbar haben sich vor einiger Zeit die Dateinamen/Versionen geändert, aber es wurde versäumt die Update Seite zu kontrollieren. Während der Installation versucht Eclipse Dateien herunterzuladen die es auf dem Server nicht (mehr) gibt.

Was kann man also machen?
Die Lösung des Problems ist eigentlich recht einfach. Das einzige was wir hierzu benötigen ist ein Apache Server mit aktiven mod_rewrite, ein Packprogramm und ein Texteditor.

Speichert die content.jar der Update Seite auf eurem PC und entpackt den Inhalt in einen Ordner eurer Wahl. Es sollte jeder handelsübliche Packer, der das ZIP Format versteht, möglich sein.
In dem Zielordner sollte sich jetzt eine content.xml befinden. Öffnet diese mit einem Textprogramm und ersetzt alle Vorkommnisse von 20091116 durch 20091124. Packt die content.xml nun wieder in eine ZIP Datei und nennt diese content.jar.

Erstellt eine .htaccess und fügt folgenden Inhalt ein:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.* http://downloads.zend.com/pdt/$0 [L]

Ihr habt jetzt eine .htaccess die jede Anfrage an eine nicht existierende Datei an die offizielle Update Seite weiterreicht.
Legt beide Dateien nun in ein Verzeichnis unterhalb eures Apache Web Roots und tragt die URL als Update Seite bei eclipse ein.

Ihr könnt nun ohne größere Schwierigkeiten den Zend Debugger installieren. Wer keine Lust hat die Änderungen selbst durchzuführen, oder den Text durchzulesen, der kann sich die geänderten Dateien auch herunterladen, oder er trägt http://a2.localdev.de/zend/ als Update Seite ein.

Downloads:

Lighttpd 1.4: HTTP 417 Expectation Failed

Veröffentlicht am 13. Januar 2010 um 15:22 by Fabian Martin Permalink

Versucht man mit einer cURL oder .NET Anwendung POST Daten an einen Lighttpd 1.4 Server zu senden, bekommt man die Meldung


HTTP/1.1 417 Expectation Failed

Dies liegt daran, das die Programme einen Expect: 100-continue Header senden, und als Antwort 100 (Continue) oder 417 Expectation Failed erwarten. Lighty kennt den Header jedoch nicht, und antwortet deswegen mit dem besagten 417 Expectation Failed.

Der Expect: 100-continue Header soll verhindern, das Daten an den Server gesendet werden, die nicht benötigt werden. Erkennt der Server z.B. das er die Anfrage ablehnen muss, kann er dies dem Client mitteilen, noch bevor die POST Daten übermittelt wurden.

Wer dennoch POST Daten an Lighty senden möchte, kann die folgenden Paramter anpassen:

.NET


System.Net.ServicePointManager.Expect100Continue = false;

cURL unter PHP

curl_setopt($objCurl, CURLOPT_HTTPHEADER, array('Expect: '));

cURL auf der Kommandozeile

curl -v -H "Expect: " -F "field=value" http://example.com/upload.php

Alternativ aktualisiert man auf Lighttpd 1.5. Dieser kennt den Expect: 100-continue Header und beantwortet entsprechende Anfragen korrekt.

Browser senden übrigens keinen Expect: 100-continue Header.