Přeskočit na hlavní obsah

Informace o WebBeans

O víkendu jsem shlédl video, ve kterém Gavin King přednášel o WebBeans. Z daného videa mám vcelku dobrý pocit a pokusím se zjednodušeně sepsat, co v přednášce bylo a jak asi bude vypadat psaní takových Web Beans.

Web Beans jsou novou specifikací, která se objeví v Java EE 6. Mezi hlavní účel patří zjednodušení vývoje webových aplikací. Samotné Web Beans jsou inspirovány (kopie) webového frameworku Seam. Jelikož je autorem jeden a tentýž člověk (Gavin King), je vcelku jasné, že lidé, kteří znají Seam budou na Web Beans přecházet stejně jednoduše jako třeba v případě Hibernate -> JPA.

Takže, co například Web Beans poskytují a nabízejí:

  • možnost psát komponenty jako Stateful EJB, které se anotací vystaví jako Web Beans se všemi vlastnostmi Stateful EJB

  • dependency injection, jednoduché vstříknutí do JSF stránek; tak jako v Seamu

  • konverzace

  • ovládání persistence context, která může např. řešit lazy loading

  • integrace s JSF, Servlety či JPA

  • JSF backing beana může být vystavena jako Web Beana

  • atd.


Nikoho asi nepřekvapí, že samotné Web Beans jsou řízeny pomocí anotací. Samozřejmě opět existuje možnost používat xml, ale myslím, že tato volba bude zřídkakdy využívána a nejsem si jist, že všechny možnosti budou v xml obsaženy.

Jak tedy takové Web Beans vypadají? Příkladem může být jednoduchá komponenta:
@Component
public class Komponenta {
public String pozdrav(String jmeno) {
return "Ahoj " + jmeno;
}
}

Samotnou anotací @Component označujeme, že se jedná o Web Bean komponentu. Kontejner nám takovouto třídu inicializuje jako Web Beanu. Nic převratného.


Dependency Injection

Při psaní definování závislosti mezi jednotlivými komponenty můžeme použít několik možností:
@Component
public class Printer {
@Current Komponenta komponenta;

public void pozdrav() {
System.out.println(komponenta.pozdrav("Ales"));
}
}

Další možností, jak definovat závislost je např:
@Component
public class Printer {
private Komponenta komponenta;

public Printer(Komponenta komponenta) {
this.komponenta = komponenta;
}

public void pozdrav() {
System.out.println(komponenta.pozdrav("Ales"));
}
}

Gavin tento způsob názývá "constructor injection" :)

Aby toho nebylo málo, máme zde další možnost nazvanou "initializer injection":
@Component
public class Printer {
private Komponenta komponenta;

@Initializer
initKomponent(Komponenta komponenta) {
this.komponenta = komponenta;
}
}


A nyní jednoduché vstříknutí do JSF stránky:


Další věcí, která stojí za zmínku je definování "binding type". Jde o to, že mohu vzít komponentu, tu podědit a při stríknutí závislosti chtít podědenou komponentu. No raději to předvedu :)

Definice vlastniho "binding type":
@BindingType
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER}}
public @interface Casual{}

Nyní již stači napsat vlastní komponentu dědicí moji "komponenta".
@Casual
@Component
public class Cau extends Komponenta {
public String pozdrav(String jmeno) {
return "cau " + jmeno;
}
}


A nyní již vstříknu vlastní komponentu do Printeru.
@Component
public class Printer {
@Casual Komponenta komponenta;

public void pozdrav() {
System.out.println(komponenta.pozdrav("Ales"));
}
}

Výsledkem bude: "Cau Ales".


Věcí, které Gavin King představil je opravdu hodně. Já zde ukážu poslední věc, která je jistě neméně zajímavá.

Nazval bych to "zástupnými anotacemi". Jak jsem na začátku psal, Web Beans jsou řízeny pomocí anotací, což ovšem může vyvolat určité rozpaky ve chvílích, kdy samotná Web Beana bude obsahovat hromadu anotací, které se často opakují.

Představme si, že máme takovouto Web Beanu:
@Component
@Transactional
@Production
@Secure
public class Komponenta {}

Výčet anotací může být i delší, což mě trochu děsí :)

Je však možné použít následující:
@Secure
@Transactional
@Named
@Production
@Stereotype
@Retention(RUNTIME)
@Target(TYPE)
public @interface Action {}

A nyní již použít:
@Action
public class Komponenta {}



Alespoň že tak :)

Všem, kteří se alespoň trochu zajímají o nové specifikace v oblasti J2EE by si měli dané video prohlédnout.
Já osobně jsem si alespoň udělal lepší obrázek o tom, jak vlastně WebBeans budou vypadat.

