[
https://issues.jboss.org/browse/AS7-783?page=com.atlassian.jira.plugin.sy...
]
Brian Stansberry resolved AS7-783.
----------------------------------
Fix Version/s: No Release
(was: 7.1.0.CR1)
Resolution: Won't Fix
I'd just make this "Open to Community" but my inclination would be to reject
such a change anyway, so I don't want to mislead people.
If deployments are not done in a batch, and 2.jar depends on 1.jar, 2.jar will fail if the
scanner deploys it first. And the user will have no way out, unless we start adding in all
that terrible pluggable deployment sorting logic we had in AS < 7.
Deployment scanner service should use a separate operation for each
deployment
------------------------------------------------------------------------------
Key: AS7-783
URL:
https://issues.jboss.org/browse/AS7-783
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Fix For: No Release
The scanner is creating a single composite op for all deployments encountered in a scan,
rather than individual ops. The effect is failures in on deployment results in rolling
back the others.
This makes some sense when users change things after startup, since multiple changes
within one scan are probably related to each other. But it's not the correct behavior
at startup, since multiple apps may not be interrelated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira