Deployment phase context dependencies and runtime changes to services

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Deployment phase context dependencies and runtime changes to services

Jaikiran Pai
I've got a DUP in Phase.PARSE which attaches a service attachment to the
DU by adding a dependency on to the next phase context:

phaseContext.addDeploymentDependency(ServiceName.Foo, myAttachmentKey);

Works fine. The attachment which points to a service is available in the
next phase from the DU. When I deploy a deployment, it passes through
these phases and deploys fine. Now at runtime I use the CLI to change a
writeable attribute's value which triggers a
change/update/reinstallation of the ServiceName.Foo. That's when I start
seeing problems. Due to the stop/start of the ServiceName.Foo service,
the already fully deployed deployment is re-deployed starting from
Phase.MODULE (and skipping the previous phases) because of the
dependency that was added to the phase context on this service. This
causes a whole lot of issues (like missing attachments) because the
deployment has re-started midway through the phases.

The javadoc of DeploymentPhaseContext.addDeploymentDependency says:

/**
  * Adds a dependency on the service to the next phase service. The
service value will be make available as an attachment to
  * the {@link DeploymentUnit}. This attachment will be removed when the
phase service for the next phase stops.


So should the dependency on the ServiceName.Foo be retained even after
the phase service has completed for the deployment unit? Is this a bug
or the expected behaviour? I wouldn't expect a re-deployment of a
already deployed unit because of changes to a service which is no longer
relevant after the deployment unit has been processed.



-Jaikiran
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment phase context dependencies and runtime changes to services

Jason T. Greene
I thought the original intention of that method was to add a dependency to the deployment unit service and not the phase, since there are other methods which operate on the phase. Well, in any case, you don't want to manipulate phase services because they are temporary, and only used to coordinate deployment activity. Instead, for permanent services, what you want to do is to build the dep tree off of the deployment service (or a child). Management ops should just control that.

On Jan 27, 2012, at 11:05 PM, Jaikiran Pai <[hidden email]> wrote:

> I've got a DUP in Phase.PARSE which attaches a service attachment to the
> DU by adding a dependency on to the next phase context:
>
> phaseContext.addDeploymentDependency(ServiceName.Foo, myAttachmentKey);
>
> Works fine. The attachment which points to a service is available in the
> next phase from the DU. When I deploy a deployment, it passes through
> these phases and deploys fine. Now at runtime I use the CLI to change a
> writeable attribute's value which triggers a
> change/update/reinstallation of the ServiceName.Foo. That's when I start
> seeing problems. Due to the stop/start of the ServiceName.Foo service,
> the already fully deployed deployment is re-deployed starting from
> Phase.MODULE (and skipping the previous phases) because of the
> dependency that was added to the phase context on this service. This
> causes a whole lot of issues (like missing attachments) because the
> deployment has re-started midway through the phases.
>
> The javadoc of DeploymentPhaseContext.addDeploymentDependency says:
>
> /**
>  * Adds a dependency on the service to the next phase service. The
> service value will be make available as an attachment to
>  * the {@link DeploymentUnit}. This attachment will be removed when the
> phase service for the next phase stops.
>
>
> So should the dependency on the ServiceName.Foo be retained even after
> the phase service has completed for the deployment unit? Is this a bug
> or the expected behaviour? I wouldn't expect a re-deployment of a
> already deployed unit because of changes to a service which is no longer
> relevant after the deployment unit has been processed.
>
>
>
> -Jaikiran
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev