Laden von Modulen

[andreas61]

Hallo,

ich habe folgende Frage. Kann ich in Netbeans-Rcp die Reihenfolge in der die Module geladen werden beeinflussen und wenn ja wie?
Hintergrund der Frage ist, das ich Module geschrieben habe, das den Loginmechanismus beinhaltet. Diese Mechanismus wird im Module via Modul Installer gestartet. Jetzt muss ich aber sicher sein, das dieses Modul in jedem Fall geladen wird bevor Module starten, die Daten aus dem Login brauchen.


Gruß

Andreas

[andreas61]

Hallo,

die Frage hat sich erledigt.
Der Loginmechanismus im Module ist ok, aber der Modul Installer muß in einem Module der Rcp-Applikation bzw. der Suite überschrieben werden.


Gruß

Andreas

[arittner]

Moin!

Exakt, nur die Modul-Abhängigkeiten entscheiden über eine "lokale" Reihenfolge. D.h. die Reihenfolge kann nur im Sichtbarkeitsbereich (Skope) der Abhängigkeits-Hierarchie der Module gesteuert werden. Darüber hinaus ist der Start der Module in einer bestimmten Reihenfolge undefiniert. Soll heißen, wenn Du keine Abhängigkeit zu einem Modul aufgebaut hast, kann es Dir auch wurscht sein, wann es aktiv wird.

Natürlich stellt sich die Frage, warum das bei einem Login nicht einfacher zu lösen wäre, weil man ja viele Moduleinheiten transparent zum Account programmiert (ggf. hinterlegen nur Basis-Bibliotheken nur den aktuell angelegten Anwender). Aber da hat man sofort die Abhängigkeit wieder in der richtigen Reihenfolge, Beispiel:

DB Core Modul benötigt Anmeldedaten für die Datenbank und hat damit die Abhängigkeit zum Login-Modul (welches die Credentials zur Verfügung stellt). Alle weiteren Module, die (beispielsweise) Kundenerfassung, Auftragswesen usw. zur Verfügung stellen sind essentiell von dem DB Core Modul abhängig. Damit hast Du eine erfolgreiche Verkettung von Abhängigkeiten. Kein Login, keine lauffähige Anwendung.

Ein Login-Modul kann bei seiner Aktivierung (im Installer) verschiedenartig reagieren.

1. Über den LifcycleManager die Anwendung beenden.
2. Sich selbst mit einer IllegalStateException in validate() verabschieben
3. oder per AutoUpdate-API andere Module explizit deaktivieren.

1) wird häufig gemacht, man verwirkt sich aber ggf. ein paar nette Features (Demo Version, Admin Konfig-Login für Erstinstallation usw).
2) Ist die Hammerharte Version, wenn man zum Login-Fehlschlag noch die signierte Lizenzdatei fehlt. Die Exception ist sehr unschön, aber man hat dann eine leere RCP-Anwendung
3) Wenn man damit geschickt umgeht, kann man ggf. über ein Modul einen bestimmten Abhängigkeitsgraphen gezielt deaktivieren und (andere aktivieren), um eine Art Demo-Anwendung laufen zu lassen. Evtl. auch mit Hilfe und Verlinkung zur Homepage. Oder der Möglichkeit der Versendung einer Service-Mail. Usw. usf.

Beste Grüße,
Josch.

[arittner]

Moin!

Ich möchte noch (der Vollständigkeit halber) hinzufügen, dass man Login-Dialoge, die über den DialogDisplayer angezeigt werden, vor der Anzeige des Hauptfensters darstellen kann.

Dafür gibt es folgende Methode:

Code: Alles auswählen

NotifyDescriptor notifyDescriptor = new NotifyDescriptor.Confirmation (loginForm, "Login");
notifyDescriptor.setOptions(new Object[] {ok, cancel});
DialogDisplayer.getDefault().notifyLater(notifyDescriptor);


loginForm wäre ein JPanel und ok sowie cancel zwei JButtons (mit passenden ActionListenern).

Der Trick liegt in der Methode notifyLater, die in einem ModuleInstaller in der restored()-Methode den Dialog exakt vor der Anzeige des Main-Windows einblendet.

Beste Grüße,
Josch.

[andreas61]

Hallo Josch,

ich habe diese Variante für meine Login-Box genutzt. Habe aber leider das Problem das "LifecycleManager.getDefault().exit();"
hängen bleibt und sich das Programm dann nur noch durch abschießen des Prozesses beenden läßt.
In den Foren ist zu lesen, das "LifecycleManager.getDefault().exit();" ein öfter diskutiertes Problem ist, aber eine Lösung habe ich bisher noch nicht dafür gefunden.
Hast Du einen Tip wie das Problem zu lösen ist:

Anbei mein Installer

Code: Alles auswählen

public class Installer extends ModuleInstall implements ActionListener{

    private KtstLoginPanel loginPanel= new KtstLoginPanel();
    private DialogDescriptor dd=null;

