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

[Stefan P. <kl...@ho...>]

Hi,

> > > Nun, man müsste dann halt die HBCI4Java-Bibliothek selbst kompilieren,
> > > damit diese zur Compilezeit alle zusätzlichen Klassen kennen.
> >
> > Das wuerde aber implizieren, dass jede Anwendung ihre eigene
> > Version von HBCI4Java mitbringt. Fuer OpenSuSE aber gibt es
> > HBCI4Java z.Bsp. als RPM (http://packman.links2linux.de/package/hbci4java),
> > welches als Abhaengigkeit von mehr als einem Paket verwendet wird.
> 
> 
> Ahso, daran hatte ich überhaupt noch nicht gedacht. Wobei ich es nicht als Nachteil ansehen würde, wenn jede Anwendung ihre eigene Version mitbringt, denn:
> 1.: Könnte so der Entwickler der Anwendung sicherstellen, dass die vorhandene Version von HBCI4Java zur Anwendung auch wirklich kompatibel ist, und dann diese definitiv kompatible Version einfach mitinstallieren lassen.
> 2.: Könnte der Entwickler der Anwendung so seine Erweiterungen einfach in seine Instanz der Library eincompilieren, und wäre beliebig flexibel (beliebige Änderungen wären möglich, sofern sinnvoll).
> 3.: Dürfte ein typischer Anwender vermutlich nur ein Programm auf seinem Rechner installieren, dass HBCI4Java nutzt. Falls er tatsächlich mehrere Programme installiert, dürfte der sehr geringe Mehrbedarf an Speicherplatz nicht ins Gewicht fallen.
> 
> Aber gut, das ist letztlich Ansichtssache, und lässt sich vermutlich nachträglich nicht mehr sonderlich gut umentscheiden. Ich bin schon länger der Meinung, das shared libraries in vielen Fällen mehr schaden, als nutzen, und dass es oftmals einfacher ist, wenn eine Software ihre Libraries einfach selbst mitbringt (unabhängig vom Betriebssystem) - ausgenommen natürlich Libraries, die fast jedes Programm benötigt, und die tatsächlich dutzendfach im System vorhanden wären. Das würde vieles vereinfachen (keine Versionskonflikte mehr), und der zusätzliche Speicherplatzbedarf dürfte 99% aller User nicht wirklich interessieren.
> 
> 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 ;-)

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.


> 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 - 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.


> 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.

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.


Grüße
-stefan-

-- 
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme
 
email: kl...@ho...
www:   http://hbci4java.kapott.org
       http://converter-db.de
       http://myamavis.kapott.org
icq:   36376278
 
key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------