TestWatchman je v podstatě interceptor, který můžete zavěsit na události failed, finished, starting a succeeded. Ukažme si na následujícím příkladě, jak zareagovat na neúspěšný test a zjistit jméno třídy a název testu. Tento string používáme jako jméno screenshotu v našich selenium testech. Metoda failed se volá jak při assertationFailed tak při výjimce.

import static junit.framework.Assert.fail;

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.MethodRule;
import org.junit.rules.TestWatchman;
import org.junit.runners.model.FrameworkMethod;

public class MyTest {

	@Rule
	public MethodRule watchman = new TestWatchman() {
		@Override
		public void failed(Throwable e, FrameworkMethod method) {
			String methodName = MyTest.this.getClass().getSimpleName() + "." + method.getName();
			System.out.println(methodName + " has failed!");
		}
	};

	@Test
	public void testFailed() {
		fail();
	}

}

Pro představu. Máme za úkol pokrýt testy funkčnost založení uživatele. Máme dvě poměrně jednoduché obrazovky:

Seznam uživatelů:

Vytvoření nového uživatele:

Jeden test bude na pozitivní scénář založení uživatele. Další test bude na založení uživatele s existujícím uživatelským jménem. Potud je to dobré a vystačili bychom si i s naklikanými testy. Ale jak se začnou množit další scénáře vyžadující založeného uživatele, začínáme se dostávat do problémů. Editovat uživatele, smazat uživatele, zablokovat uživatele, založit požadavek s uživatelem s příslušnou rolí, atd. Původně jsme to řešili privátními metodami v rámci test třídy. To ale nestačí, pokud potřebuji např. založit uživatele v rámci jiného testu. Tak si začnu vytvářet různé helper třídy, ale v tu chvíli v tom začíná být trochu zmatek. Člověk neví, jestli daný kód napsat do helper třídy nebo přímo do testu. Nebyli jsme s tímto stavem spokojeni.

Page Objects návrhový vzor to krásně řeší. Zjednodušeně vytvářím dva druhy tříd. Testy a stránky (Page Object). Page obsahuje metody, které znamenají služby, jaké stránka nabízí z pohledu uživatele. Např. tlačítka, vyplnění formuláře, odkazy, atd. Další metody umožňují zjišťovat stav, v jakém se stránka nachází. Např. počet záznamů v tabulce, přítomnost chybové hlášky, atd. Všechny tyto metody jsou implementovány pomocí Selenium API.

Testy samotné pak naopak nepoužívají Selenium API vůbec. Pouze sestavují testovací scénář voláním sérií služeb na jednotlivých stránkách. A pak také obsahují veškeré asserty. Zjistí stav pomocí metody na stránce a ověří ho. Asserty nepatří do stránky a zase Selenium volání nepatří do testu. S těmito jednoduchými pravidly se dají vytvářet velmi přehledné a čitelné testy.

Tady je příklad na otestování funkce založení uživatele v Orinoco platformě.

Stránka odpovídající formuláři na založení uživatele:

@Page
public class CreateUserPage extends AbstractOrinocoPage {

    @Override
    public boolean isValidPage() {
        return selenium.isElementPresent("page_user__createUser__do");
    }

    public CreateUserPage fillForm(TestUser user) {
        selenium.type("username", user.getUserName());
        selenium.type("password", user.getPassword());
        selenium.type("confirmedPassword", user.getPassword());
        for (String userType : user.getUserTypes()) {
            selenium.addSelection("name=roles", "value=" + userType);
        }
        selenium.type("firstName", user.getFirstName());
        selenium.type("lastName", user.getSurname());
        selenium.type("email", user.getEmail());
        return this;
    }

    public UserListPage create() {
        clickAndWait("common_action_create_button");
        return navigateTo(UserListPage.class);
    }

}

