Having dependencies on the deployment instead of the actual EJB container makes no sense
to me whatsoever, especially considering the lack of metadata needed to concretely resolve
certain dependencies (@EJB).
So maybe 4 deployers:
1. Parse and create metadata (PARSE)
2. Process anonotations (POST_CLASSLOADER)
3. Instantiate EJB containers and register them. (POST_CLASSLOADER stage, ordered after
annotation processor).
4. Real deployer, process references, create dependency items, install EJB containers with
these dependency items.
If an EJB container has an @EJB/@PC dependency, it wouldn't be affected by an
arbitrary stop/redeploy because it would already know the concrete kernel names it
depended on. Unless of course the user changed the referenced EJB or PC's name, but
we don't have to handle that situation.
For the piecemeal scenario (at least my definitino of piecemeal), we *cannot* support the
scenario of somebody deploying something first, then deploying something that it depends
on 1 hour later and expecting the dependency to be resolved unless the user has defined
adequate metadata to resolve the dependency (i.e. @EJB with only interface as identifying
metadata will not work).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082249#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...