Navigace

iPOJO

iPOJO (injected-POJO) je runtime servisních komponent zaměřený na zjednodušení vývoje OSGi aplikací. Nativně podporuje veškeré dynamické aspekty OSGi. iPOJO je vytvořen pro běh moderních aplikací, které se vyznačují modularitou, vyžadující adaptaci za běhu a autonomní chování. iPOJO je vyvíjen týmem kolem Apache Felix (implementace OSGi). Prvotní verze 0.8 je z roku 2008 a vznikla na univerzitě v Grenoblu (Clement Escoffier, Richard S. Hall). Aktuální verze (prosinec 2014) je 1.12.1.

Příklad iPOJO komponenty

Základní principy

Principem iPOJO je co největší oddělení funkčního od mimofunkčního kódu (dependency management, service provision, konfigurace, atd.).

Komponenta

Komponenta je centrálním konceptem iPOJO. Komponentu jako samostatně nasaditelnou jednotku (ve smyslu definice z hlavní stránky této wiki) v iPOJO představuje bundle, stejně jako v OSGi. Tím vzniká menší konflikt v terminologii, jelikož iPOJO notace (v anotacích, XML, atd.) označuje slovem Component Java třídy, poskytující a požadující služby z jiných bundlů. Tyto třídy se pak také označují za komponentové typy (component types) nebo továrny (factories).

Bundle

Bundle je svazek komponentových typů (ideálně tématicky spřízněných) nasazovaný zároveň. Z programátorského pohledu je to vlastně Java projekt, který specifikuje imporotované (požadované) a exportované (poskytované) balíky. To určuje pouze jejich viditelnost pro ostatní bundly, ne přímo poskytování služeb. Balíky pak obsahují jednotlivé factory/komponentové typy (třídy), z nichž se tvoří instance (objekty). Ty pak poskytují/požadují služby (implementovaná rozhraní/metody, resp. objekty tříd typované na tyto rozhraní) a jejich vlastnosti (properties; proměnné).

Komponentový typ

V jádru iPOJO modelu komponentový typ popisuje závislosti služeb, poskytované služby a callbacky. Tyto informace jsou uloženy v metadatech komponentového typu (třídy). Jelikož iPOJO staví na principu POJO (Plain Old Java Object; standardních Java tříd), komponentový typ v iPOJO reprezentuje třída označená jako component type (také označovaná jako factory) jedním ze tří základních způsobů - anotace přímo ve zdrojovém kódu, XML v speciálním souboru popisující iPOJO komponentové typy a nastavení (XML deskriptoru) nebo pomocí fluent API. Stejnými způsoby lze z component type vytvořit instanci. Instance komponentového typu je analogií k instanci třídy v objektovém programování.

Instance iPOJO a její kontejner

Instance jejich životní cyklus

Instance mají ke komponentovým typům (component type / factory) týž vztah, jako běžná Java instance ke třídám. Narozdíl od životního cyklu komponent (bundlů; stejný jako v OSGi) iPOJO instance mají velmi jednoduchý životní cyklus, který obsahuje pouze 2 stavy: INVALID a VALID. Po svém vytvoření může instance být validní pouze tehdy, pokud všechny její připojené handlery jsou validní. V nejzákladnějším případě to znamená, že všechny instancí požadované služby jsou dostupné. Například, instance požadující službu (a tím pádem používající dependency handler) nemůže být validní, pokud požadovaná služba není dostupná. Instance začíná a končí ve stavu INVALID (viz obr. níže).

Životní cyklus instance

Pro úspěšné spuštění instance je ovšem nutné aby všechny bundly poskytující jí služby byly ve stavu Resolved. Do něj framework převede všechny automaticky všechny takové instalované bundly. Problém nastává, pokud takový bundle závisí na dalším (a zřetězením případně dále), který není nainstalován, nebo nemůže být převeden do stavu Resolved. Tento případ končí výjimkou org.osgi.framework.BundleException: Unresolved constraint in bundle ....

