NEJUG ~ JSR-299 – 08-Oct-2009

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


  1. 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

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

Theme = Strong Typing

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

What’s unique?

  1. 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?

  1. Most java classes
  2. EJB session beans
  3. Objects returned by producer methods
  4. Java EE resources (e.g., JMS topics/queues)
  5. Persistence contexts (JPE EntityManager)
  6. Web service references
  7. Remote EJB references
  8. anything else can be supported through SPI (flexible extensibility via metamodel)
  9. Can define business-sensible attributes to specify injection types (e.g., InformalGreeting extends Greeting class, then have an @Informal attribute)
  10. 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}”/>
  11. Beans may need to be stateful – this is supported too – handled as lifecycle attributes such as @RequestScoped for per-request or

Scopes and Contexts

  1. Extensible context model
  2. Dependent scope, @Dependent
  3. 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
  4. Custom scopes – third party frameworks can support via SPI
  5. KEY POINT: Client does NOT know anything about the lifecycle of the session-scoped object
  6. 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
  7. 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


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


  1. Reuse patters – not just Interceptor bindings!
  2. Capture roles of components using stereotypes
  3. 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)
  4. Uses @Stereotype annotation


  1. Can be injected – as in void Login(@Observes LoggedIn loggedin)…

Proposed final draft of JSR-299:

Seam Framework reference implementation:

JBoss doc:



Value of more Type Safety in a world where Dynamic Languages are gaining traction

Debugging might be more challenging

Performance issues?

Complexity / tooling issues?

How is this different / better / worse than Spring?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.