Plugin-moduler og bunter

Mekanismene for å håndtere plugin-moduler implementeres ved hjelp av OSGi-rammeverket. Fra et slikt perspektiv er en plugin-modul det samme som en OSGi-bunt. Bunten og de tilknyttede klassene angir og implementerer prosessen med å laste inn Java-klasser, foreta nødvendig styring og buntlevetid. I det følgende bruker vi termene plugin-modul og bunt synonymt, med mindre vi beskriver en bestemt klasse i rammeverket.

Plugin

Plugin-klassen representerer en plugin-modul som kjører i plattformen. Det er en praktisk sted å sentralisere levetidsaspekter og overordnet semantikk for en plugin-modul. En plugin-modul kan implementere spesialiserte funksjoner for aspekter som gjelder start og stopp i levetiden. Alle levetidsmetodene omfatter en referanse til en BundleContext, som kan oppgi ytterligere informasjon.

La oss se nærmere på start-delen av levetiden. Vi har allerede sett at informasjon om en plugin-modul kan hentes fra plugin-manifestfilen uten kjøring av plugin-koden. Vanligvis vil en brukerhandling i arbeidsbenken utløse en rekke hendelser som krever at en plugin-modul startes. Fra et implementeringsperspektiv startes ikke en plugin-modul før det skal lastes inn en klasse i plugin-modulen.

Start-metoden har vært et praktisk sted å implementere initialiserings- og registreringsfunksjonalitet for en plugin-modul. Det er imidlertid viktig å være klar over at plugin-modulen kan startes i mange ulike situasjoner. Noe så enkelt som å hente et ikon for å dekorere et objekt, kan føre til at plugin-klassene lastes inn og dermed starter plugin-modulen. Hvis du er altfor ivrig med initialiseringen, kan plugin-modulens kode og data bli lastet inn lenge før det er nødvendig. Det er derfor viktig å se nærmere på plugin-modulens initialiseringsoppgaver og se om det finnes andre alternativer for å utføre initialisering ved oppstart.

Buntkontekst

Levetidsstyring er knutepunktet mellom terminologien for OSGi-"bunter" og plattformens "plugin-moduler". Når plugin-modulen startes, får den en referanse til en BundleContext der informasjon som er knyttet til plugin-modulen, kan hentes. BundleContext kan også brukes til å finne ut hvilke andre bunter/plugin-moduler som finnes i systemet.

BundleContext.getBundles() kan brukes til å hente en matrise over alle bunter i systemet. Du kan registrere lytterfunksjoner for BundleEvent slik at plugin-modulen oppdager når det oppstår en endring i levetidsstatusen til en annen bunt. Du finner mer informasjon i Javadoc for BundleContext og BundleEvent.

Før versjon 3.0 brukte man et plugin-register (IPluginRegistry) med liknende informasjon. Det var for eksempel mulig å opprette spørringer etter plugin-deskriptorer for alle plugin-moduler i systemet. Dette registeret er foreldet. Bruk heller BundleContext til dette formålet. Plattformregisteret brukes nå utelukkende for å få informasjon om utvidelser og utvidelsespunkter.

Buntaktivator

BundleActivator-grensesnittet definerer start- og stoppfunksjonaliteten som implementeres i Plugin. Selv om Plugin-klassen er et praktisk sted for implementering av denne funksjonen, står plugin-utviklere helt fritt til å implementere grensesnittet for BundleActivator i enhver klasse som er hensiktsmessig for plugin-modulens design. Plugin-modulen trenger faktisk ikke å implementere dette grensesnittet i det hele tatt så lenge det ikke foreligger spesifikke behov for levetidsstyring.

Bunter

Under hver plugin-modul ligger en OSGi-bunt som styres av rammeverket. Bunten er OSGi-enheten for modularitet. En bunt er egentlig bare en samling med filer (ressurser og kode) som er installert i plattformen. Hver bunt har sitt eget Java-klasseinnlastingsprogram og inneholder protokoll for å starte, stoppe og avinstallere seg selv. Fra Eclipse-plattformens perspektiv er en Bundle bare en implementeringsklasse. Plugin-utviklere utvider ikke buntklassen, men bruker Plugin eller andre BundleActivator-implementeringer som representerer plugin-modulen.