For some reason my grails application no longer starts a browser with the webpage displayed when doing a grails run-app. It always did before. There is no errors or anything, it just no longer auto-starts the application. I haven't changed any code unless git corrupted something. Anyone know what could cause this?
Grails does not start a browser - usually your IDE takes care of this.
On IntelliJ you can enable this behaviour (Launch Browser) under your Run Configuration.
Click on Edit Configurations… here
Enable Launch Browser
Related
I'm developing an application using Grails 3.3.10 using Spring security plugin but I'm getting very weird behavior, when I run the application using -https for instance I finished editing the Profile in the edit.gsp here its URL https://localhost:8443/profile/edit/1 and I press Update so it will suppose to take me to the index.gsp but the URL I get is http://localhost:8080//profile/index as you can see the URL isn't https and there is extra / by the way this is happing in a lot of the views.
What is the reason for this behavior
I figured out what is the cause for this weird behavior i found in config file application.yml, the property grails.serverURL was configured twice ,so i commented them and everything worked fine
I'm using Eclipse 4.2, appengine-java-sdk-1.8.9, gwt-2.5.1, smartgwt-4.0p
I'm trying make the simple project like this - http://uptick.com.au/content/create-gwt-project
but offline.
When I save page (as html page) it doesn't work offline and I receive alert - "GWT module may need to be (re)compiled".
My question is: how to change project to save it as html page (plus project_name_nocache.js file).
Thanks.
You might be getting this error message because you might be trying to run/debug your application in compiled mode. In order to do so, you need to re-compile your application for GWT after every single change in code.
To avoid this, you should run/debug your application in developer mode.
See this link, to have idea on how to run GWT application in dev mode.
When developing a Grail app in IntelliJ there's a console view:
Whenever I make changes to the app outside IntelliJ, this view grabs the focus and lots of building messages start appearing. This also happens on occasions when making changes within the IDE.
I would like to hide, delete, disable or remove this view if possible?
(FYI, this view has nothing to do with the Grails console that appears when you run the grails console command)
You can't disable it in the current version, however this problem will be addressed in the future builds, our developers are aware of it. Sorry for the inconvenience.
I have a plugin with domain, controller and view pages. (Using grails 1.3.6)
I run the plugin as standalone, the views work fine. URL: http://localhost:8080/sample-plugin/gp/list. I am able to view the list page.
I installed the plugin into a main application i.e. plugin-test. Start as run-app within STS and browse to http://localhost:8080/plugin-test/gp/list. I am able to view the list page.
I bundle the application as war i.e. plugin-test.war and deploy to tomcat. When I browse to http://localhost:8181/plugin-test/gp/list I get a 404 error! I am not sure what I am doing wrong.
I have been trying to resolve it for quite sometime now and still no luck. The same main application works fine in STS but not in tomcat.
HTTP Status 404 - /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
type Status report
message /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
description The requested resource (/plugin-test/WEB-INF/grails-app/views/gp/list.jsp) is not available.
Please help.
Thank you.
Jay Chandran.
This sounds worryingly familiar, as I spent a while figuring out this (or a very similar) issue. I ended up raising this Grails bug report:
Plugin layout not found in war when installed from BuildConfig.groovy
Have you installed the plugin as using the new BuidConfig dependency technique? The JIRA documents my workaround.
Sharing some of my lessons learned after experiencing the same exact issue (1.3.7):
Double check your HTML source to make sure that your template really isn't being included. Mine was being included, but my CSS/image URLs were wrong (only while running as a war)...so I wrongly assumed that my template wasn't there.
Don't use the ui performance tags for referencing your static content...doesn't appear to work, even if the plugin attribute is specified.
Don't name your layout main.gsp. You're guaranteed to have conflicts.
Don't use absolute=true on your g:resource tags. This doesn't appear to append the pluginContextPath to the absolute url, even if you specify dir="${pluginContextPath}"
Don't use pluginContextPath, as it's no longer required: http://grails.org/doc/latest/guide/single.html#6.3%20Tag%20Libraries (search "Plugin Paths")
In your g:resource tags in your plugin layout, make sure you specify the plugin attribute. Set it to the name of your plugin.
Move your static images/css from your plugin to a web server. If each application using your plugin has its own copy, your users aren't going to benefit from caching when bouncing between apps.
Note that all of the above applies to the layout gsp in your plugin project, not your consuming application.
Is there any way to run Silverlight tests without opening the browser? It takes some time to open the browser. if you are doing TDD, you may not like it.
I don´t think so.
for Silverlights Sandbox has to be astablished to test apainst and the sandbox does life in the browser , I can´t see a way to achiev this.
Regards Ren
You can test the Out Of Browser (OOB) version of your application instead. To do this, add a call to Application.Install() within your application, run it, and then in Visual Studio debug the Silverlight project itself rather than the ASP.NET project.
Once installed, you can also run the OOB version of the application from the command-line using "sllauncher.exe". To get the right parameters for sllauncher, look at the properties of the shortcut the installer creates for your app.
Even though you can use the sllauncher.exe - it still runs in using an IEFrame - hence effectively still uses a browser to host the SL sandbox. Sure, you won't see the browser in the regular sense.