Jsou tam implementovány dvě “služby”. Vyplnění formuláře a stisknutí tlačítka Create. Všimněte si, že zde se přímo používá Selenium API. Dobré bývá také pracovat s daty tak, že jsou zapouzdřené do objektů. Na jednom z projektů jsme dokonce použili přímo DTO objekty, protože už byly hotové a odpovídaly přesně formulářům. Chybí metoda pro Storno tlačítko, ale to nevadí. Doplní se, až bude potřeba pro nějaký scénář. Předek této třídy dává tušit, že bude obsahovat metody odpovídající hlavnímu menu a celému záhlaví.

Takto vypadá Page objekt pro seznam uživatelů:

@Page
public class UserListPage extends AbstractOrinocoPage {

    @Override
    public boolean isValidPage() {
        return selenium.isElementPresent("page_user__listUsers__do");
    }

    public CreateUserPage createUser() {
        clickAndWait("//a[@href='createUser.do']");
        return navigateTo(CreateUserPage.class);
    }

    public TableControl getUserTable() {
        return getTableControl();
    }

}

Je tu implementována jenom jedna metoda na přidání nového uživatele. Za zmínku určitě stojí navigace. Každá metoda, která něco dělá s aplikací, vrací objekt typu Page. Buď vrací novou stránku při přechodu nebo sebe sama, pokud browser zůstává na stejné stránce. Metoda getUserTable() jenom zjišťuje stav na stránce. TableControl je pomocný objekt na práci s tabulkami. Ani na jedné ze stránek není jediný assert. Ten přísluší Test třídě.

Test case pro správu uživatelů:

public class UserManagementTest extends AbstractOrinocoTest {

	private DashboardPage dashboardPage;

	@Before
	public void login() {
		dashboardPage = loginPage.login("habele", "a");
	}

	@Test
	public void createUser() {
		TestUser user = new TestUser("selAdmin", "selAdmin", Arrays.asList(TestUserType.ADMIN),
				"selAdmin", "selAdmin", "selAdmin@aspectworks.com", true);

		UserListPage userListPage = dashboardPage.openSettings().openUserManagement();
		CreateUserPage createUserPage = userListPage.createUser();
		createUserPage.fillForm(user).create();

		TableControl userTable = userListPage.getTableControl();
		TableRow row = userTable.getRow(user);
		assertNotNull(row);
		assertEquals(user.getUserName(), row.getCell(3));
	}

}

Test case má standardní průběh. Příprava testovacích dat, provedení testu a kontrola výsledku. Se stránkami se velmi dobře pracuje zřetězeně právě kvůli tomu, že metody zase vrací Page objekty. Test už vůbec nepracuje se Selenium API. Vše nechává uvnitř stránek.

Návrhový vzor Page Objects se velmi osvědčil. Je to přirozený návrh tříd podle uživatelského rozhraní. Testy se velmi snadno tvoří a čtou a znovupoužitelnost je velmi dobrá. Ze stránek se navíc dají tvořit další objekty vyšší úrovně zapouzdřující celé moduly. Lze pak třeba založit uživatele jedním řádkem a pokračovat ve psaní skriptu toho, co zrovna testujeme.

V tomto článku nebylo zmíněno ještě několik součástí, které jsou vidět ze zdrojových kódů. Jak jsou stránky a testy konfigurovány a jak jsou tvořeny instance? Jak probíhá navigace mezi stránkami? Jak ověřit, že se browser nachází na stránce, na které je volána metoda služby? Jak funguje TableControl? O tom zas někdy příště.

Obvykle každý ví, že rodná čísla se tvoří od roku 1954 ve tvaru yymmdd/xxxx a ta starší mají tvar yymmdd/xxx. Pokud je to žena, přičte se k měsíci 50. Také si každý myslí, že by mělo být rodné číslo dělitelné jedenáci. Ale zde je právě kámen úrazu. Vše je trochu jinak.

Poslední desátá číslice přidávaná od roku 1954 je kontrolní a tvoří se tak, že se vydělí devitimístné číslo jedenácti a zbytek po dělení se použije jako desátá kontrolní číslice. Tím je výsledné desetimístné číslo dělitelné jedenácti. Tedy v případě, že zbytek po dělení nebyl 10. V takovém případě je kontrolní číslice rovna 0, ale tím pádem není celé rodné číslo dělitelné jedenácti. Do roku 1985 bylo přiděleno cca 1000 rodných čísel, která nejsou dělitelná 11. Není vyloučeno, že se v minimálním počtu vyskytly i po tomto roce.

Navíc od roku 2004 je zavedena možnost v případě, že jsou v nějaký den vyčerpána všechna platná čtyřčíslí, použít alternativní rodné číslo, u kterého mají muži k číslu měsíce přičteno 20 a ženy 70. A i rodná čísla před rokem 1954 mohou mít čtyřčíslí, pokud se jednalo o dodatečně přidělená rodná čísla (např. při získání občanství).

Více informací třeba na Wikipedii nebo na tomto blogu.

Většina aplikací se spokojí s ověřením dělitelnosti jedenácti. Ale to je evidentně špatně. Ještěže nemám tu smůlu a nemám nestandardní rodné číslo

Napsal jsem pro účely Selenium testů generátor rodných čísel s několika možnostmi, jak číslo generovat:

• pro konkrétní datum a pohlaví
• pro věkové rozpětí – vhodné třeba pro generování mladistvých
• oficiální rodné číslo – dle výše popsaných pravidel
• běžné rodné číslo – takové, které čeká většina aplikací – dělitelnost 11, standarní tvary
• speciální rodné číslo – takové, které není běžné – vhodné pro test validace

Ukázka použití generátoru:

// generates random personal number from 1900 till today
String personalNumber = RcGenerator.generateRc();

// men between 18 and 30
personalNumber = RcGenerator.generateRcForAge(18, 30, Gender.MALE);

// common personal number modulo 11 == 0 which passes most validators
personalNumber = RcGenerator.generateRc(RcType.COMMON);

Přiložené třídy můžete volně použít. Budu rád, když najdete chyby nebo generátor vylepšíte, rozšíříte funkčnost a s kódem se zase podělíte.

RcGenerator.zip

Pozor na pořadí anotací! Řešení popsané ve zmiňovaném článku volá nejprve metodu anotovanou @After a poté teprve @AfterFailure. To samo o sobě není problém, pokud stejně jako my v metodě anotované @After nevoláte metodu Selenium#stop(), která zavírá prohlížeč. To pak vám je získaný snímek obrazovky k ničemu. Rešení je jednoduché, stačí v runneru jen prohodit volání metod v metodě #withAfters(FrameworkMethod, Object, Statement).

@Override
protected Statement withAfters(FrameworkMethod method, Object target, Statement statement) {
      statement = withAfterFailures(method, target, statement);
      return super.withAfters(method, target, statement);
}

Věřím, že vám snímky v případě selhání Selenium testů ušetří čas při opravování bugů.

Edit
JUnit od verze 4.7 má svoje řešení jménem TestWatchman.

V AspectWorks jsme fanoušky kontinuální integrace. Píšeme unit testy, snažíme se o dobré pokrytí kódu a s každým commitem do SVN spouštíme integrační build. Aktuálně používáme TeamCity jako server na kontinuální integraci. O selhaných buildech nás doteď informovaly emaily, Jabber, vyskakovací okýnka v Eclipse, atd. Nuda!

Teď jsme si ale pořídili tu správnou vychytávku na notifikaci o buildech: Tux plugin do TeamCity.

Jak to funguje? Jednoduše – když někdo rozbije build, tučňák Tux začne křičet, který build selhal.

Pokud nemáte zrovna TeamCity, nevadí – Tux API je docela jednoduché, takže si můžete celkem rychle udělat plugin pro vlastní build server.

TuxAPI tux = new TuxAPI(ipAdress, port);
tux.server.autoConnect(TuxAPIConst.CLIENT_LEVEL_RESTRICTED, "login", "password");
tux.tts.speak("Text to speach");

Vřele doporučuju nějakou takovou blbinu zavést.