Vytvoření instance lze vynutit okamžitě po přechodu komponenty (bundlu) do stavu ACTIVE atributem immediate=true anotace @Component (viz obr. níže). Vytvoření instance volá konstruktor (defaultní/prázný, pokud neexistuje jiný), čímž se v kombinaci s immediate de facto nahrazuje/duplikuje funkci anotace @Validate (viz níže). Rozdílem je, že konstruktor je volán pouze jednou (při vytvoření instance), zatímco validate callback je volán při každé validaci (spuštění).

Okamžité vytvoření instance atributem immediate

Rozhraní (kontrakt)

Rozhraní je reprezentováno poskytovanými a požadovanými službami (metodami nebo promněnými, popř.: konstantami), které se v iPOJO specifikují stejnými způsoby zápisu jako komponentové typy (anotace, XML, fluentAPI). Služba je vlastně jakékoli rozhraní, které POJO reprezentující komponentový typ implementuje. Komponentový typ tak může poskytovat více služeb. Framework automaticky hledá všechny taková rozhraní a nadtřídy každého komponentového typu při instalaci bundlu.

Interakce služeb mezi iPOJO instancemi

Model

Komponentový model iPOJO je v základu stejný jako u OSGi, jelikož iPOJO pouze vylepšuje tento framework. Jedná se o jednoduchý a rozšiřitelný (viz níže) model servisních komponent založených na POJO. Servisní komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Model představují základní možnosti iPOJO ohledně nastavení konfigurace a komunikace mezi komponentami (viz seznam anotací níže). Model lze však libovolně upravovat a rozšiřovat přidáváním vlastních anotací. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu v životním cyklu (např. PostRegistration, PostUnregistration callbacky při (od)registrování služby, nebo přechod instance na stav Valid a Invalid).

Framework

Komponentový framework je pak celé iPOJO, resp. iPOJO spojené s patřičnou implementací OSGi (viz technické detaily níže). Princip fungování závisí na 2 hlavních částech - kontejner a handler. Kontejner obklopuje obsah (implementace POJO objektů) a spravuje všechny jeho mimofunkční požadavky jako propojení s ostatními instancemi nebo zdroji, životní cyklus, atd. Kontejner je popsán v component type třídě (opět anotacemi, XML nebo API). Kontejner v iPOJO tudíž není monolitem, ale je složen z handlerů. Každý handler spravuje jeden mimofunkční požadavek a požadované hadlery jsou připojeny za běhu aplikace. Instance komponentového typu je pak validní pouze pokud všechny připojené handlery jsou validní. Handlery je možné vytvářet a nasazovat mimo jádro iPOJO, tudíž každý si může vytvořit vlastní handler a přizpůsobit si tak model iPOJO svým potřebám (viz zde). Při běhu aplikace pak iPOJO runtime kombinuje funkční (implementace instancí) a mimofunkční (uchované v konfiguraci kontejneru) aspekty aplikace, odhaluje a "vstřikuje" (inject) požadované služby spojením metadat komponenty a konfigurace instance. Následně uveřejňuje (propaguje) poskytované služby a řídí životní cyklus komponenty.

Technické detaily

iPOJO funguje na jakékoli implementaci R4.1 OSGi a také na mnoha JVM jako Oracle JRockit, JamVM, Dalvik (Android) a Mika. Požaduje pouze J2ME Fondation 1.1 JVM. Díky tomu lze aplikace používat v mobilních a jiných zařízeních.

Základem iPOJO fyzicky je iPOJO Core bundle (stáhnout).

Samotné programování pak probíhá obdobně jako při standardním vývoji v Javě. Rozdílem je jen konfigurace instancí a metadata komponent. Ty je možné zavádět třemi způsoby:

v XML deskriptoru metadata.xml v bundlu (podobně jako u OSGi) za pomoci kořenového elementu <iPojo> (příklady např. v Reference Card nebo dalších zdrojích dole na stránce)
přímo v kódu anotacemi (nejjednodušší příklad a výpis základních anotací viz níže, další ukázky stejně jako u XML deskriptoru)
přímo v kódu přes fluent API

Proč iPOJO?

OSGi Service Platform poskytuje výborný základ pro vývoj dynamicky rozšiřitelných Java aplikací. Nicméně tato síla a pružnost není zadarmo. Kromě nevýhod ve formě nových API a formátů balíků, vývojáři v OSGi musí změnit svoje uvažování, aby byli schopni vytvářet vysoce dynamické aplikace. Rané pokusy, jako Service Binder a Service Tracker, se snažily o zmírnění některých z těchto problémů stejně jako některé aktuálnější příklady jako Declarative Services a Spring Dynamic Modules. iPOJO je další takovou snahou v této oblasti. Je to service-oriented komponentový model vytvořený přímo pro OSGi Service Platform.

Hlavní účel na pozadí iPOJO je dvojí. Prvním jeho cílem je zjednodušení vývoje v OSGi na naprosto nezbytné minimum. To znamená, že poskytování a používání služeb a vyrovnávání se s dynamizmem by mělo vyžadovat co nejméně snahy na straně vývojáře. Druhým cílem je posunout se za hranici podpory zákadních OSGi mechanismů a pokusit se více nenuceně zahrnout pokročilé atributy včetně konfigurace komponent, synchronizace a kompozice.

Vytvoření aplikace prostřednictvím služeb v samotném OSGi bez dalších frameworků je náročné, protože OSGi API je komplexní a je třeba určité úrovně znalosti o vnitřních mechanismech, aby se předešlo problémům se synchronizací. iPOJO poskytuje velmi jednoduchý vývojový model, což ukazuje následují základní ilustrační příklad (bez vnitřní implementace) pro

poskytnutí služby

    @Component
    @Provides
    public class MyServiceImplementation implements MyService {
        //....
    }

požadování služby:

    @Component
    public class MyServiceConsumer {
        @Requires
        private MyService myservice;
        // stačí použít požadovanou službu jako obyčejnou proměnnou
    }

Pozn.: Pro úplnost by bylo třeba přidat nad obě třídy ještě anotaci @Instantiate, nebo vytvořit instanci jiným způsobem.

Podpora OSGi aplikací není jedinou výhodou iPOJO pro zjednodušení vývoje sofistikovaných aplikací. Podporuje také konfiguraci komponent pomocí Configuration Admin, posílání a přijímání událostí pomocí Event Admin, vzdálenou konfiguraci pomocí JMX a další.

Další výhodou iPOJO je jeho flexibilita. Poskytuje totiž mechanismy pro rozšíření sebe samotného, které nevyžadují úpravy jádra. iPOJO se dá tudíž adaptovat pro vlastní potřeby pomocí vlastních handlerů (viz výše Základní principy)

Anotace

Anotace jsou jedním ze způsobů zápisu metadat komponent a konfigurace instancí v iPOJO. Anotace jsou automaticky zpracovány iPOJO manipulátorem a nemusí být nasazeny při runtimu. Zde jsou vyjmenovány základní anotace iPOJO obsažené v knihovně org.apache.felix.ipojo.annotations a jejich význam, cíl (část kódu, s kterou jsou asociovány, resp. nad kterou se používají) a atributy. Po stažení stačí knihovnu přidat do build path / class path / dependencies. Podrobnější informace nejen o atributech na stránce pod odkazem dole pod seznamem.

