For instance, once EJBs are a child DU of a WAR, I won't be able to add input/output patterns like:
input: JBossWebMetaData, EJBMetaData
Or will I?
I don't see a problem with it.
The problem is that JBossEnterpriseBeanMetaData will be in a component unit of the war deployment unit.
Then again the input is only used for ordering, the actual existence of it still has to be checked.
So most likely specifying JBossWebMetaData and JBossEnterpriseBeanMetaData will set you at the correct position and then modifying JBossWebMetaData on the parent should work out.
So inner most is done? EJB metadata will be created before the WAR goes through its deployment cycle?
JAX-RS needs to scan for EJBs within a WAR that might expose JAX-RS endpoints. Right now, EJBs are in the same DU as the WAR. The question I have is, what happens when EJBs become a child DU of the WAR? I need to scan EJB metadata and then, if it has JAX-RS metadata, modify JBossWebMetaData.
Are DUs deployed inner-most first?
Why would the EJBs be in a child DU? WARs don't have child DUs. See WARStructure.
WEB-INF/lib/*.jar are not subdeployments they are just part of the WAR's classpath.
To answer your last quest (probably redundant?), you can decide what order the DUs are passed to your deployer, see
Deployer::isParentFirst() which returns true by default from AbstractDeployer.
I think we have a misunderstanding here. :-)
Bill is asking about EjbMetaData, where Carlo is already talking about its components - JBossEnterpriseBeanMetaData.
As I don't understand what exactly are you interested in, I'll answer in a more generic way.
By default we handle parent deployments first.
But there is a flag that you can set on the deployer to handle children first.
By simply stating inputs you only affect the order. There are required inputs which also affect the actual usage of the deployer.
I know we should handle ejbs in .wars, but I have no clue on how we actually do that. Carlo?
I think Carlo has a better understanding of what Bill is talking about - terminology problem again. :-)
He is talking about Components rather than SubDeployments.
But that doesn't sound like the right thing to order after?
Ordering after the ComponentDeployer for EJBs would work since it controls the ordering in which the deployers are invoked
(for the whole deployment - parent/child/components).
It's only the mandatory input - setInput() or passed to the constructor - that decides whether to ignore your deployer if it doesn't have it.
The problem with ordering after the ComponentDeployer would be that it is very late. It is when you start doing stuff to the runtime.
Typically you want to get your metadata all sorted out before that, otherwise different parts of the runtime would see different config.
Hehe, this touches exactly my misunderstand of ComponentDeployers. I use them to split meta data, instead of installing runtime components.
Still we should have some sort of composition mechanism on a meta data level. But that would probably be sub-deployments?