Představte si například situaci, kdy v properties vaší aplikace potřebujete nastavit, zda se Spring Security bude autentizovat vůči databázi nebo vůči LDAPu.

Jak na to?

Nejdříve nastavte v properties takovýto klíč:
myApplication.authentication.provider=ldap

Target beana libovolného jména definovaného v properties bude díky BeanReferenceFactoryBean dostupná vždy pod jediným a předem známým id.

<bean id="authenticationProvider" class="org.springframework.beans.factory.config.BeanReferenceFactoryBean">
	<property name="targetBeanName">
		<value>${myApplication.authentication.provider}AuthenticationProvider</value>
      </property>
</bean>

Do authentication-manageru nainjektujeme beanu authenticationProvider, jejíž target beana je zvolena právě na základě konfigurace v properties.

<sec:authentication-manager>
	<sec:authentication-provider ref="authenticationProvider"/>
</sec:authentication-manager>

Pro úplnost ještě uvádím nástin konfigurace Spring Security vůči databázi a LDAP.

<bean id="dbAuthenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider" lazy-init="true">
	<property name="userDetailsService" ref="userDetailsService" />
</bean>

Lazy-init je nastaveno na true, protože pokud si vyberete autentizaci vůči databázi, tak nebudete konfigurovat LDAP a naopak. S nevalidním nastavením by vám pak vůbec nenaběhl aplikační kontext.

<bean id="ldapAuthenticationProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider" lazy-init="true">
	<!-- configuration of LDAP -->
</bean>

Místo nového buildu teď stačí pro změnu konfigurace jen upravit nastavení v properties a restartovat aplikační server.

Zkusme napřed pojmenovat možné způsoby, jak získat data pro číselníky na novém projektu.

• Přebírání číselníků ze staršího projektu, programu, firmy, … – asi nejrozšířenější praktikou je vzít data tam, kde už jsme je jednou připravili. Může to být jiný projekt, naše internetové bankovnictví, nebo třeba náš účetní systém. Je to správné a legální? Dá se takový postup snadno zopakovat? Jak řešit aktualizace dat?
• Placený zdroj dat – některé číselníky si můžeme koupit. Existují dodavatelé, kteří se na přípravu a aktualizaci číselníkových dat specializují.
• Volně dostupné zdroje dat na internetu – mnohé číselníky neobsahují data, o kterých by se dalo mluvit jako o cenných. Náročný bývá spíše způsob, jak jejich hodnoty zkompilovat a udržovat. Proto je přirozená myšlenka hledat pro číselníky volně dostupné zdroje dat. Existuje jich mnoho, na některé se zaměřím.

Ve zbytku příspěvku se budu věnovat právě několika dostupným zdrojům dat pro číselníky zemí, bank, měn, měst, ulic, PSČ a adres.

Země

Pro číselník zemí existuje standard ISO 3166. Standard má tři části, číselníku zemí odpovídá ISO 3166-1 (dvouznakové kódy, pro Českou republiku je to ČR). Další dvě části standardu popisují jemnější členění zemí a země vyřazené z číselníku. Na typickém projektu není důvod tento standard nepoužít.

• ISO – Přímo na stránkách ISO organizace se dají najít číselníky zemí v angličtině a francouzštině. Bohužel jen v upper case.
• Český statistický úřad – Na stránkách ČSÚ je možné volně stáhnout xls soubor s daty odpovídajícími normě ISO 3166-1. Číselník obsahuje kódy předepsané standardem, plný a zkrácený český název a plný anglický název.

Na posledním projektu jsme použili data z ČSÚ. Xls soubor jsme zkonvertovali do csv a pak už jej jednoduchým skriptem transformovali do formátu, kterým plníme databázi. To je postup, který se dá snadno zopakovat a v případě potřeby i automatizovat. I když to asi v případě číselníku zemí není nutné.

Banky a měny

Dalšími typickými číselníky jsou seznamy bank registrovaných v České republice a seznam měn. Pro měny opět existuje ISO standard – ISO 4217. Definuje tříznakové kódy, kde první dva znaky odpovídají číselníku zemí definovanému standardem ISO 3166-1. Nevidím důvod, proč se i pro číselník měn nepřidržet tohoto standardu (pokud potřebujeme všechny) .