@Component
- význam: definuje, že třída je komponentovým typem (component type / factory)
- cíl: třída implementující komponentový typ
- atributy: name, immediate, architecture, propagation, managedservice, factoryMethod, publicFactory
- pokud je použito stejné jméno komponentového typu v anotaci jako v XML souboru, XML definice má přednost, ale během manipulace se ukáže varování
@Provides
- význam: určuje, že komponenta poskytuje službu
- cíl: třída implementující komponentový typ
- atributy: specifications, strategy, properties
@Requires
- význam: signalizuje závislost na službě jiné komponenty
- cíl: proměnná nebo parametr konstruktoru
- atributy: filter, optional, id, nullable, defaultimplementation, exception, policy, comparator, from, specification, proxy, timeout
@ServiceProperty
- význam: definuje vlastnost služby
- cíl: proměnná
- atributy: name, value, mandatory
@ServiceController
- význam: kontrola expozice (vystavení?) služby
- cíl: proměnná (Boolean)
- atributy: value, specification
@Property
- význam: definuje vlastnost
- cíl: proměnná, metoda, parametr konstruktoru
- atributy: name, value, mandatory
@Updated
- význam: určuje metodu volanou při dokončení rekonfigurace
- cíl: metoda (se slovníkem jako vstupním argumentem)
@Bind
- význam: určuje metodu pro binding
- cíl: metoda
- atributy: id, specification, aggregate, optional, filter, policy, comparator, from
@Unbind
- význam: určuje metodu pro unbinding
- cíl: metoda
- atributy: id, specification, aggregate, optional, filter, policy, comparator, from
@Modified
- význam: určuje metodu volanou, když je aktualizována bound (vázaná) služba
- cíl: metoda
- atributy: id, specification, aggregate, optional, filter, policy, comparator, from
@Validate
- význam: určuje callback vyvolaný při přechodu instance do stavu Valid životního cyklu
- cíl: metoda
@Invalidate
- význam: určuje callback vyvolaný při přechodu instance do stavu Invalid životního cyklu
- cíl: metoda
@PostRegistration
- význam: určuje callback vyvolaný po registraci služby; callback musí mít hlavičku public void name(ServiceReference ref)
- cíl: metoda
@PostUnregistration
- význam: určuje callback vyvolaný po odregistrování služby; callback musí mít hlavičku public void name(ServiceReference ref)
- cíl: metoda
@Instantiate
- význam: deklaruje jednoduchou instanci (ekvivalentní k <instance component="..."></instance> v XML souboru)
- cíl: třída
- atributy: name
- nepodporuje konfiguraci, pojmenování a má pouze globální rozsah platnosti (tudíž nelze použít kompozici)
- lepší je pro vytváření instancí použít XML descriptor:
```
<instance component="ipojo.example.hello.impl.HelloImpl"/>
<instance component="AnnotedHelloClient"/>
```

Další anotace mohou být v externích handlerech, např. temporální závislosti nebo možnost vystavení instance jako JMX MBean. K použití externích anotací je nutné pouze přidat je do build path. Více informací o anotacích např. zde.

iPOJO Reference Card pak ukazuje paralelně použití některých základních principů jak anotacemi, tak XML deskriptorem + několik dalších věcí jako Extender Pattern a Whiteboard Pattern.

Rozdíly v implementaci oproti OSGi

Popisované rozdíly jsou demostrovány na implementaci iPOJO aplikací pomocí Maven a anotací. Pro další možnosti implementace (XML deskriptor, fluentAPI, Ant, atd.) možno konzultovat hlavní stránku iPOJO na Apache Felix nebo další zdroje uvedené na této wiki.

Nahrazení manifestu

Atributy bundlů jako jméno, symbolické jméno, verze a další vedených v OSGi v manifestu je možné nahradit obdobnými elementy v Mavenu (pom.xml). Obdobně importované balíky jsou nahrazeny dependencies a exportované balíky pomocí elementu <Export-Package> viz následující příklad:

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Export-Package>
                            cz.zcu.kiv.ppicha.ipojo.parkoviste.brana
                        </Export-Package>
                    </instructions>
                </configuration>
            </plugin>
        ...

Komponentový typ

