Hvordan skriver man en WSO2 brugerdefineret OSGi-komponent?

Vil du lære, hvordan du udvikler en OSGi-tjeneste? Her udvikler vi en enkel applikation med OSGi og tester den i WSO2 Carbon-platform, som er en modulopbygget, letvægts, OSGi-baseret serverudviklingsramme. Har du allerede forvirret, hvad der er OSGi? Bare rolig, jeg vil snart forklare det. Læsere forventes at have tidligere erfaring med Java-udvikling og Apache Maven. Lad os dykke ind :)

Først og fremmest, før jeg sætter fingrene på tastaturet og begynder at kode, så lad mig forklare, hvad der er den rigtige idé bag brugen af ​​OSGi i applikationer. OSGi (Open Services Gateway-initiativ) er en komponentramme for Java, der definerer en arkitektur til modulær applikationsudvikling. Det er, det giver os fleksibiliteten til eksternt at installere, starte, stoppe, opdatere og afinstallere applikationer, der kommer i form af bundter til distribution uden at kræve en genstart. Super cool ikke? Der er forskellige OSGi-containerimplementeringer såsom Equinox, Knopflerfish og Felix. I denne tutorial som OSGi-container bruger vi Eclipse OSGi-containerimplementering, Equinox (Eclipse Equinox bruges som OSGi-runtime i WSO2 Carbon Platform). Stadig ikke klar? Bare rolig. Fortsæt med at læse, du vil forstå det snart. Lad os gå videre til kodning.

I denne artikel opretter jeg først to Maven-projekter; osgiproducer og osgiconsumer. I osgiproducer-projektet skrives OSGi-tjenesten, og i osgiconsumer-projektet forbruges den tidligere skrevne OSGi-service.

Lad os få fat på at oprette osgiproducer-projektet som den første fase ved at følge nedenstående enkle trin.

1. pom.xml



     4.0.0 

    
         org.wso2 
         WSO2 
         1 
    

     com.example.osgiproducer 
     osgiproducer 
     1.0.0-SNAPSHOT 

     bundt 

    
        
            
                 org.apache.felix 
                 Maven-scr-plugin 
                 1.9.0 
            
            
                 org.apache.felix 
                 Maven-bundle-plugin 
                 sand 
                
                    
                         $ {project.artifactId} 
                         $ {project.artifactId} 
                         com.example.osgiproducer.package01.internal, 
                        
                            org.osgi.framework,
                            org.osgi.service.component,
                        
                        
                            ! Com.example.osgiproducer.package01.internal.ProducerComponent,
                            com.example.osgiproducer.package01 *;. versionen = "1.0.0-SNAPSHOT"
                        
                    
                
            
        
    

    
        
             org.eclipse.osgi 
             org.eclipse.osgi 
             3.9.1.v20130814-1242 
        
        
             org.eclipse.osgi 
             org.eclipse.osgi.services 
             3.3.100.v20130513-1956 
        
    
    

Lad os se nærmere på de førnævnte POM-konfigurationer.

 bundt 

Det er her vi skal konfigurere maven til at opbygge et OSGi-bundt ved at definere emballageelementet som bundt. Bundle er en JAR med yderligere manifestindgange, der bruges af OSGi-rammen til at identificere tjenester.


    ! Com.example.osgiproducer.package01.internal.ProducerComponent,
    com.example.osgiproducer.package01 *;. versionen = "1.0.0-SNAPSHOT"

repræsenterer listen over pakker til det bundt, der skal eksporteres. Disse pakker kopieres til det resulterende bundt JAR. Vi kan ekskludere pakker, som vi ikke ønsker at importere, ved hjælp af negation (!). Bemærk, at det er obligatorisk at bruge de fuldt kvalificerede navne, når du ringer til de relevante klasser og pakker. Formålet med at eksportere pakker vil blive forklaret senere, når POM-konfigurationer tilføjes til osgiconsumer-projektet.

En anden vigtig kendsgerning, jeg skal nævne, er .

 com.example.osgiproducer.package01.internal, 

Her har vi tilføjet det fuldt kvalificerede navn på den pakke, hvor servicekomponenten er skrevet. Det er en almindelig praksis på WSO2 at have servicekomponenten i en underpakke kaldet intern og ikke at få den serviceklasse eksporteret af pakken.


    org.osgi.framework,
    org.osgi.service.component,

Instruktion angiver de pakker, der kræves af bundtets indeholdte pakker.

2. Producentgrænseflade

pakke com.example.osgiproducer.package01;

offentlig interface Producent {

    tom produkt (strengnavn);
}

3. ProducerImpl-klasse

pakke com.example.osgiproducer.package01;

import java.util.logging.Logger;

Producent af offentlig klasse Impl implementerer Producer {

    privat statisk endelig Logger LOGGER = Logger.getLogger (ProducerImpl.class.getName ());

    @Override
    offentlig ugyldig produktion (strengnavn) {
        
        LOGGER.info ("Produceret med succes:" + navn);
      
    }
}

4. ProducerComponent klasse

pakke com.example.osgiproducer.package01.internal;

import com.example.osgiproducer.package01.Producer;
import com.example.osgiproducer.package01.ProducerImpl;
import org.osgi.framework.BundleContext;
import org.osgi.service.component.annotations.Activate;
import org.osgi.service.component.annotations.Component;

@Component (name = "com.example.osgiproducer.package01.internal.ProducerComponent",
        øjeblikkelig = sand)
ProducentKomponent af offentlig klasse {

    @Activate
    beskyttet tomrumsaktivering (BundleContext bundleContext) {

        bundleContext.registerService (Producer.class, new ProducerImpl (), null);
    }
}

Bemærk, at som tidligere nævnt skal ProducerComponent-klassen være i en pakke, der er navngivet som intern.

