11:43 p.m.
On 12/07/2010 02:35 AM, Carlo de Wolf wrote:
On 12/07/2010 01:08 AM, David M. Lloyd wrote:
> It's at
> http://community.jboss.org/wiki/JavaEEImplementationTechnicalRequirements
> and
> it has a long way to go. Be as critical as you want.
The preceding '/' within java: namespaces is incorrect. It's just
java:global, java:app, java:module and java:comp. (EE.5.2.2)
OK.
JNDI - Service - bullet #2
Does it mean that stuff will only get bound into the java: namespaces
one the actual service is ready? (the EJB is invokable?)
No, the intent is like we talked about: the binding can happen first,
and things depend on the binding. If a binding is used before it is
ready it has one of several possible outcomes:
1. If the service is still coming up, wait for it to finish.
2. If the service is missing, error.
3. If the service is there but has failed, error.
This seems to be about the best we can do due to the required two-phase
nature of EJB startup.
Interceptors
A short amendment:
For the purpose of providing system functions on EJBs, like
transactions, security etc, system interceptors are added the normal
interceptor chain of an EJB. These system interceptors effectively form
a extra layer above the default interceptors and take no note of the
regular exclusion directives like @ExcludeDefaultInterceptors or
@ExcludeClassInterceptors.
Ah okay. Does this mean that these interceptors cannot be disabled
globally, at all? If so, I'll make note of that.
Singletons - Services - bullet #2
If the singleton is an eager singleton (EJB 3.1 FR 4.8.1), the service
MUST have an *explicit* dependency on all services that are injected
into the singleton (EE.5).
OK, so the user has to specify them?
The underlying requirement is really: all services needed for an
eager
singleton MUST be available before the singleton is instance is
initialized.
That is the intent of the rule, but I may have got it wrong in the
requirements.
SLSB - Services - bullet #2
This does not solve a circular dependency.
@Stateless A { @EJB b; } @Stateless B { @EJB a; }
You're right, the dependency should be on the JNDI binding (first
phase). I'll make that correction.
SFSB
Do you want to add a requirement on initialization in the same thread as
the lookup? Or do you want to explicitly add it as a non-requirement?
I implied it via #5's note, but for now I'd prefer to leave it
unspecified until we can be sure it will work 100% of the time.
MDB - Service - bullet #2
Each MDB services MUST have a dependency on all services that are
injected into it.
(Only after those are available, endpoint activation must occur.)
That's the point of bullet #3 on that item. I didn't order the
resolution that way though, because I had assumed that the endpoint
activation is something outside of the control of the EJB layer (i.e. it
comes from JCA as a message inflow thing of some sort). I suppose this
rather implies a different dependency relationship: the MDB doesn't
depend on the endpoint activation; rather, the endpoint activation
depends on a consumer (the MDB) being available (which makes much more
sense, now that I think of it). I can make that change.
I'm not sure whether this will actually solve the problem of the
dependency chain. Basically you can define a state for a component where
its bindings are up, but not yet capable of being looked up (SFSB and
Singleton) plus a state where it's bindings are up, but not yet
invokable (SLSB lazy proxy). We might need to have such constructs for
all EE injectable resources.
Yeah that's what I'm getting at. The possibility of circular deps is
what makes it interesting. The problem is that it's hard to detect all
possible errors (including initialization errors) in all EE resources
before their dependents are ready to execute. So something may come
"up" (on the assumption that because the JNDI binding was successful,
the component will become available) only to fail during initialization
or usage when the dependency itself fails to initialize for some reason.
But, it looks like this two-phase setup is probably the most elegant
solution allowed by the spec in any case.
I'll make the changes, keep the comments coming...
--
- DML