Komponentový typ (factory) stačí označit anotací @Component a v případě instancování i @Instantiate nad hlavičkou třídy. Obě anotací disponují atributem name pro pojmenování a dalšími možnostmi. Máli být instancování provedeno okamžitě po validaci, použijte atribut immediate=true anotace @Component (u komponentových typů neposkytujících služby je tato hodnota defaultní). Lze také vytvořit komponentový typ, která bude mít jedinou instanci (singleton) použitím atributu publicFactory=false opět na anotaci @Component. Anotacemi nelze vytvořit kompozity a využívat některých dalších možností iPOJO (viz výše).

Služby

Poskytovanou služby stačí identifikovat anotací @Provides rovněž nad hlavičkou třídy. iPOJO automaticky najde všechny implementovaná rozhraní a rodičovské třídy a zpřístupní je. Požadovanou službu lze identifikovat anotací @Requires nad patřičnou proměnou, nebo @Bind nad metodou. Možné je využít specifikace a filtry (atributy anotace) pro upřesnění parametrů požadovaných služeb / metod / dat. U @Requires je navíc kombinací atributů optional=true a defaultImplementation specifikovat např. lokální implementaci (ve stejném bundlu) služby, která se má použít v případě, že nebude nalezen její jiný poskytovatel. Služby není nutné registrovat, ani jinak přidávat do kontextu, iPOJO to zařídí automaticky.

Vlastnosti

Možné je též specifikovat vlastnosti služeb anotacemi @Property, @ServiceProperty a jejich atributy. Zajímavá je pak anotace @StaticServiceProperty pro statickou vlastnost všech služeb instance, užívaná v atributu properties anotace @Provides. Jedná se o další možnost rozlišování různých komponentových typů poskytujících stejné služby (např. implementujících stejné rozhraní).

Activator

Místo aktivátoru používaného v OSGi stačí použít callbacky identifikované anotacemi @Validate (ekvivalent start()), @Invalidate (ekvivalent stop()), @PostRegistration, @PostUnregistration and libovolně pojmenovanou metodou.

Události

Použití EventHandler nebo Listener obejktů a jejich registrace jako samostatných služeb pro správu událostí v OSGi je v iPOJO opět značně zjednodušeno. Je ale nutno přilinkovat k bundlům externí handler Event Admin Handler a balík org.osgi.service.event a dále na instanci Felix nasadit EventAdminHandler a EventAdmin bundly (vše dostupné na Maven repository). Poté stačí pro posílání událostí použít anotaci @Publishes s patřičnými atributy nad proměnou typu Publisher, nad kterou se poté volá jedno z metod pro posílání zpráv:

send(Dictionary d) pro obecné události,
sendData(Object o) pro posílání dat.

Defaultní způsob zasílání událostí je asynchronní. Názorná ukázka zasílání událostí:

    @Publishes(name="vysilac_parkoviste_mista", synchronous=true, topics="parkoviste/mista")
    Publisher vysilac_mista;

    @Publishes(name="vysilac_parkoviste_plne", synchronous=true, topics="parkoviste/plne")
    Publisher vysilac_plne;
    ...
    private void posliZpravu() {
        if (volnaMista == 0) {
	    vysilac_plne.send(new Properties());
        }
        Dictionary<Object, Object> properties = new Properties();
        properties.put("volnaMista", volnaMista);
        vysilac_mista.send(properties);
    }

Příjem událostí je realizován použitím anotace @Subscriber a jejími atributy přímo nad obslužnou metodou libovolného jména. Atributy lze specifikovat i která data ze zprávy potřebujeme, pokud jí nechceme zpracovávat celou. Opět následuje názorný příklad:

    @Subscriber(name="prijmac_tabule_plne", topics="parkoviste/plne")
    public void prijmoutPlno(Event e) {
        println("Parkoviste plne!");
    }

    @Subscriber(name="prijmac_tabule_mista", topics="parkoviste/mista", dataKey="volnaMista", dataType="java.lang.Integer")
    public void prijmoutMista(Integer mista) {
        println("Zbyva mist : " + mista);
    }

