[wildfly-dev] Completion of DeploymentUnitProcessor.deploy(ear, war1, war2) observed in a subsequent phase?
Brian Stansberry
brian.stansberry at redhat.com
Tue Sep 18 15:39:11 EDT 2018
The DUPs in each Phase are executed in the start method of an MSC Service
that represents that Phase for that deployment.[1] The start method
executes the DUPs associated with the phase and then installs the service
for the next phase.
So, all DUPs for PARSE will have run before any DEPENDENCIES DUPs are run.
[1]
https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentUnitPhaseService.java#L85
On Tue, Sep 18, 2018 at 11:01 AM, Peter Palaga <ppalaga at redhat.com> wrote:
> Hi *,
>
> I cannot find any info about what (if any) are the guarantees for
> ordering and exit of DeploymentUnitProcessors (DUPs) in case of an EAR
> that contains multiple WARs.
>
> I have a situation like this: MyDUP1 is registered for Phase.PARSE and
> MyDup2 is registered for Phase.DEPENDENCIES.
> I can see from the logs that MyDUP1.deploy(ear),
> MyDUP1.deploy(ear.war1), MyDUP1.deploy(war2), etc. are executed by
> distinct threads which is perfectly OK.
> I'd like to know if there is any guarantee that MyDup2.deploy(*)
> observes the completion of MyDUP1.deploy(ear), MyDUP1.deploy(ear.war1),
> MyDUP1.deploy(ear.war2), etc.?
>
> MyDUP1.deploy() collects some info from the EAR and the WARs and stores
> it as an attachment of the DeploymentUnit. MyDup2.deploy() is supposed
> to read that attachment and so it is important that the info is complete
> when MyDup2.deploy() reads it.
>
> Thanks,
>
> -- Peter
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180918/d0375603/attachment-0001.html
More information about the wildfly-dev
mailing list