Re: [Hbci4java-help] [Bug 84] Probleme, wenn Threads nicht selbst erzeugt werden (bei Tomcat etc .)

[Rolf V. <ro...@we...>]

> > Aber gut, diese Diskussion ist wahrscheinlich für diese Mailingliste schon leicht "off topic", daher sollten wir das wohl nicht vertiefen. Es spricht ja auch nichts dagegen, den bisherigen Mechanismus mit den Factories beizubehalten, ich war nur irrtümlich davon ausgegangen, dieser wäre eigentlich unnötig und würde nicht real genutzt werden. Wenn dem so gewesen wäre, hätte man ihn in der nächsten Version einfach weglassen können.
>
> Sie ist off-topic, hier aber trotzdem auch mein Senf dazu: ich bin eher
> ein Verfechter der shared-libs-Variante (nicht wg. des Speicherplatzes).
>
> Wenn z.B. in der libpng ein potentiell gefährlicher buffer overflow
> behoben wird, will ich alle meine Anwendung, die diese Bibliothek
> verwenden, nicht neu installieren / compilieren müssen. In einem
> shared-lib-System aktualisiere ich nur meine EINE Version der
> Bibliothek, und alle darauf basierenden Anwendungen sind wieder
> "sicher" ;-)
>
> Das Problem mit Anwendungen, die eigene Versionen bestimmter
> Bibliotheken mitbringen, besteht zum Teil darin, dass wichtige
> Bugfixes oder Erweiterungen an der Original-Bibliothek erst sehr
> viel später - wenn überhaupt - auch bei der Anwendung ankommen
> (nämlich erst dann, wenn sich der Verantwortliche entschließt, mit
> der Anwendung auch die neuere Version der Lib. auszuliefern).
>
> Außerdem ist z.B. gerade HBCI4Java eine Bibliothek, in der aufgrund der
> großen Artenvielfalt und Mutations-Freudigkeit der verschiedenen
> HBCI-Server doch relativ häufig Anpassungen gemacht werden (müssen),
> damit auch der Server der Bank XY damit zufrieden ist (bzw. HBCI4Java
> die Nachrichten dieses Servers versteht). Wenn denn auch jedesmal
> ein Update der darauf basierenden Anwendungen notwendig wäre, kann
> man tolle Install-Parties übers Wochenende daraus machen ;-)


Nun, ich muss gestehen, dass das in der Tat ein gutes Argument für den shared-libray-Ansatz ist. Zwar bieten viele Programme heutzutage einen bequemen auto-update-Mechanismus, und unter Linux kann man ja sehr bequem alle Updates auf einen Schlag einspielen, aber das bringt natürlich nichts, wenn die Anwendung nicht sonderlich häufig upgedatet wird.

Letztlich gibt es auch hier vermutlich keinen Königsweg. Mir persönlich behagt es mehr, wenn ein Programm alle Libraries mitbringt, und zwar in genau der Version, mit der die Autoren der Software diese getestet und für "gut" befunden haben. Das sollte zu extrem wenigen Kompatibilitätsproblemen führen (denn die würden ja schon während der Entwicklung auffallen). Aber das Argument mit den Sicherheitslücken in Libraries ist nicht von der Hand zu weisen.


> Obwohl ich mir jetzt selbst widerspreche, finde ich die Lösung in
> Hibiscus aber gut - also dass dort eine bestimmte Version der Bibliothek
> mitgeliefert wird. Das liegt aber wohl auch daran, weil man von
> Hibiscus bei Bedarf auch eine bleeding-edge-Version der Software
> bekommen kann (die nightly builds), in denen i.d.R. auch eine sehr
> aktuelle (teilweise SVN-Versionen) HBCI4Java dabei ist.


Es hängt wohl von diversen Faktoren ab, was macht die Anwendung, wie genau nutzt sie die Library, wie oft wird sie aktualisiert, etc.


