Community
Participate
Working Groups
Build Identifier: 3.2.maintance I am looking at the code below in the Server.ResouceChangeJob#run(). It appears to me that a publish will not happen after the structure change if there is no module file changed. A structure change can be recorded in a .XXX file in the project but it doesn't need to be a part of the module. I think it should be published. // run the visitor visit(visitor, null); if (getServerPublishInfo().hasStructureChanged(modules2)) { int newState = getServerPublishState() == IServer.PUBLISH_STATE_FULL ? IServer.PUBLISH_STATE_FULL : IServer.PUBLISH_STATE_INCREMENTAL; setServerPublishState(newState); } if (!changed[0]) return Status.OK_STATUS; if (getServerState() != IServer.STATE_STOPPED && behaviourDelegate != null) behaviourDelegate.handleResourceChange(); if (getServerState() == IServer.STATE_STARTED) autoPublish(event); return Status.OK_STATUS; Reproducible: Always
Created attachment 210620 [details] v1.0 a potential fix.
Without the fix, the tools may fail to do an auto publish when it is needed. The server in server view is shown as Republish but the auto publish will never happen until a manual click on the publish button or a resource change occurs. The work-around to this problem is to click on the publish button in the server view to start a publish. The fix is to set the change[0] flag to true when a structure change is detected. This tells the server there is something changed and need to do an auto publish. The fix has been reviewed and tested. When a structure change of a module happens, the server should start a publish. This is how the server should behave. The change is simple and risk associated with the fix is low.
- Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. As an adopter, without the fix, my tools may fail to do an auto publish when it is needed. The server in server view is shown as Republish but the auto publish will never happen, which will confuse my users. - Is there a work-around? If so, why do you believe the work-around is insufficient? Yes. The work-around is to click on the publish button in the server view to start a publish. Again, this will make the users wonder why a publish doesn't happen when auto publish is enabled. - How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? The test was done using a debugger with my server adopter. It works as I expected. - Give a brief technical overview. Who has reviewed this fix? The fix is to set the change[0] flag to true when a structure change is detected. This tells the server there is something changed and need to do an auto publish. Elson Yuen has reviewed it. - What is the risk associated with this fix? The change is simple and risk associated with the fix is low. It is how the server should behave.
Auto-publish is one of the core function on the server tools support. There were a couple of feedback from the adopters before that there are multiple places for disabling auto publish. Although there is a workaround on this problem, some users may find it confusing and get confused and try to look for ways to enable the auto publish function when they see this error. Given that the change is very simple (one liner) and fairly low risk, I am marking this for PMC approval.
I am personally fine with this, but won't vote one way or the other, and hopefully some others have stronger opinions. It seems like a the right fix, to an important bug ... but it is very last minute for a bug which is not a regression and for which there is a work around. It'd be ideal to hear from some other major "server adapter providers" (oracle? redhat? sap? (libra?) ) to give a voice of support ... though I know time is short, so I am not saying that is required. Just my 2 cents. I'm fine either way.
Our experience is also that the auto-publishing is often unpredictable when will be triggered, which leads to lots of user confusion. Any improvements in this direction are welcome. IMHO, having the low risk, this patch should go in SR2.
I think this is a good change - approved
Changes released to 33M and HEAD
Marking this as resolved as the changes has been dropped.
