Yes, and I want each deployer to use a clean SPI. So no use of InjectionContainer which is too bloated. But one created in projects/integration based on the org.jboss.ejb3.javaee interfaces.

After the describe phase each JavaEEComponent should be able to answer the questions in the interface.

(I don't like the createObjectName methods. Maybe getComponent(name) on JavaEEModule level and getModule(name) on JavaEEApplication. If we add generics we could even specify what kind of components are in the module. Hmm EE 6 clash, getComponent(name, type).)

http://jira.jboss.com/jira/browse/EJBTHREE-811

"bill.burke@jboss.com" wrote:
Ok, after talking to Ales I think i get it.

There would be:

EJBParserDeployer
EJBDescribeDeployer
EJBComponentDeployer

So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right?

"bill.burke@jboss.com" wrote:

he real solution is to create your own DependencyItem implementation
like I've been telling you to over a year now.

And I've been telling you that EE injection requirements are not simple...

Are you sure the DependencyItem stuff will work since EJB and PC ref's metadata may be incomplete or even ambiguous? Does a DependencyItem get queried EVERY TIME any arbitrary thing is deployed or when ANY arbitrary thing changes state within the MC? I also worry about a dependency item matching and picking up the wrong reference because an inner deployment scope hasn't been processed/deployed yet.

I don't understand why I have to add the dependencies to the deployment to make this work. The subdeployments of an EAR are not going to be deployed piecemeal.

Also, we're not going to make configuration more complicated for the user for the edge cases 90% of people don't care about. Meaning, we're not going to require a mapped-name with @EJB or @PersistenceContext refs. i.e. requiring them to specify a mapped-name.

Where is there documentation on how dependency items work? The Javadoc isn't very helpful ;-)

"bill.burke@jboss.com" wrote:
What triggers it. If i know this information, then I can proceed.

 Set<ControllerContext> unresolved = contextsByState.get(fromState);
 Set<ControllerContext> resolved = resolveContexts(unresolved, toState, trace);

 protected Set<ControllerContext> resolveContexts(Set<ControllerContext> contexts, ControllerState state, boolean trace)
 {
 HashSet<ControllerContext> result = new HashSet<ControllerContext>();

 if (contexts.isEmpty() == false)
 {
 for (ControllerContext ctx : contexts)
 {
 if (advance(ctx))
 {
 DependencyInfo dependencies = ctx.getDependencyInfo();
 if (dependencies.resolveDependencies(this, state))
 result.add(ctx);
 }
 }
 }

 return result;
 }

Plus this:

 public boolean resolveDependencies(Controller controller, ControllerState state)
 {
 boolean resolved = true;
 if (unresolved.isEmpty() == false)
 {
 for (DependencyItem item : unresolved)
 {
 if (state.equals(item.getWhenRequired()) && item.resolve(controller) == false)
 {
 resolved = false;
 break;
 }
 }
 }
 return resolved;
 }

"bill.burke@jboss.com" wrote:

FYI, my question on DependencyItem is simple. When does it get invoked upon. What triggers it. If i know this information, then I can proceed.

whenSomebodyInstallsANewContext()
{
 registerItInNotInstalledState();

 // Go through all the states from NOT_INSTALLED TO INSTALLED

 for (ControllerState state : allStates)
 {

 // Go through all the contexts at the current state

 List<ControllerContext> contexts : getContextsInState(state);
 for (ControllerContext context : contexts)
 {
 List<DependencyItem> items = context.getDependencyInfo().getDependencies(context.getNextState());

 // See whether the depenencies are resolved

 boolean readyToGoToNextState = true;
 for (DependencyItem item : items)
 {
 if (item.resolve() == false)
 readyToGoToNextState = false;
 }

 // If they are bump it to the next state

 if (readyToGoToNextState())
 doIt();
 }
 }
}

"adrian@jboss.org" wrote:

"bill.burke@jboss.com" wrote:
Ok, after talking to Ales I think i get it.

There would be:

EJBParserDeployer
EJBDescribeDeployer
EJBComponentDeployer

So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right?

This can only work if you add the dependencies to the deployment rather than
the ejb instance. The same way OSGi dependencies work.