STS 3.0 M2 not publishing to tc Server after resource change

[adrians]

I'm having a problem with STS not re-publishing a newly created Grails app (2.0.4) when I modify a resource. The tc Server definition is set to 'Automatically publish when resources change' as per default. There is no console activity for tc Server when I save a modified file. In the servers view, when I save, I see the app status change from [Synchronized] to [Republish] and back to [Synchronized] and the tc Server status from [Started, Synchronized] to [Started, Restart] upon saving.

The only, possibly relevant, thing I see in the log output is this:

WARNING: [SetContextPropertiesRule]{Context} Setting property 'source' to 'org.grails.ide.eclipse.runonserver.GrailsAppModul eFactory:testgrails' did not find a matching property.

This is under Windows 7 64 bit, jdk 1.7.0_05.

Any advice?


Thanks,
Adrian

[Kris De Volder]

Hi Adrian,

The server status infos from WTP aren't really to be relied upon. What you describe there is pretty much what I'd expect.
I.e. wtp suggesting that maybe you need to restart the server. But you can ignore that.
However the real question is whether your changes become live on the deployed instance. They should, even without server restart. But I take it this isn't happening for you or you wouldn't be posting this.

The way a grails app gets deployed to the tc server instance is a bit complicated and it tries to determine based on the type of change it sees in your project how/if to update it on the server.

Likely you are hitting a bug in this updating logic. To be able to reproduce it on my end, can you provide some more details. The particulars matter a great deal here. I.e. what exactly is the change (what resource, is it a html file? a gsp file? a groovy file), how is your app deployed (which env is selected in the projects property page env, prod etc) is the 'incremental war build' option enabled on the project.

Does this happen for any kind of change you make, or can you discern a pattern (i.e. specific kind of change that does / doesn't work).

I want to help (and try to get this fixed) but you have to give me some more specific info to work with.

Kris

PS: WARNING: [SetContextPropertiesRule]{Context} Setting property 'source' to 'org.grails.ide.eclipse.runonserver.GrailsAppModul eFactory:testgrails' did not find a matching property.

I've seen this message as well on occasion. I don't think it is connected with the problem.

[Kris De Volder]

PS: Did you check the eclipse error log for possible errors as well (I think the error that you mentioned is from the tc server console log). This error log is often overlooked and a bit hard to find. If you didn't check it yet, you can open it via menu "Windows >> Views >> Other >> Error Log").
If some error happened in the deploy/update logic something useful may have been logged there.

[adrians]

Hi Kris,

The problem I saw was with index.gsp, produced as the initial default view of a newly created Grails 2.0.4 project. The app was deployed by right-clicking on the server in the servers view and adding it to the tc Server instance. Everything is out of the box here, STS (3.0 M3 now, after an update), Grails 2.0.4 (downloaded myself, not through the dashboard), added as an installation in preferences. tc Server is 2.7.0 - the version that shipped with STS 3.0 M2. The app in question was not modified in any way from what the Grails new project wizard produced.

You should see that if you make any changes to index.gsp, there will not be any server console output indicating a re-publish. Also, the error view doesn't show anything either.

Can you reproduce it with this info?

[Kris De Volder]

Yes, it looks like indeed I can reproduce it. Thanks for providing all those details!

I fairly regularly test very similar scenarios with gsp files that are created by using the grails commands to generate controllers and views. That works just fine... But when I do the same with the index.gsp that is already there it does *not* publish the changes.

I say that is definitely a somewhat serious bug and we should raise a bugreport. I'll do it shortly and post back a link here.

It is good we caught this now, there's still time to fix it for 3.0.0 release.

Kris

EDIT: Jira issue raised here: https://issuetracker.springsource.com/browse/STS-2743