NEJUG ~ JSR-299 – 08-Oct-2009

Very rough notes on JSR-299 by Gavin King from NEJUG Meeting of 08-Oct-2009

Profiles

Will enable deployment with subset of JEE feature set – so can leave out parts you don’t use – thinner footprint, less complexity?

Theme = Loose Coupling

decouple server and client via well-defined types and “qualifiers” (beyond Interfaces)
decouple lifecycle of collaborating components via
1. server-side lifecycle management by Container
2. allow stateful components to interact like services via message-passing
decouple orthogonal concerns via Interceptors
decouple msg producer from consumer via Events

Theme = Strong Typing

eliminate lookup using string-based names
1. enables smarter auto-complete, more power in compiler type checking

What’s unique?

implementations of a type may vary at deployment time – without need for central list of available implementations
1. no need to explicityl list beans (e.g., Spring) or use Java-based DSL (Guice)

What kinds of things can be injected and how?

Most java classes
EJB session beans
Objects returned by producer methods
Java EE resources (e.g., JMS topics/queues)
Persistence contexts (JPE EntityManager)
Web service references
Remote EJB references
anything else can be supported through SPI (flexible extensibility via metamodel)
Can define business-sensible attributes to specify injection types (e.g., InformalGreeting extends Greeting class, then have an @Informal attribute)
Can use injected object in a JSF or JSP page – e.g., container will instantiate the right objects (construct as needed, etc.) and pass it is such as in: <h:commandButton value=”Say Hello” action=”#{printer.greet}”/>
Beans may need to be stateful – this is supported too – handled as lifecycle attributes such as @RequestScoped for per-request or

Scopes and Contexts

Extensible context model
Dependent scope, @Dependent
Built-in scopes
1. @ApplicationScoped, @RequestScoped, for servlet we have @SessionScoped [e.g., Login state object may store username in a member variable], for JSF requests @ConversationScoped
Custom scopes – third party frameworks can support via SPI
KEY POINT: Client does NOT know anything about the lifecycle of the session-scoped object
Conversation context is scoped INSIDE OF (DOES IT NEED TO BE WITHIN, or is it just defined as more granular a SCOPE than) a session – can have more than one Concersation that don’t know about each other – supports multiple tabs, wizards, AJAX and other multi-step sub-tasks
Better abstracts some concepts – a set of mappings can be defined such that a class can loosely reference (my term), say, a value from another object (like the user’s first name, from the Login object), and the container will take care of all the heavy lifting and just insert that value – nicely separates lookup logic so your business logic code can stay cleaner and refer to (as in example above) their “first name”, not the Login object directly

Interceptors

ANOTHER APPROACH FOR WHAT ASPECTS ARE USED FOR TODAY
1. Perceived to be more flexible, more generally useful (there are very few uses for Aspects now – nothing new in 5-10 years!)
Should be decoupled from implementation via semantic annotations
Should be deployment-specific – e.g., can turn off my transaction support during testing
Ordering of interceptors matters – so do this centrally so you can manage/understand it – don’t bing interceptors directly to components

Stereotypes

Reuse patters – not just Interceptor bindings!
Capture roles of components using stereotypes
A Stereotype packages up:
1. a default scope
2. a set of interceptor bindings
3. the ability to specify that beans have names by defaults
4. (more)
Uses @Stereotype annotation

Events