Hi Marina,
Thanks for your reply.
Re: #2 From an EJB perspective, this still doesn't seem problematic. For
example, I would expect the following to work, because the @EJB injection
does not directly inject a target instance.
@Stateless @Interceptors(Int1.class) public class A { }
public class Int1 { @EJB A field; }
It would be the actual invocation of a method on Int1.field in an
AroundConstruct that would problematic. I can see where just adding the
basic restriction will eliminate potential issues, though.
Re: #3 please add this to javadoc and/or spec
Re: #7 For example, if there are two interceptors, each with setter
injection, is there a required order for {construct Int1, construct Int2,
inject Int1, inject Int2, call Int1.aroundConstruct, call
Int2.aroundConstruct, construct target instance}? Or is there freedom to
create/inject interceptor instances in any order, so long as the
aroundConstruct for a specific interceptor is called after injection for
that specific interceptor?
-Jeremy
From: Marina Vatkina <marina.vatkina_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Cc: Jeremy Bauer/Rochester/IBM_at_IBMUS, users_at_interceptors-spec.java.net
Date: 02/13/2013 02:27 PM
Subject: [jsr345-experts] Re: Interceptors spec 1.2 DRAFT2 is
available for review
Hi Jeremy,
Thanks for the review.
On 2/13/13 11:08 AM, Jeremy Bauer wrote:
Hi Marina,
Some feedback regarding @AroundConstruct in draft 2.
1. Some non-normative use-cases/examples would be helpful.
The intent is to be used by BV, and to much lesser extent by regular
developers. But I can try to come up with something if you feel it's
needed.
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?
It's just the problem of when will this happen? After the instance is
created or later on, when its injection is completed? Again, as the intent
for this interceptor is not for the general use, it seemed as a reasonable
restriction.
3. What is the behavior of InvocationContext.getTarget prior to the final
proceed()? Does it return null, does it throw IllegalStateException, or ?
null should be fine.
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".
Thanks. Will use it.
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?
The instance won't be created and an exception will be thrown. I'll update
the spec.
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.
OK. Thanks.
7. Do interceptors need to be injected as proceed() is called, or is there
freedom to inject them all, then invoke them all?
Interceptors get injected with dependencies? Do you mean this: "The
AroundConstruct lifecycle callback is invoked after the dependency
injection has been completed on the interceptor instance."? It should be
"instances".
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.
Thanks again,
-marina
-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