Zatím musím uznat, že jsem nadmíru spokojen. Pokud bude vše tak, jak Gavin King ukazuje, asi pošlu jeho Seam do věčných lovisť :) Nenarazil jsem v podstatě na nic podstatného, co by Seam měl a WebBeans nikoli. Zatím to vypadá na pravý opak.

Komentáře

  1. Ten preklad injection je opravdu hrozny... Jinak pekny clanek

    OdpovědětVymazat
  2. neni binding type obslehnute z google guice? :)

    OdpovědětVymazat
  3. Ano je :)
    Dokonce i nakonci jako studijni material je prave uveden Google Guice, z ktereho se brala inspirace, stejne jako ze zminovaneho Seamu, z ktereho vychazi cely koncept.

    OdpovědětVymazat
  4. [...] se zabývat úvodem, radši se podívejte do originální dokumentace nebo sem (česky). Radši napíšu jen co mě zaujalo. No nejvíc asi to, že se díky WebBeans mohou stát EJB i JSF [...]

    OdpovědětVymazat

Okomentovat

Populární příspěvky z tohoto blogu

Jak si v IT vydělat hodně peněz?

Na začátek by bylo dobré, abych objasnil samotný titulek, který může na někoho působit jako červený hadr. Článek nebude o obecných pravidlech, ale bude vyprávět můj vlastní příběh, na kterém vám zkusím ukázat, jak se dá docílit úspěchu, či alespoň správně nastartovat svojí vlastní kariéru v IT.

I když se z názvu článku dá dedukovat, že se vše bude točit kolem peněz, není tomu tak. Alespoň ze dvou třetin určitě ne. Ale to už předbíhám, pojďme to raději vzít hezky popořadě...

Kdybychom měli mluvit o roce 2017 jako o přelomové době, nejspíše to nebude pravda. I když pro někoho to může být rok plný úspěchů a štěstí v podobě narození zdravých dětí, svatby či první velké lásky, tak z pohledu lidstva se jedná o rok, který jen kopíruje předešlé a v oblasti technologií nás posouvá stejným tempem jako rok předtím.

Jsem naprosto přesvědčen o tom, že i když se současná doba tak nenazývá, tak prožíváme dobu, která jednou bude označena za revoluční, a to zejména díky vynálezu internetu, který je s…

Jak by se firmy neměly chovat k programátorům?

Každý, kdo pracuje v IT oboru, se jistě již setkal s různými „geniálními nápady“, od kterých si firma slibovala zlepšení produktivity či snížení nákladů. Ať už je to zavedení agilních principů, striktní kontrola práce či zavedení nové a skvělé metodiky, o které si „šéf“ přečetl včera na internetu. Jsou z toho skutečně tak nadšení i samotní vývojáři? A bude nový nápad fungovat?
K napsání tohoto článku mě navedly různé programátorské diskuze, kde si lidé stěžovali na firmu, kde pracují. Příklady, které zde uvedu, jsou z reálné praxe. Ať už jsem je zažil jako řadový programátor, či jako šéf týmu.
I když je poptávka po programátorech tak vysoká, že Vás headhunteři nahánějí i ve chvílích, kdy o to opravdu nestojíte, tak i přes to je mnoho lidí, kteří se bojí opustit svoje současné zaměstnání.
Čeho se nejčastěji bojíme? Je to samozřejmě nejistota, kterou si často omlouváme větami jako: „Tady mám své pohodlí, co když to jinde mít nebudu?“ nebo „I když mě to v práci štve a nebaví, tak mě ale…

Jak jsem technologicky postavil startup

Tento příběh pojednává o technologiích, nástrojích a vůbec o všem, co jsem potřeboval k tomu, abych byl schopen, postavit startup na zelené louce.

Každý správný příběh začíná stejně: "Jednou jsem...."

Kapitola první: Nápad
Jednou jsem se setkal s člověkem, který měl nápad na produkt, který se v průmyslu zatím nevyskytuje. I přes prvotní skepsi, kdy jsem si říkal: "Tohle už přeci dávno v průmyslu existuje, ne?", jsem došel ke zjištění, že nikoli.

Tím jsem se dostal ke svému prvnímu poučení. Průmysl je technologicky dost zabržděný. Osobně se domnívám, že těch důvodů, proč tomu tak je, je několik. Za prvé je to fakt, že většina lidí, kteří se pohybují v tomto odvětví jsou často konzervativní a za správné považují pouze léty osvědčené věci. Druhým důvodem je to, že jakákoli změna znamená riziko. Ať už z pohledu finanční ztráty tak i z pohledu stability výroby. No a třetím a nejzásadnějším důvodem je to, že ač zde máme spousty technologických vymožeností, narážíme na to,…