    @Override
    public void restored() {
        dd=new DialogDescriptor(loginPanel,"Login",true,this);
        dd.setClosingOptions(new Object[]{});
        // hier reaagieren wir auf F4 (Fensterschliessen)
        dd.addPropertyChangeListener(new PropertyChangeListener() {

            @Override
            public void propertyChange(PropertyChangeEvent evt) {
                if (evt.getPropertyName().equals(DialogDescriptor.PROP_VALUE)
                        && evt.getNewValue()== DialogDescriptor.CLOSED_OPTION) {
                    LifecycleManager.getDefault().exit();
                }
            }
        });
//        DialogDisplayer.getDefault().notifyLater(dd);
        DialogDisplayer.getDefault().notify(dd);
    }

    @Override
    public void actionPerformed(ActionEvent e) {
        KtstLoginCheck check=new KtstLoginCheck();
        if (e.getSource()== DialogDescriptor.CANCEL_OPTION) {
            LifecycleManager.getDefault().exit();
        } else {
            if (!check.loginCheck(loginPanel.getUser(), loginPanel.getPassword(),loginPanel.getDatabase())) {
                loginPanel.setInfo("Benutzername oder Password falsch");
            } else {
                dd.setClosingOptions(null);
            }
        }
    }
}


Wie zu sehen, nutze ich die Methode notify , um sicherzustellen das der Dialog modal ist.
Ich hatte vorher mit notifylater experimentiert aber dann geht das Datenbank-Login in die Hose,
weil die Login-Informationen noch nicht gefüllt sind, wenn mein Viewer startet.
Du weist ja nochmal auf notfiylater, habe ich hier einen Denkfehler???
Ist das vielleicht auch die Ursache für das Problem mit dem LifecycleManager.getDefault().exit() ???

Gruß Andreas

[arittner]

Moin!

LifecycleManager.getDefault().exit() sollte entweder aus dem Thread gestartet werden, der per notifyLater aufgerufen wurde oder in Ausnahmefällen in SwingUtilities.invokeLater (...). Zwar handelt es sich in beiden Fällen um den EventDispatcherThread (das ist sowieso Pflicht), aber so weit in den Event-Queue nach hinten geschoben, dass es keine Deadlocks geben sollte.

Warum Dein Login-Dialog Probleme bekommt, wenn notifyLater verwendet wird, kann ich nicht sagen. Vermutlich wurden schon zu viel Module aktiviert, die irgendwelche Seiteneffekte verursachen. D.h. aber (da die Modulaktivierung global nicht deterministisch ist), dass Dir das Problem später wieder auf die Füße fallen kann, wenn sich mal die Ladereihenfolge verändert hat.

Beispiel, wo M5 zwingend Logindaten benötigt

Ladereihenfolge mit notify
M3, M1, M2, M-Login -> notify -> Login Daten abfragen, Ok -> M4, M5, M6 -> Main-Window

Ladereihenfolge mit notifyLater
M3, M1, M2, M-Login -> notifyLater -> M4, M5, M6 -> Login Daten abfragen, Ok -> Main-Window

Jetzt Wochen später mit notify:
M3, M1, M2, M5, M-Login -> notify -> Login Daten abfragen, Ok -> M4, M6 -> Main-Window

Nun mal ein Abbruch per exit direkt aus notify:
M3, M1, M2, M-Login -> notify -> Login Daten abfragen, Cancel -> exit() [...Modul System greift auf diese M's zu]-> M4, M5, M6

Da LifecycleManager.getDefault().exit() im EDT ist und das ModulSystem in einem extra Thread die Module lädt bekommst Du (wie schon beobachtet) manchmal einen Deadlock.


Du musst also deine Abhängigkeiten sauber bekommen. Logindaten ggf. ausschließlich per Services anfordern (z.B. Lookup.getDefault().lookup (Account.class)), so dass Du nicht mehr wissen musst, wann das Modulsystem welche Module geladen hat. Über die ServiceLoader Architektur kann das Modulsystem die Anforderung in eine saubere Ladereihenfolge umsetzen (bedingt schon über die zwingende Compile-Zeit-Abhängigkeit). Wenn Du die Kopplung extrem lose hast, kannst Du auch Listener auf das Result<Account> setzen und erst dann los arbeiten, wenn Accountdaten gesetzt wurden. Dann kann Dir die Reihenfolge komplett egal sein, und der Fall mit notifyLater und dem M5 Modul klappt dann auch

Beste Grüße,
Josch.

[andreas61]

Hallo Josch,

Danke für die schnelle Antwort!!!!
Ich habe hier wohl noch einiges zu tun.


Gruß Andreas

[andreas61]

Hallo Josch,

nochmal eine kurze Meldung.
Habe jetzt meine Loginbox via Services und Moduleinstaller-Class geklärt. Klappt prima.
Das Problem mit Notifylater hat sich damit auch geklärt.
Danke nochmal für Deinen Tip.


Gruß Andreas

[arittner]

Moin!

Bitte, es geht doch nichts über eine saubere Modularchitektur - da lohnt es sich auch etwas Arbeit rein zu stecken.

Beste Grüße,
Josch.