Pete Muir wrote:
We also discussed in some detail the contract imposed by A2. Session
Bean Interceptor
http://docs.jboss.org/webbeans/reference/snapshot/en-US/html/ri-spi.html
ALR said that he would prefer us to register for lifecycle callbacks
from the EJB container programatically, rather than use an EJB interceptor.
I raised this point to address a portable mechanism for JSR-299 to
integrate with EJB Implementations, where 299 is an add-on
(consumer/client) atop EJB3. If that's left out of scope as Ken
suggests, any vendor-specific way to get the job done should suffice.
Especially in the case of JBoss WebBeans, which is solving the problem
without touching the EJB3 codebase (==good).
I'll think about the API for this later today, but in essence we
would
pass an extra object as part of the resolveEJB call above, which would
implement some callback interface in the Web Beans SPI that allowed us
to listen for at least postConstruct, preInvokeBusinessMethod and
preDestroy. The JBoss-Web Beans integration project would then have to
decorate this with an interface JBoss EJB knows about, and somehow pass
it to JBoss EJB3 for registration.
ALR, do you think we need to do this for the 1.0 of Web Beans, or can
address it for 1.1? I certainly agree that programmatic registration of
an interceptor is less brittle than the current ThreadLocal approach,
but if we can get away with the ThreadLocal for now, it gives us more
time work on a good SPI.
The current mechanism should be good for the time being. My concern is
in imposing upon other vendors a specific implementation approach.
To that end, there are a few impositions the 299 spec defines that are
outside of the EJB spec, and I'll raise those points in a more
appropriate forum (the public webbeans-dev-list)
* SFSB remove() bypassing business method @Remove
* 299 injection inbetween backing object instance creation and
@PostConstruct (violating the client view)
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com