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

[Carlo de Wolf]

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)

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?)

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.

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).

The underlying requirement is really: all services needed for an eager 
singleton MUST be available before the singleton is instance is initialized.

SLSB - Services - bullet #2
This does not solve a circular dependency.

@Stateless A { @EJB b; } @Stateless B { @EJB a; }

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?

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.)


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.

Carlo