Questions & Answers

[graulich]

Hallo zusammen,

wir haben ein Swing-Java-Tool, mit welchem wir über die Access-API auf den FirstSpirit Server verbinden.

Für jede Minor-Version müssen wir aktuell die access.jar austauschen, damit die API Verbindung geöffnet werden kann.

Gibt es eine saubere Möglichkeit, den Versionscheck zu "umgehen"?

Wir haben aktuell eine "Lösung" über einen eigenen ClassLoader - müssten jedoch unser komplettes Tool auf Reflection umstellen, bzw. beim Packaging des Tools darauf achten, zu welcher Version das ganze raus gehen soll.

Gibt es eine "offene" access.jar, in welcher der Check nicht durchgeführt wird?

Wir nutzen nur Klassen, und Methoden, welche sich in der kompletten 4.2er FS Version bis einschl. 5.0 nicht geändert haben und finden deswegen ein Packaging zur Minor-Version in unserem Fall übertrieben.

Hoffen auf eure Antworten und Tipps.

Beste Grüße

Dominic

[Hendrik]

Hi,

probier mal eine System Property "skipVersionCheck" mit true zu setzten, sollte klappen

Wir verwenden das z.T. in den JNLP-Dateien, dort funktioniert es auf diese Weise.

[Peter_Jodeleit · Accepted solution]

Wir nutzen nur Klassen, und Methoden, welche sich in der kompletten 4.2er FS Version bis einschl. 5.0 nicht geändert haben und finden deswegen ein Packaging zur Minor-Version in unserem Fall übertrieben.

Ich will hier nichts "vorwegnehmen", aber hinter den offiziellen, sich nicht ändernden Schnittstellen liegen Implementierungen, die sich durchaus auch zwischen zwei Minor-Versionen ändern können. Das würde dann zu einer Inkompatibilität führen, die bei Umgehung des Versions-Checks zu unerwarteten Fehlern und im schlimmesten Fall auch zu inkonsistenen Zuständen führen kann.

Also ich würde eine Aktualisierung des Jars empfehlen, wenn der FirstSpirit-Server aktualisiert wird.

Das sollte ja nicht allzu häufig auftreten.

Oder man automatisiert die Aktualisierung - der Download des fs-client.jar ist ja über http möglich.

[andre]

> Wir verwenden das z.T. in den JNLP-Dateien, dort funktioniert es auf diese Weise.

warum denn? was ist der Grund? warum ein solches risiko eingegangen wird? ein jar auszutauschen, kann doch hier wirklich nicht das argument sein....oder?

wie seit ihr denn an den parameter dran gekommen?

[Hendrik]

Rein für experimentelle Entwicklungszwecke, keine Bange. Wir verwenden ein ähnliches Tool wie der Threadstarter um eine Verbindung mit FirstSpirit herzustellen welche dann in einer lokalen Beanshell verwendet wird, quasi eine Beanshell ohne Java Client die über Webstart gestartet wird..

[graulich]

Hallo zusammen,

wir haben das externe Tool nun einfach als Modul gebündelt und schippern es direkt in FirstSpirit aus.

Somit umgehen wir eine Bündelung für jede FS-Minor-Version und der Kunde braucht nicht mit umständlichen JAR/BAT/SH Files hantieren...

Danke für die Anregungen.

Beste Grüße

Dominic