• Český statistický úřad – ČSÚ je dobrým zdrojem i pro číselník měn. Na uvedeném odkazu se dá specifikace stáhnout jako xls nebo pdf soubor. Xls soubor je snado převoditelný do csv, které už se dá vhodným skriptem rychle zpracovat.
• Česká národní banka – Obsahově správným zdrojem dat pro číselník bank je určitě ČNB. Ke stáhnutí je zde k dispozici pdf soubor, který se zpracovává hůř, ale možné to je.

Nabízí se i možnost „převzít“ číselník bank z vašeho oblíbeného internetového bankovnictví. Otázkou je, nakolik je to správné a kolik toho vaše svědomí snese.

Města, ulice, PSČ, adresy, …

Poslední skupinou číselníků, které se budu věnovat, jsou města, ulice, PSČ a adresy. Od těchto číselníků si typicky slibujeme provázanost, aktuálnost dat a také možnost aktualizovatelnosti dat. V bankovním prostředí je častý požadavek na ověření existence a správnosti adresy (např. u scoring systémů, kde je zákazník s existující adresou jistě důvěryhodnější).

• Česká pošta – Česká pošta nabízí placený číselník adres. Zmiňuji ho jako alternativu k UIR-ADR (viz níže), ale protože jsem na stránkách pošty nenašel možnost stažení vzorku dat, jeho hodnocení se vyhnu.
• Český statistický úřad – Několik číselníků měst a PSČ nabízí i ČSÚ. Vždy ale plní nějaký statistický účel (např. sčítání obyvatelstva) a jako obecné číselníky se mi neosvědčily.
• UIR-ADR: Územně identifikační registr adres – Překvapivě kvalitní a volně dostupnou databázi adres spravuje česká státní správa, konkrétně Ministerstvo práce a sociálních věcí.

Datový model registru UIR-ADR
(zjednodušený, pouze některé tabulky)

Registr UIR-ADR toho nabízí mnoho:

• Typy dat – UIR-ADR obsahuje číselníky okresů, obcí, částí obce, ulic, stavebních objektů, adresních míst, adresních pošt, pražských obvodů, městských částí/městských obvodů, oblastí, krajů, správních obvodů a některé další typy dat.
• Prohlížení registru na webu – jednoduchá webová aplikace pro prohlížení registru.
  Webová služba pro ověřování adres v registru – UIR-ADR poskytuje webovou službu pro ověřování adres. Služba je volně dostupná, ale vyžaduje nejprve registraci.
• Možnost udržovat si vlastní kopii registru – zdarma si lze objednat CD s instalací UIR-ADR. Instalace znamená vytvoření instance MS SQL s daty a windows prohlížečkou, nebo inicializaci dat v jiné databázi. CD obsahuje data registru v šesti různých databázových formátech (dBase, FoxPro, Oracle, MS SQL Server, SQL_92, CSV).
• Aktualizace registru zdarma – v případě udržování vlastní kopie jsou volně k dispozici aktualizace registru (údajně připravované 1x týdně, ale to jsem neověřoval).

Na novém projektu bych rozhodně zvolil vlastní kopii UIR-ADR. Vím o několika bankách a dalších firmách, které registr používají. Standardizace dat podle registru UIR-ADR je trend, takže je tu dobrá šance, že v případě integrace a výměny adresních dat budete mít štěstí a adresy půjdou snadno porovnávat. Poslední poznámka se týká ověřování adres – nesmíme zapomenout, že zde neplatí předpoklad uzavřeného světa. Absence adresy v registru ještě nemusí zaručeně znamenat, že adresa skutečně neexistuje.

Shrnutí

Příspěvek si kladl za cíl nabídnou několik osvědčených zdrojů dat pro různé číselníky. Řešili jste někdy na projektu zdroje dat pro číselníky? Jakou cestou jste se vydali? Podělte se o své zkušenosti v diskuzi pod článkem.

