Ich hab gerade gesehen das die Jungs von Sonar/SonarQube die Version 4.1 raus gebracht haben aber dabei den Support für Tomcat eingestellt haben.
Hat irgendwer das trotzdem irgendwie hinbekommen Sonar in einem Tomcat laufen zu lassen und nicht als Standalone Version?
Ich hab keine Lust dafür wieder nen neuen Port auf meinem Server aufmachen zu müssen.
Wieso neuen Port aufmachen? Vielleicht verstehe ich die Frage nur falsch, aber ich lasse solche Dienste eh nur lokal laufen und “publiziere” die über einen Reverse Proxy (früher Apache, inzwischen nginx). Da kann man z.B. auch sehr einfach SSL oder Auth drüber stülpen und Audit ist auch an zentraler Stelle. Das wird auch in einem Reply auf das Announcement auf der Mailing Liste vorgeschlagen.
Hmmm müsste ich mal gucken wie ich das hinbekomme
bisher habe ich halt einfach einen Tomcat für meine ganzen internen Sachen wie jenkins, sonar und die Anwendungen die über den Tomcat getestet werden.
Aber stimmt wenn ich für das ganze Teil einen Proxy einrichte wäre das Problem gelöst
Was bedeutet das denn, es unterstützt kein Tomcat mehr? Läuft es jetzt Standalone oder wie? Wir sind hier noch auf 3.7.3 und würden am Freitag ein Update machen, geht das nicht so einfach wie erhofft?
Ja.
Wenn ihr es in einem Tomcat deployed habt, dann geht das nicht (außer ihr wollt nur auf die 3.7.4).
habs jetzt mit nginx gemacht, gefällt mir zwar nicht aber hab ja keine Wahl 
Ich habe auch einen nginx als inverse-Proxy in Betrieb und bin mit dem derzeitigen Setup noch nicht so ganz zufrieden. Ich nutze ihn, um PHP-Anwendungen (per FastCGI), Perl-Anwendungen (mit nem anderen Modul) und einen Tomcat auf Port 80 anzubieten.
Was mich daran stört, ist die Ausgabe der Fehler. Wenn es einen Fehler in eine Anwendung gab, dann remappt der nginx die Ausgabe. Außerdem bekomme ich beim Debuggen hin und wieder nginx-Timeouts. Und man muss gewaltig mit den Puffergrößen aufpassen, damit das alles zuverlässig läuft.
Ja, das sind alles Konfigurationsprobleme. Was ich damit aussagen will: mal eben schnell einen Reverse-Proxy aufsetzen führt nicht unbedingt zu voller Zufriedenheit.
jo deshalb hab ich den nginx auch rein nur für den internen Part aufgesetzt den ich hab und nichts anderes, irgendwie läuft das auch alles nur holprig
Weiß jetzt nicht genau, was du mit „remappen“ meinst. Standardmäßig wird alles einfach nur weitergeleitet. Wenn man die Fehler abfangen und selbst behandeln will, hilft proxy_intercept_errors.
Bei der Entwicklung einer auf symfony basierenden Webanwendung kam es immer mal wieder zu 500er Errorcodes. Dann wurde statt der durch symfony generierten Webseite die Standard nginx 500er Fehlerseite angezeigt und somit waren Debugginginformationen nicht sichtbar.
Welcher Konfigurationsfehler das genau war, habe ich im Detail dann nicht nachvollzogen.
Wie oben ja auch von mir angedeutet, muss man sich mit dem Thema ein wenig auseinandersetzen, um es vernünftig zum Laufen zu bekommen. Der Aufwand dürfte sich in vielen Fällen aber lohnen.