Java Web User Group Impala Framework Update Modular class loaders and OSGi Phil Zoio London December 2, 2008

Why is modularity a good thing? Static modularity decouples parts of a system  less complexity  easier to deploy in part  easier to configure  easier to test Dynamic modularity allows partial loads/updates  developer productivity  operational benefits (e.g. hot fixes)‏

Example – fulfilment system main hibernatedaoimportweb order processing warehouse manageme nt Contains main domain model classes plus interfaces shared by modules

Tools of the trade Service registry  decouples service providers from users Proxies  allow static references to dynamic services Dependency injection (Spring)‏  provides transparent programming model Class loaders  limits visibility of classes across modules  allows “reloading” by replacing class loaders

Class loader options Single class loader Hierarchical class loader Graph-based class loader OSGi

All Single class loader All modules share same class loader main hibernatedaoimportweb order processing warehouse manageme nt Single class space – all public classes are visible to all other classes No runtime enforcement of modularity boundaries No partial reloading

Hiearchical class loader Visibility inherited from parents main hibernatedaoimportweb order processing warehouse manageme nt Modules can see classes within module plus those visible to parents Supports reloading of module subtree e.g. dao and import cannot see each other's classes

Graph-based class loader Visibility inherited from multiple dependencies main hibernatedaoimportweb order processing warehouse manageme nt Unlike hierarchical, allows importing from more than one module Supports reloading of subgraph web import

OSGi class loader Versioning and enhanced visibility controls main hibernatedaoimportweb order processing warehouse manageme nt More powerful than graph-based class loader: - Either package imports and exports or explicit module dependencies - Multiple versions of same package - “Private” packages - Visibility not necessarily inherited - Applies to 3 rd party and app classes web imports Graph relationships are largely implicit

Pros and cons Single class loader  simplest BUT but no enforcement or reloading Hierarchical  simplest which supports dynamic reloading BUT has limitations Graph-based  more complex BUT more powerful and flexible than hierarchical OSGi  most powerful BUT most complex and requires extra runtime support (OSGi container)‏

Usage scenarios Single class loader  multiple class loaders not an option  quick running test suites Hierarchical  simpler apps requiring dynamic modularity Graph-based  complex apps requiring dynamic modularity OSGi  must address 3 rd party library conflicts or dynamic reloading requirements  need dynamic integration of 3 rd party modules

Impala support Single class loader  present in current version (1.0 M3)‏ Hierarchical  present in 1.0 M3 Graph-based  in SNAPSHOT and next version (1.0 M4)‏ OSGi  standalone support in SNAPSHOT & 1.0 M4  web support planned for 1.0 M5

Why use Impala with OSGi? Eases transition into OSGi Allows switching between environments Adds framework for managing application modules Leverages Spring and Spring DM

Resources Home: Blog: Me:

Q & A