Quello che mi piacerebbe fare è creare un framework "launcher" per il mio codice che, dato un URL e uno schema di versioning predefinito: 1) controlla se esiste un aggiornamento 2) scaricare gli aggiornamenti 3) "install" l'aggiornamento 4) "re-run" l'applicazioneUtilizzo di OSGi per implementare l'aggiornamento automatico
voglio a) fare tutto questo all'interno della JVM esistente e b) essere indipendente dalla piattaforma. Alto ordine giusto? Basandomi sulla mia (limitata) conoscenza di OSGi e Apache Felix sono abbastanza sicuro che ciò sia possibile, ma mi sto davvero perdendo nei dettagli.
Controllare l'aggiornamento e scaricarlo è banale. Causando il "vecchio" pacchetto da scaricare e il "nuovo" pacchetto da caricare è dove mi sto bloccando. Ho fatto il lavoro di OSGi in passato, ma era molto meno dinamico di questo. Un buon punto di partenza o una buona spinta nella giusta direzione sarebbe molto apprezzato.
Se sto sovraccaricando seriamente qualcosa che è già stato risolto con una libreria gratuita, ditelo anche questo, ma non ho trovato nulla finora. :-)
Questa volontà perché il bundle precedente non è corretto? Cosa succede al bundle esistente dopo l'aggiornamento (ad esempio sul disco rigido)? – user453385
La risposta di Richard è succinta e corretta, vedi http://www.osgi.org/javadoc/r4v43/org/osgi/framework/Bundle.html#update%28java.io.InputStream%29 - lo stato del (vecchio) bundle essere cambiato in DISINSTALLAZIONE, nel qual caso non è più disponibile. Non sono sicuro di cosa facciano tutti i framework - rimarranno sicuramente sui bundle tra riavvii, immagino che un bundle disinstallato venga rimosso completamente (sia da JVM che dalla garbage collection non è impedito, così come dalla cache del disco). OSGi è una soluzione perfetta per le tue esigenze, che se flessibile può essere eseguita semplicemente con un gestore di posta prepagata e gestore di mvn pax mvn – earcam
L'aggiornamento fa sì che il vecchio bundle "svincoli" e diventi disponibile per la garbage collection. Subito dopo un aggiornamento ci sono due revisioni del bundle sul disco rigido e in memoria, supponendo che altri bundle abbiano dipendenze dal pacchetto aggiornato. Questo è il motivo per cui l'aggiornamento è necessario, dal momento che si desidera che i bundle dipendenti passino alla nuova revisione. Una volta che l'aggiornamento avviene, allora c'è solo una revisione del pacchetto aggiornato in memoria o su disco. –