Hi Marina,
Some feedback regarding @AroundConstruct in draft 2.
1. Some non-normative use-cases/examples would be helpful.
2. What is the intent of this restriction: "Injection of the target
component into interceptor instances that are invoked during the
AroundConstruct lifecycle callback, is not supported."? The injection of
a target wrapper/proxy into the interceptor shouldn't be a problem. Is
primarily to avoid invocation of the target in the interceptor, which
could result in a loop?
3. What is the behavior of InvocationContext.getTarget prior to the final
proceed()? Does it return null, does it throw IllegalStateException, or ?
4. The phrase "should not invoke any business methods of the target
instance" seems questionable, since the actual bean instance is returned,
not an ejb wrapper/proxy. Is the intent to restrict what I mentioned in
#2? Perhaps it should say "Interceptors should be careful to avoid
calling methods on the target instance that might rely on state that has
not been initialized since injection and @PostConstruct lifecycle callback
methods have not been called".
5. What happens if an @AroundConstruct interceptor doesn't call
proceed()? Presumably this is an error. Is it up to the individual specs
(e.g., EJB would throw EJBException) to define the behavior?
6. This statement seems to have an incorrect implication:
"If the AroundConstruct lifecycle callbacks are NOT associated with the
target instance, all interceptor methods, including PostConstruct
callbacks, if any, are invoked only after dependency injection has been
completed on both, the interceptor instances and the target instance.
[1]."
The 'NOT' in this position implies that if AroundConstruct IS present then
PostConstruct might be called before dependency injection, which is not
correct. Something like "all interceptor methods except AroundConstruct
callbacks are invoked only after dependency injection has been completed"
eliminates that implication.
7. Do interceptors need to be injected as proceed() is called, or is there
freedom to inject them all, then invoke them all? If not defined, each
vendor could choose a different scheme, leading to differences in
behavior. For example, complete construction+injection could lead to an
early injection failure, while lazy construction+injection of interceptors
may avoid an up-front injection failure and throw some other exception in
the middle of the invocation chain.
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
users_at_interceptors-spec.java.net,
Date: 02/11/2013 02:20 PM
Subject: [jsr345-experts] Interceptors spec 1.2 DRAFT2 is available
for review
Experts,
You can now review the 2nd draft of the Interceptors spec. This version
incorporates most of the review comments and the AroundConstruct
interceptor. The full list of changes is below (the change log at the
end of the document is an accumulative list).
The draft:
http://java.net/projects/interceptors-spec/downloads/download/interceptor-1-2-dr2.pdf
The diff from draft1:
http://java.net/projects/interceptors-spec/downloads/download/interceptor-1-2-dr2-diff.pdf
Please review it (AroundConstruct) in particular ASAP.
Pete, please forward it to the CDI EG.
The list of changes as found in the revision history:
- Fixed page numbers in the book
- Minor editorial changes
- Moved Section 5.6 to the end of Chapter 5
- Moved rule on invocation order of interceptors with superclasses to
Section 5.3
- Replaced rules on the Nonbinding annotation with references to the CDI
spec
- Clarified that an around-invoke interceptor method, around-timeout
interceptor method, and lifecycle callback interceptor methods for
different lifecycle events may be defined on the same interceptor class
- Added the AroundConstruct lifecycle callback interceptor
- Extended InvocationContext with getConstructor method; adjusted rules
on the InvocationContext.getTarget return value, and
InvocationContext.proceed result
- Added notes to the around-invoke and around-timeout about the throw
Exception clause in their signatures
- Added a not that transaction context of interceptors may be changed by
transactional interceptors in the invocation chain
- Explained how interceptors are enabled
Happy reading,
-marina