[jboss-as7-dev] First cut of EE tech requirements doc

[David M. Lloyd]

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