> > Ein derartiges _gemeinsames_ Callback-Objekt hat Stefan aber für die nächste Version der Library geplant, ich denke jedoch, dass das keine so gute Idee wäre. Es hätte für manche Szenarien Nachteile, im Gegenzug scheint es mir jedoch keine Vorteile zu geben.
>
> So wollte ich meine diesbezügliche Aussage nicht verstanden wissen. :-)
>
> Mir ging es nur um den Punkt, dass bei einem Callback-Aufruf auch die
> aktuelle "HBCI-Session" als ein Parameter mit übergeben wird, damit eine
> Anwendung, die tatsächlich nur ein gemeinsames Callback-Objekt für alle
> HBCI-Sessions führen will, bei einem Callback auch noch unterscheiden
> kann, in welche Session der aufgetreten ist.
>
> Im Moment ist es so, dass man pro ThreadGroup ein eigenes Callback-
> Objekt verwenden kann (aber nicht muss). Das wird in dieser Form
> auch weiterhin so sein,


Achso. Dann hab ich das in der Tat missverstanden, sorry. Ich hatte schon gedacht, in Zukunft wäre nur noch ein einziges Callback-Objekt für die ganze Anwendung möglich, das hätte ich nicht gut gefunden. Es ist natürlich prima, wenn die Callback-Methoden die HBCI-Session bekommen, um die es geht, das ist sicher sinnvoll. Dann ist beides möglich, ein einziges Objekt, oder mehrere. Die Anwendung kann also beliebig designed sein :)


> nur dass HBCI4Java-3 sich nicht mehr um
> Threads schert, sondern das Konzept von "HBCI-Sessions" einführt,
> die anwendungsseitig natürlich mit Threads korrespondieren können,
> aber nicht müssen.


Klingt sehr vielversprechend :)


> > Mein Vorschlag wäre weiterhin, den Session-Identifier von außen (also durch die Anwendung) festzulegen, und nicht mehr auf die ThreadGroup zu schauen. Im Moment findet eine Trennung von Sessions ja immer anhand der ThreadGroup statt, hier wäre es einfach besser, die Trennung anhand eines Merkmals zu haben, dass die Anwendung vorgibt. Das kann ja evtl. auch die ThreadGroup sein, aber oftmals wird das irgendeine SessionId sein.
>
> Wie schon in einer der letzten Mails beschrieben: die Anwendung
> legt Instanzen von "HBCISession" an. Ein solches HBCISession-Objekt
> ist dann praktisch der "Session-Identifier". Alle möglichen anderen
> Objekte wie HBCIPassport, HBCIHandler (falls es sowas noch geben wird),
> usw. gehören dann zu einer bestimmten HBCISession.


Klingt ebenfalls sehr vielversprechend :)


> Es wird sicherlich auch weiterhin einige globale Konfigurations-
> Mechanismen geben, die aber eher als default-Wert für die HBCI-Sessions
> anzusehen sind und die man für eine bestimmte HBCI-Session auch
> ändern kann (in dem Punkt bin ich mir über das Ob und Wie aber noch
> nicht ganz klar).


> > Kurz zusammengefasst meine Vorschläge, nachdem ich jetzt meine falschen Vorstellungen losgeworden bin:
> > -> Bisheriger Mechanismus mit Factories, die von der Anwendung überschrieben werden können, sollte beibehalten werden, weil dieser (entgegen meinen Vermutungen) rege genutzt wird.
>
> Es wird einen NEUEN Mechanismus geben. HBCI4Java-2 setzt an dieser
> Stelle viel auf Reflection, was sehr viele Nachteile mit sich bringt.
>
> Reflection wird in HBCI4Java-3 gar nicht mehr benutzt (zumindest ist das
> das Ziel). Statt dessen wird es saubere Factory-Mechanismen geben wie
> in einer der vorherigen Mails skizziert.


Ah, das war mir auch noch nicht ganz klar. Klingt aber auf jeden Fall nach einem guten Plan :)


> Grüße
> -stefan-


Viele Grüße, Rolf