-
15. Re: Deployers and service dependencies
"alesj" wrote:
This looks OK.
What's the error?
Actually no. :-)
I think I see what the problem might be.
It's the dependency item name.
If unit != top unit, this won't point to the right MC component.
You need to pass in the name of top deployment unit.
But if you do it as I suggested, this is already taken care of.
Another good example of why re-usage is good.
(if only there were docs ...) :-) -
16. Re: Deployers and service dependencies
I would just create a proper version of DependenciesMetaData,
leaving its deployment to DependenciesMetaDataDeployer and DeploymentDependencyDeployer.
Simply create DependenciesMetaData as a deployer output?
Is that already available in 5.0.0.GA? -
17. Re: Deployers and service dependencies
If unit != top unit, this won't point to the right MC component.
You need to pass in the name of top deployment unit.
You right. I'll check. I think the deployer picks up subdeployments. -
18. Re: Deployers and service dependencies
Great, it works. You'd been right. It depends on the units top level name.
-
19. Re: Deployers and service dependencies
"heiko.braun@jboss.com" wrote:
Simply create DependenciesMetaData as a deployer output?
Yes, and as an attachment.
That way you don't have to bother with other details.
What you want is to create your own dependency items,
how this maps to deployment can (almost) be considered impl detail.
e.g. this way you wouldn't use the wrong name - which is deep impl detail in AbstractController::undeploy"heiko.braun@jboss.com" wrote:
Is that already available in 5.0.0.GA?
Sure. -
20. Re: Deployers and service dependencies
"heiko.braun@jboss.com" wrote:
Great, it works. You'd been right. It depends on the units top level name.
Ever doubted? ;-)