Pojďme se tedy podívat, co lze s Quick Fixem a Quick Assistem dělat a jak se používají. Kdykoli Java editor zaznamená v kódu chybu, červeně jí podtrhne a na levém okraji označí žárovičkou. Po kliknutí na žárovičku nebo po stisku Ctrl+1 se zobrazí nabídka, co s danou situací můžeme dělat. Možností je v Eclipse opravdu nepřeberné množství. Zde přehled toho, co považuji za nejužitečnější:

Rychlý import

Eclipse poskytuje spoustu cest k vygenerování vhodného importu: Content Assist, chytrý copy-paste, Organize Imports (Ctrl+Shift+O) a i Quick Fix. Vlastně si nepamatuju, že bych někdy v poslední době psal import ručně. S Quick Fixem je to jednoduché. Stačí kliknout na žárovičku nebo stisknout Ctrl+1 a vybrat vhodný import.

Opravy chyb – přetypování

Okamžik, kdy Quick Fix hodně používám, je když potřebuju napsat přetypování. Je to pravděpodobně jenom takový můj zvyk, kdy si šetřím i tu práci napsat závorky a typ. Prostě napíšu kód bez přetypování a pak pomocí Quick Fixu si nechám přiřazení “opravit”. Jsem tak zas o kousek rychlejší, než kdybych to psal ručně

Vývoj shora dolů

Nebo jakým je to vlastně směrem. Prostě implementuju například servisní vrstvu a potřebuju nějakou metodu na DAO objektu. Ale neudělám to tak, že si tu metodu vyvinu předem, ale nechám si jí Quick Fixem vygenerovat.

Například píšu autentizaci ve své aplikaci a potřebuji metodu findByUsername() na UserDao. Neudělám to ale tak, že bych přešel do jiné třídy a začal si to připravovat nejdřív tam. Naopak. Zůstanu ve své vrstvě a nechám si pomoc s doděláváním chybějících metod později. To samé funguje pro privátní metody v té samé třídě a řadu dalších podobných případů.

Teď tedy máme vygenerovanou metodu na rozhraní, ale je potřeba doplnit implementaci ve třídě HibernateUserDao. A opět jsme líní, tak si necháme metodu předgenerovat. Tento způsob používám i třeba v situaci, kdy existující třídě nechám implementovat rozhraní navíc a potřebuju doplnit několik metod najednou.

Změna v signatuře metody

Stejně jako v případě nové metody lze i změny v parametrech a návratových typech metody dělat pomocí Quick Assistu. Zjistíme např. že do metody z minulého příkladu potřebujeme ještě poslat parametr s heslem. Opět můžeme postupovat obráceným směrem proti kompilátoru. Dokonce se Eclipse snaží hádat název parametru, který bude v tomto případě password. Můžeme parametry i odebírat a měnit návratové hodnoty.

Ošetření výjimek

Pokud metoda vyhazuje výjimku, která se musí ošetřit dává nám Eclipse na výběr několik možností. Můžeme si nechat vygenerovat try-catch blok a nebo nastavit throws na metodě. Případně pokud již existuje try-catch blok, tak Eclipse nabídne možnost, aby se nová výjimka připojila k existujícímu bloku.

Odstranění bloku

Někdy se hodí rychle a bezpečně odstranit obklopující blok kódu. Následující příklad ukazuje možnost odstranění try-catch bloku.

Závěr

Jako v minulém díle nezbývá než konstatovat, že pokud chceme být efektivní, je potřeba se naučit možnosti, které nabízí Quick Fix a Quick Assist. V příštím díle se budeme věnovat šablonám kódu (Code Templates).

Předchozí díl: Eclipse efektivně (1.) – Content Assist

Flexibilita JEE