Projektmappestrukturen vil se sådan ud,

Endelig bygger projektet ved at påberope maven-kommandoen “mvn clean install”, og du får den oprettede osgiproducer-1.0.0.-SNAPSHOT.jar i målmappen.

Lad os nu oprette osgiconsumer-projekt ved at følge nedenstående trin.

  1. pom-fil


     4.0.0 

    
         org.wso2 
         WSO2 
         1 
    

     com.example.osgiconsumer 
     osgiconsumer 
     1.0.0-SNAPSHOT 

     bundt 

    
        
            
                 org.apache.felix 
                 Maven-scr-plugin 
                 1.9.0 
            
            
                 org.apache.felix 
                 Maven-bundle-plugin 
                 sand 
                
                    
                         $ {project.artifactId} 
                         $ {project.artifactId} 
                         com.example.osgiconsumer.package01.internal, 
                        
                            org.osgi.framework,
                            org.osgi.service.component,
                            com.example.osgiproducer.package01 *;. versionen = "1.0.0-SNAPSHOT"
                        
                        
                            ! Com.example.osgiconsumer.package01.internal.ConsumerComponent,
                            com.example.osgiconsumer.package01 *;. versionen = "1.0.0-SNAPSHOT"
                        
                    
                
            
        
    

    
        
             org.eclipse.osgi 
             org.eclipse.osgi 
             3.9.1.v20130814-1242 
        
        
             org.eclipse.osgi 
             org.eclipse.osgi.services 
             3.3.100.v20130513-1956 
        
        
             com.example.osgiproducer 
             osgiproducer 
             1.0.0-SNAPSHOT 
             billede 
        
    


Jeg vil ikke forklare om POM-konfigurationer igen, men der er en kendsgerning, jeg skal påpege.


    org.osgi.framework,
    org.osgi.service.component,
    com.example.osgiproducer.package01 *;. versionen = "1.0.0-SNAPSHOT"

Bemærk, at vi er nødt til at importere den pakke, vi har eksporteret i osgiproducer-projektet, og jeg vil igen understrege det faktum, at det skal kaldes ved hjælp af det fuldt kvalificerede navn.

2. ConsumerComponent-klasse

pakke com.example.osgiconsumer.package01.internet;

import com.example.osgiproducer.package01.Producer;
import org.osgi.framework.BundleContext;
import org.osgi.service.component.annotations.Activate;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.osgi.service.component.annotations.ReferenceCardinality;
import org.osgi.service.component.annotations.ReferencePolicy;


@Component (name = "com.example.osgiconsumer.package01.ConsumerComponent",
        øjeblikkelig = sand)
offentlig klasse ConsumerComponent {
    Producent producent = null;

    @Activate
    beskyttet tomrumsaktivering (BundleContext bundleContext) {
        producer.produce ("producentkomponent");
    }

    @Reference (navn = "producerService", service = Producer.class,
                cardinality = ReferenceCardinality.MANDATORY, policy = ReferencePolicy.DYNAMIC, unbind = "unbindService")
    beskyttet void registerService (Producent producent) {
        denne.producer = producent;
    }

    beskyttet tomrum unbindService (Producent producent) {

    }
}

Bemærk, at ConsumerComponent-klassen er inde i den interne underpakke.

Projektmappestrukturen vil se sådan ud,

Byg projektet, så får du følgende jarfil.

Lad os nu teste den OSGi-tjeneste, vi har skrevet. Som nævnt i begyndelsen af ​​denne artikel tester vi vores kode i WSO2 Carbon-platformen.

Klon https://github.com/wso2/carbon-kernel. Kassen til afdeling 4.4.x og opbyg projektet ved hjælp af kommandoen “mvn clean install”.

Gå derefter til projektplacering kulstofkerne -> distribution -> produkt -> moduler -> distribution -> mål. Du vil se en binær pakke (ZIP-fil) inde i målmappen. Uddrag denne zip til et foretrukket sted. Fra det tidspunkt, jeg skriver denne artikel, bruger jeg wso2carbon-4.4.18-SNAPSHOT version. Jeg vil henvise til det som (bibliotek, hvor du installerede produktdistributionen).

Gå til -> depot -> komponenter -> dropins. Kopier de 2 oprettede JAR-filer til dropins-mappen.

Nu er vi alle klar til at teste, om vores OSGi-service fungerer korrekt. Først skal vi starte serveren og derefter kontrollere, om de 2 OSGi-servicepakker er aktiveret. Til dette skal vi starte serveren i OSGi-konsoltilstand.

Gå til -> bin bibliotek, og åbn en kommandoprompt. Udfør en af ​​følgende kommandoer:

  1. For Windows-bruger:

wso2server.bat --run -DosgiConsole

2. For Linux-bruger:

sh wso2server.sh -DosgiConsole

Nu vil serverens opstartlogger blive udskrevet. Når serverstart er afsluttet, skal du kigge efter følgende logmeddelelse fremhævet på billedet.

Tryk på enter-knappen, når serveren er færdig med opstart. Så får du osgi-konsollen. Udfør kommandoen “ss”. Derefter får du et overblik over alle OSGi-bundter, der er tilgængelige med deres nuværende tilstande og bund-id'er svarende til nedenstående billede.

Gå igennem listen, så ser du de 2 JAR-filer, vi kopierede til dropins-mappen med staten som Aktiv.

Udfør kommandoen “b ” for at få information om pakken inklusive de registrerede og brugte tjenester.

Endelig er vi nået til slutningen af ​​denne tutorial. Forhåbentlig har denne tutorial givet en start på, hvordan man bruger OSGi.

Se følgende links for kildekoden.

Så nu er det tid til at komme derude og skrive nogle OSGi-tjenester!