[ https://issues.jboss.org/browse/WFLY-1759?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-1759: --------------------------------------- More on expected behaviour after modification of a value for a field that requires re-load upon change: <psakar> asoldano, ping <asoldano> psakar, pong <psakar> asoldano, question for you. In following scenario what will be status of deployment ? I will deploy war with webservice, remove webservice subsystem and do reload <asoldano> psakar, I believe that when you remove the webservices subsystem, the deployment would be stopped, but never tried <asoldano> psakar, a ws deployment without the webservices subsystem enabled is basically a jar or war deployment, so possibly a webapp with potentially no pages or a simple library deployment <asoldano> psakar, it really depends on the contents <asoldano> psakar, the deployers contributed by the ws subsystem are basically sensible to ws descriptors and annotations <asoldano> psakar, those would go un-noticed <psakar> asoldano, existing deployment works until reload, new deployment before reload is deployed but wsdl not accesible (wrong, but at this moment probably as designed), after reload both deployments are ok, no ws available (OK) <asoldano> psakar, is the new deployment with wsdl not accessible issue related to JBWS-3671? <psakar> asoldano, no. it's deployed before reload (but after removal of ws subsystem) <asoldano> psakar, ok, then I'd probably need to try that, to understand why the wsdl wouldn't be available <asoldano> psakar, this said, as part of the WS subsystem removal I could probably stop the main WS service which would cause all ws deployment to stop, if that's the required behaviour <asoldano> psakar, we really never thought about these things <psakar> asoldano, I'll try to document it / create test cases. I've talked to rsvoboda and the approach at this moment probably would be write in official documentation the deployments before reload are possible but can result in undefined state and thus are not recommended. But generally it should be addressed somehow <asoldano> psakar, +1 <rsvoboda> asoldano, psakar maybe changes in management model will be needed to fix it properly <asoldano> rsvoboda, they will definitely we required <rsvoboda> asoldano, and can it be inforporated / suggested to WF 8 or the train is gone for such changes ? <rsvoboda> s/inforporated/incorporated/ <asoldano> rsvoboda, it depends on the how much change it will require. We can create a jira now and me or Jim will have a look <asoldano> rsvoboda, might be doable for WFLY 8 <asoldano> rsvoboda, depending on how much time TCK7 takes, etc. <psakar> asoldano, rsvoboda - I would propose for start of discussion following solution: Changes which require reload should not immedially change value in DMR, but should be kept in "pending value". During reload pending value should replace the value and be cleared. Option to allow / disallow such behavior should be introduced for backward compatibility. <psakar> Advantages: <psakar> - admins will be able to see pending changes <psakar> - all operations caried on before reload will use the proper values <psakar> - revert pending value can clear reload required <psakar> Disdvantages: <psakar> - compatibility - can be handled by option to allow / disallow such behavior <psakar> - requires DMR change <rsvoboda> asoldano, psakar sorry, I have to focus on second chat I'm on, agree with Petr's proposal <asoldano> psakar, rsvoboda, looks reasonable <psakar> asoldano, can you then create ticket or shall I do it ? <asoldano> psakar, that would still go under WFLY-1759 <psakar> asoldano, can you then append it please ? thanx <asoldano> psakar, I'm attaching our discussion here to the jira -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira