The
http://jira.jboss.com/jira/browse/JBAS-4684 issue is due to the ServiceDeployer.deploy
method not seeing the deployment error. This is due to the
AbstractController.incrementState uninstalling context with errors:
| ...
| finally
| {
| lockWrite();
| if (error != null)
| {
| log.error("Error installing to " + toState.getStateString() +
": " + context.toShortString(), error);
| uninstallContext(context, ControllerState.NOT_INSTALLED, trace);
| errorContexts.put(context.getName(), context);
| context.setError(error);
| return false;
| }
| }
|
AbstractControllerContext.uninstall(ControllerState fromState, ControllerState toState)
clears the error state, and the ServiceContext problem is nulled out when the
CreateDestroyLifecycleAction.uninstallAction calls getServiceContext:
| public ServiceContext getServiceContext()
| {
| try
| {
| serviceContext.proxy = getServiceProxy();
| }
| catch (Exception ignored)
| {
| }
| serviceContext.setProblem(getError());
| if (getState() == ControllerState.ERROR)
| serviceContext.state = ServiceContext.FAILED;
| return serviceContext;
| }
|
The context after the ServiceDeployer.deploy calls start(context), the context is in a
DESTROYED state, but has no problem set:
| ObjectName: jboss.web.deployment:war=/custom-context
| State: DESTROYED
|
Because of this, the MainDeployer.checkComplete call has no information about the failed
deployment. If I just fail to null out the ServiceContext.problem then the deployment
failure propagates as expected.
However, it seem like we should not be able to transition out of the ERROR state to
DESTROYED?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083243#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...