Deployer order solely based on inputs/outputs now?

[bill.burke]

Is deployer order solely based on inputs/outputs now? If so I believe I have a serious problem. I don't think the current approach in the EJB3 container of creating DependencyItems and RegistryPlugins is going to work. The main reason is that the @EJB annotation (and ejb-ref XML metadata) is incomplete. It does not have enough information to correctly define the dependency.

This is why there were two deployers: EJBRegistrationDeployer and EJBStage2Deployer. Registration was supposed to work first on all deployments before Stage2. Stage2 would be able to determine the "REAL" dependencies by searching for @EJB refs (and @PersistenceUnit refs for that matter) based on:

1. Look in the jar first for the reference
2. Look in the EAR
3. Look globally

EE6 will complicate things further as EJB jars will be deployable within WARs.

Do you see the problem I'm getting at? Since @EJB is incomplete, it could be possible for it to resolve to something it is not supposed to. Some links to WIKI or forum posts would be helpful. (and no adrian, google doesn't always work as you have to know what to search for).

thanks

[bill.burke]

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]

The only thing about this is that there would need to be a

JavaEEDescribeDeployer that would need to work with EJBs, Servlets and any other EE component that uses EE XML/annotation component references.

[wolfc]

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

[wolfc]

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

[adrian.brock]

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.

It has to be real dependencies, no "flow" or ordering of deployers is going to
solve the problem where deployments are deployed piecemeal, i.e. not at
the same time, or even worse (more complicated)

* redeployed
* one of the transient dependencies is missing and deployed later

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

The JNDI plugin to the MC registry is stupidly inefficient, it's ok as an
early hack to try out the idea.

A DependencyItem that does the same thing, but only for those you expect to
be JNDI dependencies is much more efficient.

[bill.burke]

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

[adrian.brock]

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

I know.

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.

You can make a DependencyItem do whatever you like, e.g. just delegate
to the EJBContainer to do all the work.

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.

EAR subdeployments are always going to piecemeal unless you make
them wait for their dependencies.
If its non-deterministic then nothing is going to work, its just random.

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.

I'm not saying you should. I'm saying you create a dependency that is relevant
to what the user requests. If they say mapped-name then that is more specific
and should respected over whatever heuristic rules you use otherwise.

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

Not done, yet...
http://jira.jboss.com/jira/browse/JBMICROCONT-81
Ales has been concentrating on what most people will actually use
in the documentation.

There's many examples though, e.g. the deployment dependencies
I added for OSGi a few weeks ago:

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=64469

Mapping of OSGi requirement to MC dependency (currently only modules and packages
are implemented as requirements)
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontainer/trunk/deployers-impl/src/main/org/jboss/deployers/plugins/classloading/RequirementDependencyItem.java?view=markup&pathrev=64469

[bill.burke]

EAR subdeployments are always going to piecemeal unless you make
them wait for their dependencies.
If its non-deterministic then nothing is going to work, its just random.

1. Parsing deployer runs generating metadata for each EJB in the EAR
2. Describe deployer runs adding dependency metadata for each EJB
3. Component deployer runs, creating EJB beans with "real" kernel dependencies based on metadata in step #2.

Again, this would be for @EJB and @PC refs that do not have a mapped-name defined. Metadata refs with mapped-name specified don't have the ambiguity that @EJB and @PC might have that don't have mapped-name defined.

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.

[alesj]

What triggers it. If i know this information, then I can proceed.

Any addition (e.g. new install) to Controller triggers this:

 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;
 }

[alesj]

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;
 }

btw: you can always check the code for more details ;-)

[adrian.brock]

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.

I'll answer your question with some psuedo code that describes the MC algorithm :-)

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();
 }
 }
}

Of course the real implementation is more complicated because of ControllerMode, multithreading, recursion and error handling, but that algorthim is effectively all the MC does.

So you can see it will check dependency items for every context that is not in a
fully installed state when somebodyinstalls a new context.
But only those dependency items that lead to the next state.

[adrian.brock]

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.

I should also point out that with the latest rev of the deployers, the deployment
dependencies are implemented on the whole deployment.

i.e. adding a dependency on an ejb subdeployment of ear will actually be
a dependency for the whole ear.

So if the describe deployer adds a dependency saying don't move to the "REAL"
stage until java:/DefaultDS is deployed, nothing in the EAR will move to "REAL"
until that is done.

In that sense, it can't be piecemeal if you have real dependencies on the deployments.

[bill.burke]

You're talking about DeploymentUnit dependencies, not components, right? So, if I create dependencies on the EJB container itself, rather than the deployment I'll be ok.

[bill.burke]

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