trying to solve IT problems

JBossWorld Boston, Jason T Greene, Zen of class loading

What is the Class class
- represents a class
- allocates memory on heap and permgen
- is referenced by every object instance of that class
- Unique (by name) only to a ClassLoader
- holds a reference to the ClassLoader

What is a ClassLoader
- responsible for loading classes
- holds strong reference to all classes it loads
- optional parent for delegation

Problem #1 – OutOfMemory:PermGen
- too many classes loaded
- sizing could be wrong, big application with many classes
- possible classloader leak
– hot deployment causes new classloader
– one instance to an object prevents garbage collection of all classes loaded by the classloader

Common leak sources
- static field on a class with a long lifecycle (on another classloader)
- caching frameworks
- persistent thread locals (automatic cleaning is *very* important)
- framework bugs (logging frameworks, third-party frameworks)

JDK class loading delegation
- parent-first prevents overriding a parent
- custom classloaders can do this (and they do!)
- bootstrap is searched even if parent==null
- bootstrap classes often return null for getClassLoader()

JDK has default hierarchy
- boot classpath (including lib/endorsed)
- application/system loader (defined class path)
- user loader

Problem #2 – ClassNotFoundException
- classes are not visible to the loader
- unintentional ref/dep
- solution: audit cross jar references (Tattletale)

EE class loading model
- child-first allows deployments to override parent classes and jars
– support bundling a diffrent version of a framework than in the ear
- EJB jars share classes with the EAR
- WARs do not share classes, but do see classes in the EAR
- RARs and global EJB-Jars visible to everyone

Problem #3 – ClassCastException on the same name
- duplicate class in isolated loaders
- usually a packaging problem
- common scenario – bundling ejb local interfaces in a WAR

Domain based models (default class loader)
- hot deploy requires classloader per deployment
- normal classloader isolations disallows pass-by-reference
- domains allow class sharing between class loaders
- duplicate classes are resolved using fist-come-first-server
- allows big ball-of-mud
- shared class cache
- default : one domain (defaultDomain) for all, plus one for each WAR
- fix : isolate ears in deployers/ear.deployer

Evolution to module class loaders
- applications don’t always fit hierarchical models
- declare specific dependencies, each jar is a module
– each jar declares dependencies on a name and version
- module system responsible for mapping to class loader (delegation map)
- module has imports and exports

OSGi bundle = module mentioned here, require-bundle, import-package, export-package

AS5 support package and module import/export, jboss-classloading.xml (import=requirements, export-capabilities)
domain style model is also possible

future :
- JDK7 is probably going modular (project jigsaw – JSR-294)
- EE7 will probably follow
- AS7 will be modular

Tattletale can produce module descriptors using a plug-in

JBossWorld Boston, Andrew Lee Rubinger, Throwing complexity over the wall

What is important to employer
- bottom line
- features
- time-to-delivery
- implicit assumption that everything is of high quality
- not much tolerance for refactoring, stress-testing,…

Software can be in three silos
- core concerns : business logic, domain specific, no one else can do this ; time spent here is a good investment
- cross cutting concerns : independent of business logic, targeted, composable, “aspects”/”advice”, orthogonal/perpendicular
- plumbing : get data from A to B, transformation, does (should) not affect state, enables loose coupling, generic, usually implemented by frameworks ; typically not the best use of an application developers time

What should you do
- business logic, core concerns
leave the rest to servers and frameworks
- less you write, less you need to maintain

Components model as solution
- run in a “container”
- container manages the environment, wires up at runtime
- user code executes as deployable components
- components follow a standard form, or model

And what is Jave EE
- collection of specifications which allow writing business logic as components
– recipe to write less
– increase signal to noise ration
- platform defining how containers should handle this

What’s missing?
- a cohesive way to develop and test our applications
- applying the same component model to out tests

Importance of testing – the often ignored
- forces developers to be users
- key in proving API design makes sense
- self-documenting
- gives a sustainable path forward
- slims the release process, no big-bang runs at the end

Excuses, excuses
- testing is not enjoyable, it should be!
- when under pressure to deliver, test code does not deliver bottom-line

Unit testing
- finely grained
- speed is important

Integration testing
- coarsely grained
- component interactions
- agile “user stories”

Traditional approach to integration testing
- start container
- do test using some kind of remoting
- clean up the house

In-JVM embedded integration testing
Pro
- shared memory
- pass-in-reference
- no remotable views
- manage concurrency
Cons
- lack of isolation
- JVM start-up parameters may differ

Hybrid approach
- container in its own process
- test is deployed as archive, bundled alongside test execution framework
- test runs inside container
- TestRunner obtains the results remotely

Test reliance upon the build
- adds extra step to the development/test cycle
- packaging : defines a unit, regulates class loading

Fake the environment for unit tests
- use mock objects, stub out API which may not be available, gets you running in POJO environment

Introducing ShrinkWrap
- simple mechanism to assemble archives like JAR, WAR, EAR in Java
- deploy “virtual” archive in container, integrates with JBoss EmbeddedAS, OpenEJB, Jetty, GlassFish v3

Micro deployments
- Using ShrinkWrap to deploy components in isolation
- test one thing at a time

Arquillian
- provide simple test harness to produce braod set of integration tests for (enterprise) Java applications
- abstract our server lifecycle

How
- use “@RunWith(Arquillian.class)”, define the deployment (annotated with “@Deployment”)
- rest are just your tests and some annotations to wire everything up
- container is not defined in the test class, can be defined separately

When developing EJB beans, there are ways to inject the current user to assure the logged in user is known. The same goes when developing a web application where the information is available through the HTTPServletRequest.

However when outside these, like when developing a JMX bean or when writing a webservice which requires authentication, there are no standard ways to get this information.

In JBoss however, this can be solved by accessing the SecurityAssociation class.

SecurityAssociation is the JBoss recommended make login and credentials (password) available when doing remote EJB access. Looking though the JBoss source it appears that this is used to store the credentials server side as well. So, you can always get the login details using
SecurityAssociation.getPrincipal().

Also interesting (but completely untested), is the pushRunAsIdentity() method which should allow (server-side only) switching run-as role without the need to call a EJB.