[ https://jira.jboss.org/jira/browse/JOPR-94?page=com.atlassian.jira.plugin... ] Heiko W. Rupp updated JOPR-94: ------------------------------ Description: TC5: war file create works, but war does not show up in inventory of the parent vhost See screen shot. War file is attached I've verified that the war file is indeed deployed by calling its url in tomcat ( http://fedora9:8080/test-simple/ ) was: See screen shot. War file is attached -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JOPR-94?page=com.atlassian.jira.plugin... ] Jay Shaughnessy reassigned JOPR-94: ----------------------------------- Assignee: Jay Shaughnessy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JOPR-94?page=com.atlassian.jira.plugin... ] Work on JOPR-94 stopped by Jay Shaughnessy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JOPR-94?page=com.atlassian.jira.plugin... ] Jay Shaughnessy commented on JOPR-94: ------------------------------------- My guess in the above comment looks pretty much right. In the past the server, when completing a successful create operation, would create the new resource and mark it committed. But, this was changed due to JBNADM-3451. Now we rely on the plugin container running a service scan on the parent of the new resource, and letting auto-discovery do the work. This approach has a couple of weaknesses that are brought out in this use case: 1) The scan runs immediately after the plugin returns. In this case the scan may run before Tomcat has picked up and deployed the newly deployed webapp in the docbase dir. So, the mbean does not yet exist. The scan does not discover the app until the next scheduled, or manual, discovery. 2) A worse scenario is if the vhost is not configured for autodeploy. This means the physical app is deployed but the vhost ignores it until the next vhost start. In both cases we end up with no resource server-side instead of a new, but down, resource. My proposals are this: 1) Fail the create if autodeploy is not turned on for the vhost. Supply an error message to that effect so the user knows why it failed. 2) Wait for the the mbean to show up before returning from the plugin's create resource impl. This should solve #1 in most cases. Although, some sort of max wait will have to be put in place (any suggestions? maybe 1 minute?) Is there any sort of other timeout already in place that would limit our ability to wait?) If the max wait expires just return success and live with this situation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira