I've been upgrading a Grails 1.3.7 project to Grails 2.0. Everything was going smoothly until I hit integration (first non-local deployment). The gist of the problem is that it appears the Resource plugin always prepends the app name to the static CSS/JS URLs it generates, regardless of the grails.serverURL or grails.app.context specified for the environment. What's strange is image resources are hosted with the appropriate URL "/static/foo.png" but CSS/JS files attempt to be served as "/AppName/static/foo.js". Tracking this issue in ResourceTagLib, this initially looks like a issue in Resource Plugin but I don't want to jump to conclusions.
Our integration environment is setup with Apache proxy passing all traffic from "/" to ":8080/AppName" hosted on Tomcat. Therefore, all traffic to "http://int.sitename.com" is hitting the app running on Tomcat. Previously, in 1.3.7, grails.serverURL="http://int.sitename.com" was all that was required to get resources to served correctly.
Does anyone know a way to resolve this issue or does this look like a bug present in Resource plugin.
I'm using Grails 2.0 too. There is a line app.context=/ in the application.properties. As application is deployed to Tomcat, it's also on renamed to ROOT.war on deployment, so Tomcat will use a ROOT ie / context for this application. As result I don't have the described issue.
Related
Issue on Websphere 6.1 I hope I'm missing something obvious: We have an application which gets deployed to a configured Websphere environment. We're trying to mimic this WebSphere configuration on a different platform (Linux vs Solaris), but maybe we're missing some obvious settings. The application deploys and starts without an error, but after logon on url localhost:port/app/index.jsp
(via j_spring_security_check) Websphere redirects to localhost:port/index.jsp. This gives an JSP processing Error (HTTPError 404), with code JSPG0036E.
The webapplication is wrapped in an ear, because those are the standards here. And that ear works well on our solaris WAS 6.1 environment but not on the linux WAS. Furthermore in development we've the wrapped war running on Tomcat without problem.
I think I missed the context root somewhere but It's not to be found in Websphere's console, I wouldn't be surprised if it is a Websphere (6.1.0.33) Bug, hopefully I'm wrong or are there workarounds?
I installed Ubuntu, GlassFish web server, installed JRuby on Rails using GlassFish's admin tools, deployed my application from .war archive. The problem is only - when I attempt to run this web application nothing happens. GlassFish isn't listening on port 8080 as promised. The GlassFish administration web console listens on port 4848 and works fine. What to do to pair GlassFish and JRuby on Rails the correct way, remembering that it isn't a separate JRuby installation?
Update: it seems that this problem lies somewhere around access rights because I can deploy an application through
sudo ./asadmin deploy
but can not do the same through web console. The output is as if the application has been deployed, without any error messages (web interface shows the presence of application, domain folder contains my application's file/folder structure), but something in server's internals isn't bound to application.
I didn't think much and applied quick and dirty solution: set "777" access rights to /home/glassfish and all its contents. It helped.
I generally run Grails 2.0 from my IDE but have been seeking to deploy an app to a remote Virtual Private Server (linux) where I installed Tomcat and Mysql. I create a production WAR file and copy it to the Tomcat webapps dir, where I can see Tomcat restart and after some "fixing" I see the application come up, adding minimal bootstrap entries into the MySql database fine.
However, I cannot connect to the Grails app (remotely). If I specify www.mydomain.com, I am (finally) able to reach the main Tomcat server "welcome page". I also reach Tomcat if I add a "/" at the end, not my grails app.
As such I'm tried putting in full controller paths that I know work on my dev machine, and then accessing them on the remote machine (note grails.serverURL is configured as http://www.mydomain.com). Doing this, I get
HTTP Status 404 -- The requested resource (/BareBones/bare/create) is not available.
This error is from a BareBones application I created, as I was having some problems with VPS available memory. In any case, on my dev machine I can reach the this BareBones app URL
http://localhost:8080/BareBones/bare/create
as expected. When I deploy, I get the same HTTP Status 404 error (resource not available) when I do:
http://www.mydomain.com/bare/create
In Config.groovy, in this BareBones app I've got the minimal change:
environments {
development {
grails.logging.jul.usebridge = true
}
production {
grails.logging.jul.usebridge = false
grails.serverURL = "http://www.mydomain.com"
}
}
In my Tomcat server.xml file I changed over from the default 8080/8443 ports to 80/443, but using either either set results in the same problem.
I'm probably missing an easy step, just don't know what it is.
P.S. When I deploy the sample.war file that comes with Tomcat (isn't Grails, just a hello-world servlet), it works. I'm able to access that at
www.mydomain.com/sample
Since I FTP'd sample.war from my computer to the server, it would appear to indicate my FTPs are good, and the routing to the server is right, narrowing this down to Grails & Tomcat.
Usually in dev mode Grails mounts, as you pointed out, the context of appName, i.e. http://localhost:8080/BareBones/ here.
But the path it mounts on tomcat is not up to Grails itself, it is wholly dependent on the Tomcat configuration and primarily the name of the WAR file.
Even if you have BareBones as your appName and you deploy it as ROOT.war then it will mount the root "/" context. If you deploy it as BareBones.war then it should mount the same dir as in dev mode.
Because sites are usually mounted as ROOT.war "/", I can recommend setting
grails.app.context = "/"
in your Config.groovy file which will make it so that you will use the root context path also in dev, i.e. http://localhost:8080/
This makes it simpler since both dev and production will now have identical relative paths to everywhere and only the hostname:port will change.
I'm using Jasper with the Struts2 plugin to generate PDF reports for my web application, as described in this tutorial.
The application uses Weblogic as app server and Apache as webserver in development environment, IIS in testing and production environments.
Locally I put the .jasper files under WEB-INF of the WAR section, which is then put in a EAR after compilation.
PDF generation works locally, passing a relative path (namely WEB-INF/jasper/template.jasper) to the result parameters of the "jasper" result in struts.xml . This does not work when the application is deployed as an EAR.
How can I get my application to find the .jasper template even when deployed as an EAR? I tried to pass in an absolute path pointing to a directory in the same server the EAR is in, but it doesn't work.
And by the way, is there a comprehensive guide to the Struts2 plugin for Jasper? I couldn't find anything except for that tutorial.
In weblogic domain home's webapplications tab; enable the option called Archived Real Path Enabled
works for me in weblogic 11g or later versions
I am developing a Rails 3 application and I have installed Capistrano on the client side and Passenger with Apache 2 on the server side.
I make a deployment and the files are sent to a folder called u/apps/.
But when I visit the IP address I am currently using I only get to an empty folder, how do I configure Apache to look for my app in the current folder? So that I only need to visit my IP/domain to see my app?
I have done this using Rails 2.x but I think for Rails 3 also pretty much the same thing. For this you need to use Passenger and then configure Apache.
Following are some useful resources
http://www.modrails.com/install.html
http://railscasts.com/episodes/122-passenger-in-development
If you browse to your URL and you see an apache files/folders list that means that passenger is not triggered for that location...
Test your server environment by running a mongrel/thin in your application folder and see that your application runs correctly. After that, look at your Apache configuration (see Passenger docs).