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

Profiles

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

Interceptors

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

Stereotypes

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

Events

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

Proposed final draft of JSR-299: http://www.jcp.org/en/jsr/detail?id=299

Seam Framework reference implementation: http://seamframework.org/WebBeans

JBoss doc: http://docs.jboss.org/webbeans/reference/current/en-US/html/

Blog: http://in.relation.to/Bloggers/Everyone/Tag/Web+Beans

—-

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?