Vývoj enterprise aplikací na platformě JEE je zajímavý tím, že lze architekturu a použité technologie velmi dobře přizpůsobit charakteristice i potřebám vyvíjené aplikace. Je vyžadováno vzdálené volání? Můžeme použít EJB komponenty. Je potřeba zvládat mnoho současně pracujících uživatelů? Nasadíme aplikační server s podporou clusteru. Píšeme jen jednoduchou webovou aplikaci? Nepotřebujeme plný aplikační server, postačí jednoduchý webový kontejner, např. Apache Tomcat.

Ještě větší volnost máme ve výběru knihoven a frameworků. Jenom webových frameworků je v Java světě přes sto a každý má navíc velké množství verzí. Podobné je to i s dalšími oblastmi napříč architekturou aplikace. V dnešní době je většina použitých knihoven open-source, což přináší celou řadu dobře známých výhod, od úspory na licencích až po přístup ke zdrojovým kódům.

Problémy s komponentami třetích stran

Často je obtížné sladit jednotlivé verze open-source komponent a zajistit jejich kompatibilitu. Problémy mohou nastat už během vývoje, především však později při provozu aplikace. Při provozu je potom vhodné mít podporu výrobce a dostávat záplaty na chyby a bezpečnostní rizika. Open-source komunita má obvykle dobrou odezvu na opravy chyb, ale vydává je pouze v nových verzích. To ovšem není úplně vhodné pro již běžící systém, kde taková náhrada za výrazně novější verzi může mít dopady na zbytek systému. Každá použitá komponenta má teké jiný rytmus při vydávání nových verzí, takže není možné dobře plánovat verze aplikace.

Řešení a podpora JBossu

JBoss již delší dobu řeší tyto problémy a dokonce letos rozšířil svou nabídku na poli vývojových platforem o podporu open-source knihoven a frameworků, které nejsou z jeho dílny, ale jsou hojně rozšířené a populární pro vývoj JEE aplikací. Lze se tak rozhodnout pro JBoss Enterprise platformu nejlépe vyhovující  použitým technologiím a profitovat z aktualizací, oprav chyb, podpory a dalších služeb. Společnost AspectWorks například používá ve velké míře architekturu založenou na Spring Framework, Hibernate a provozovanou na JBoss aplikačním serveru. Nyní jsme schopni mít celé toto portfolio produktů pokryto podporou ze strany JBossu.

JBoss Enterprise Web Server

Tato platforma je zaměřená na dlouhodobou podporu a předvídatelný způsob aktualizace.
Kombinuje populární Apache Tomcat s Apache web serverem a konektory, které oba propojují (mod_jk, atp.). Balíček se hodí nejenom pro nejjednodušší JEE aplikace, ale i na tzv. lehké architektury, vyžadující pouze Tomcat server. I na této platformě lze tedy provozovat mission-critical systémy a mít plnou podporu. Více v JBoss Enterprise Web Server datasheet.

JBoss Enterprise Web Platform

Odlehčená varianta JBoss Enterprise Application Platform podporující jednodušší JEE aplikace. Je zaměřená na JEE webový profil a tedy používá JBoss AS bez některých enterprise komponent. Přitažlivé je, že v této platformě je obsažena podpora pro populární frameworky a knihovny jako je Spring Framework, Hibernate, Struts, RichFaces, Google Web Toolkit a další. Lze tak dosáhnout podpory od aplikačního serveru přes všechny důležité aplikační frameworky. Sada frameworků je dostupná i samostatně jako JBoss Web Framework Kit.

JBoss Enterprise Application Platform

Platforma pro vývoj enterprise aplikací podle JEE standardů pro nejnáročnější nasazení. Zahrnuje JBoss aplikační server s podporou EJB, JTA, cluster, distribuované aplikace, asynchronní komunikací JMS, open-source frameworky a další komponenty. Je to nejvhodnější volba v případě vývoje rozsáhlých řešení na založených na JEE a provozovaných na JBoss produktech. Pro velmi důležité provozní systémy je vhodné doplnit tuto vývojovou platformu i o monitorovací nástroje v podobě JBoss Operations Network, zahrnující integrované nástroje pro správu, nasazení a monitorování všech komponent JBoss Enterprise Middleware.