When we disable reloading, classes are still being recompiled upon changes in dev environment.
File /....../grails-app/controllers/test-app/org/foo/UrlMappings.groovy changed, recompiling...
Why does this happen?
Grails 3/4/5
Related
is there any best practice how to update from Vaadin 14.4.x to Vaadin 14.6 or Vaadin 14.7?
Just updating the dependency's will cause that fonts do not look same anymore.
Also the switch to dark mode also does nor work anymore (https://vaadin.com/learn/tutorials/toggle-dark-theme).
As soon as I switch back to 14.4.x all works again.
I am using Java only no Spring.
Do I need to delete any cache or something? I deleted the frontend folder already, but that does not resolve the problem.
First of all, I'm sorry to ask a somewhat vague question but I'm only doing it because I'm clueless to what might be causing the problem.
I've been building an app with Sprite Kit and it has worked great. I've made some additions to code at suddently I see a dramatic decrease in performance. I have rolled back all my code changes but the performance didn't go up. I'm left clueless to what's wrong.
After hidious debugging I've noticed that the performance problem only affects run and test builds. If I do a profiling build, the app behaves as normally = with high performance. So this would suggest that my problem is somewhere in the build configuration but I'm completely new to ios build environment configurations.
Can anybody suggest what might be the cause of this? Where should I start looking? I have my background in Java 5 and the compiler and other settings are quite strange to me.
The default setup is to have a Debug config and a Release config, where Debug is configured with no optimizations, and Release does include optimizations. Optimizing often makes it hard to use the debugger, which is why unoptimized code is preferred there.
By default, Run, Test, and Analyze use the Debug config, Profile and Archive use the Release config. Your change in behavior could come from lots of differences: you may have had it configured before to build for Run in Release mode. You may have had a subproject built in Release mode that is now in Debug. You may have made a coding change that is very slow unless the optimizer is used. (Since you say you rolled back the code, this last one is unlikely, but check your version control and see if you changed any project settings.)
If you're seeing weird "it wasn't like that before" behavior when you think you've put everything back, make sure you're rebuilding everything. Delete your Derived Data directory. You can determine where it is in Preferences, Locations. "Delete your Derived Data directory" is the Xcode-equivalent of "try rebooting." It's the most common way to fix strange "Xcode isn't working right" problems. In fact, I put my Derived Data in /tmp/build so that it gets deleted every time I reboot (and so the path is easier for me to remember).
I am using ASP.NET MVC3, .NET4, Razor, C#, EF4.1, MS SQL2008(dev), SQL Azure(test,live).
I am deploying my web application to "Standard" Azure Websites. My process is:
1) Publish to local IIS folder, no precompilation options selected:
Project C# code is compiled as Project dll and put into "bin" folder.
Views stay as source *.cshtml files
2) FTP changed files to deployment server using Beyond Compare,so
Project DLL gets copied
Source *.cs files (Controllers, helpers, Models) get copied.
Changed source *.cshtml Views getting copied
With the initial call to the deployment server, the response is slow, due to JIT compilation. I suspect this is due to:
a) Views being compiled. Major factor as opposed to project dll??
b) Project DLL already precompiled so no issue here ??? Is this correct.
I try to keep the application pool in memory via pingback services either external monitor sites(Uptime Robot) or MS's "always on" service which is the same. But one can still get app pool refreshes and thus slow downs. It seems to me that everything should be precompiled for deployment so that if dropped from memory then rerunning will be quick.
My question(s)
1) Is my understanding correct about what is precompiled and what is not?
2) What should I do now to maximise precompilation and minimise these app pool refresh penalties, and thus keep performance at it peak ie no start of day warm ups etc. My initial impression is to precompile the Views. I did try editing the Project XML file, and this setting specifically:
<MvcBuildViews>true</MvcBuildViews>
However when I try to publish using the above setting I get an error:
obj\release\aspnetcompilemerge\source\web.config(45): error ASPCONFIG: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
EDIT
Having done a little more research it seems that I need to focus on precompiling the Views for wich 2 main tools exist:
a) RazorSingleFile
b) RazorGenerator
Apparently
<MvcBuildViews>true</MvcBuildViews>
just compiles rather than precompiles. Not sure of the difference. So it is recommended to use one of the tools above.
EDIT2
My main MVC project dll is 890k-ish in size. Is this large? Would the size cause more drop out from memory?
There is a serious rabbit hole when building views. There is some known bug that this particular error happens. The only known if is to use the <BaseIntermediateOutputPath>. This path needs to exist, and not be within the project path (I think). I usually use:
<MvcBuildViews>true</MvcBuildViews>
<BaseIntermediateOutputPath>..\..\tempMVC</BaseIntermediateOutputPath>
The Aspnet Compiler Build Task in Visual Studio 2010 ASP.Net MVC 2 Projects
I am 95% sure that: You can't pre-compile MVC views (cshtml, etc) for deployment (with any default version of Visual Studio, there may be add-ons). There are two separate issues here.
First, <MvcBuildViews> is only a buildtime strongly-typed checker when set to true. Meaning that if you build a view against a specific #model that the compiler will check the view during a build to make sure aren't using the model incorrectly (like trying to use a property on the model that doesn't exist).
Secondly, the notion of pre-compiling a view into an assembly is a process that exists for Webforms because there is a code in-front and code behind that can be combined. Views aren't tied to logic in this way so the compiler hasn't been designed to take MVC Views into account.
OK, my solution was to publish the application.
Then I selected:
Precompile during Publishing
I then clicked on "configure" and then unchecked:
Allow precompiled site to be updateable
I then selected:
Do not merge, create a seperate assembly for each page or control.
This enabled the precompilation of the views, and put them in the bin folder, in the form of:
_orders.cshtml.4deb95a2.compiled
I understand this to be p-code and so will still need a binary compilation on first load on the deployment server. The project dll is worse since it is bigger.
By the way I did encounter quite a few assembly references issues that were caused by old excluded code files. I thought if they were excluded that was good enough, but no..... In the end I just deleted them all and the precompilation completed successfully.
Doing this forced me to fixed quite a few hidden razor errors which would have come out at runtime as opposed to compile time.
I am working on grails 2.0.4 project and at some point I've found that recompilation process does not work. Further tries showed that first run-app after removing ~/.grails/2.0.4 has recompiling process working well, but running run-app next time ignores changes in files during run (no changes on pages and no Compiling… message in log after appears). So my question is how to debug recompilation process?
There's some JIRA issues related to the recompilation:
http://jira.grails.org/browse/GRAILS-8951
http://jira.grails.org/browse/GRAILS-8573
http://jira.grails.org/browse/GRAILS-8914
Only the third one is fixed. Looking in the first, some folks said that this not work:
grails run-app
But entering in the interactive mode works:
grails
run-app
Looking a bit in the code, I can see that GrailsProjectWatcher.java is responsible for file changes. Try to add debug to the related package and see if you get messages.
If it's one particular class that's not reloading, one thing you can check is that the package definition is correct. Grails will happily compile a class that is in the wrong package, but this breaks the reloading mechanism.
Hey all,
I'm just starting with Grails in Netbeans (6.9.1). I got a demo working, but each time i change a groovy file i need to build the project, and then select run (ie the equivalent of "grails build" and "grails run-app"). If there is already an instance running, I need to first shut that instance down.
This seems wrong. It seems like i should be able to just change the groovy file, and it would get automagically reloaded. Isn't that the point of groovy?
Is this actually how it's supposed to work in Netbeans? Without getting into an IDE war, do other IDEs do it better? everyone seems to rave about the Grails support in IntelliJ. Is it worth it?
One last point... I noticed that a regular war maven project no longer automatically reloads on an F11 build. Could this be related?
Thanks
--Matthias
Do not expect to have reloading for all your files even by running your grails app through command line.
Depending on which groovy file you have changed, grails run-time auto-reloading will work or not. Indeed:
Files and folders supporting reloading in development mode: gsp files (in view folder), grails services (in service folder), controllers, taglibs, css, i18 resources, javascript files, some config files (like Config.groovy), url mappings. Note that there are some Grails bug when for instance, using spring transactional annotation in Services makes the reloading crashed
Files and folders NOT supporting reloading (and requiring a restart of the application): any code under src/groovy, src/java, Domain classes (under domain directory), some configuration files, changes in plugins, any code under utils folder (if you have any Codec for instance)
So in your case, if you change a controller groovy file AND NetBeans restarts the application, I recommend you to use a separate command line for running grails application and using the IDE for code changes. The only bad side is that you will not use the NetBeans debugger.
Actually this is the way I work with Grails and IntelliJ