Celý koncept práce s událostmi ilustruje obrázek níže. Pro více informací o Event Admin Handleru viz zde.

Zasílání a zpracování událostí v iPOJO

Kompozice

Zajímavou vlastností iPOJO je možnost vytváření kompozic, tj. aplikací agregujících několik bundlů a schopných určit rozsah viditelnosti (propagace) jejich služeb. Prakticky řečeno lze nastavit, které služby budou dostupné jen uvnitř kompozice a které budou uveřejněny i pro bundly vnější vzhledem ke kompozici (více zde). V příkladu na obrázku je služba Dictionary Service dostupná pouze uvnitř kompozice, zatímco služba komponenty Checker je propagována vně kompozice.

Příklad kompozice

Kompozice je možné definovat pouze v XML deskriptoru (element composite), nikoli pomocí anotací. Možnosti definice metadat je ale možné kombinovat, takže není problém používat anotace na vše ostatní a pouze kompozici definovat pomocí XML. S kompozicí se dále zachází podobně jako s komponentovým typem ve smyslu instancování a poskytování služeb.

Dále je pak možné skládat kompozice kompozic a dalších bundlů a tím dosáhnout hierarchické struktury celé agragace, na jejíž každé úrovni je možné omezit propagování služeb za její hranici. Příklad na obrázku ilustruje takovou situaci.

Příklad hierarchické kompozice

Možnosti customizace

Možností vlastních úprav komponentového modelu iPOJO je definování vlastních handlerů (včetně vlastních anotací). Podrobné informace o tomto tématu naleznete zde. Handler komunikuje s kontejnerem komponenty, POJO, ostatními komponentami, službami, bundly, OSGi frameworkem, atd. Prvním krokem k vytvoření vlastního handleru je implementace Java třídy rozšiřující abstraktní třídu PrimitiveHandler ze základního balíku iPOJO. Dále nad hlavičku této třídy je nutné přidat anotaci @Handler s atributy pro jméno (název anotace, kterou se bude handler označovat) a jmený prostor (balík handleru). Handler funguje (téměř) jako jakýoli komponentový typ ve smyslu, že používá další handlery, požaduje a poskytuje služby, atd. Dalším krokem vytvoření vlastního handleru je implementace/překrytí metod abstraktní třídy. Obrázek znánzorňuje životní cyklus handleru pro ilustraci funkcí metod.

Životní cyklus handleru

Metody abstraktní třídy PrimitiveHandler, které je třeba překrýt:

configure()
- volána po inicializaci handleru metodou initializeComponentFactory()
- kontroluje handler a a konfiguruje vlastnosti (properties) specifické pro instanci
start()
- volána po konfiguraci handleru
- spouští handler, obsahuje aktivační kód
- stav po handleru po startu je active, pokud jsou ve stejném stavu všechny jím využívané handlery
- následně handler přechází do stavu valid nebo invalid v závislosti na stavech jím využívaných handlerů
stop()
- volána při zastavování handleru (před likvidací jeho instance)
- zastavuje handler, obsahuje deaktivační kód
- volá se po zastavení (ne zničení) instance komponentovho typu, která handler využívá, tudíž pokud bude restartována bude potřebovat opět stejnou instanci handleru

Metody abstraktní třídy PrimitiveHandler, které je možné překrýt/rozšířit/využít:

initializeComponentFactory()
- volána, když framework zjistí použití handleru
- kontroluje validitu popisu komponentového typu, aby nebyly spuštěny nevalidní factories
setValidity()
- nastavuje stav na valid nebo invalid

Handler je pak možné používat přidáním v XML deskriptoru (viz odkaz výše) nebo pomocí definování anotace. Anotaci je možné definovat vytvořením Java souboru s následující hlavičkou:

    public @interface JmenoHandleru {

Zde je podle potřeby možné definovat atributy anitace formou atributů Java třídy. Poté lze handler snadno používat v komponentových typech použitím jeho anotace (popř. s atributy). Pro funkčnost je samozřejmě nutné nasadit bundle s handlerem před spuštěním aplikace, která ho používá. Návody na zpracování konfigurace handleru a instance, interakce s iPOJO frameworkem a další pokročilé techniky včetně 2 ilustračních příkladů, viz odkaz výše.

Další znaky iPOJO

iPOJO aplikace podporují dynamické adaptace a vykazují autonomní chování
použití v různých zařízeních a oblastech (mobilní zařízení, domácí brány, JEE servery)
staví koncept služeb jako top-level, čímž poskytuje lepší znovupoužitelnost, dovoluje nahrazování jedné implementace za jinou a správu dynamizmu
malý "footprint" - iPOJO Core má pouze cca 550KB

iPOJO používají

podporují: akquinet, Grenoble University, Bull (viz zde)
success stories: Schneider Electric, Ubidreams, JOnAS (viz zde)

Praktické příklady a tutoriály

Příklady na vyzkoušení jsou k nalezení na internetu a zahrnují aplikace

prostý tutorial na příklady s prodavači občerstvení
Spell simulující jednoduchý spellchecker
Hello Wrold příklad propojení technologie iPOJO a Maven
příklad integrace iPOJO a Vaadin

Další zdroje

iPOJO API
Apache Felix iPOJO FAQ
Describing your iPOJO components
přehled verzí iPOJO
slajdy přednášky od Richarda S. Halla iPOJO: The Simple Life

Praktická část

Oba příklady jsou vypracovány s maximální možnou podobností (až na několik drobných změn) jako jejich protějšky z kapitoly o OSGi pro snadné porovnání obou implementací. Kroky převodu implementačních principů z OSGi na iPOJO v příkladech použité jsou z většiny popsané v kapitole Rozdíly v implementaci oproti OSGi (viz výše). Oba příklady využívají anotace a Maven.

Felix

Oba níže uvedené příklady obsahují instanci Felix frameworku konfigurovanou pro své potřeby pomocí Maven.

Instalace: stačí spustit příkaz mvn install na pom.xml v podsložce Felix*.
Spuštění: ze složky target přes příkazovou řádku spustit java -jar bin/felix.jar.
Základní příkazy:
- výpis bundlů
  - lb
- výpis instancí
  - instances
- přidání bundlů
  - install file:cesta_k_bundlu/bundle.jar
- spuštění bundlů
  - start id_bundlu (může být i více oddělených mezerou)
- zastavení bundlů
  - stop id_bundlu (může být i více oddělených mezerou)
- odstranění bundlů
  - uninstall id_bundlu
- nápověda
  - help (příkaz)

Překlad příkladů

hromadně pro všechny části - přes mvn install na pom.xml v kořenové složce (přeloží pouze podprojekty bundlů, ne Felix!)
postupně - přes mvn install na pom.xml v dané podsložce
výsledné .jar soubory vždy ve složkách target v jednotlivých podsložkách

Příklad Message Printer

Attach:MessagePrinterIpojo.zip.

Příklad Parkoviště

Attach:ParkovisteIpojo.zip.

Hlavní menu

Nástroje

UvodDoKomponent / IPOJO

Navigace

iPOJO

Základní principy

Komponenta

Bundle

Komponentový typ

Instance jejich životní cyklus

Rozhraní (kontrakt)

Model

Framework

Technické detaily

Proč iPOJO?

Anotace

Rozdíly v implementaci oproti OSGi

Nahrazení manifestu

Komponentový typ

Služby

Vlastnosti

Activator

Události

Kompozice

Možnosti customizace

Další znaky iPOJO

iPOJO používají

Praktické příklady a tutoriály

Další zdroje

Praktická část

Felix

Překlad příkladů

Příklad Message Printer

Příklad Parkoviště