I have a Glassfish server in production which uses JDBC Realm for authentication.
It works well, but there is the need to change all the roles/groups. I developed a new version of the web application in a test environment changing glassfish-web.xml and web.xml to align them with the groups contained in the groups table on the db for test. Everything works flawlessly. So I moved the web application to the production environment and updated the content of the groups table on production db.
The authentication works well but roles are not recognized. How can I investigate this problem ? I checked the production db and the groups table is fine and can be accessed for select. Glassfish-web.xml and web.xml are the same of the test enviroment. This is a real brain teaser. The only explanation I can give is that Glassfish-web.xml is discarded for unknown reasons or the old file is still present and read from some other location than web-inf directory.
Thanks for any help
Filippo
Explore your domain's folder under GlassFish root folder + \domains. If you are unsure what domain you are on, it is domain1 by default. Under this folder you should have a folder called applications. This folder contains the deployed version of all your applications, and it's the place where to check your application's Glassfish-web.xml configuration file.
Anyway, if you are having this kind of problems, a Clean & Build of your project, followed by a redeploy, usually works.
Related
I have an Apache server proxying all traffic from mainhost.com/subdirectory to someec2instance/subdirectory. When I start Apache and hit someec2instance.com, I get the ROOT war page. That works fine. If I deploy my app as ROOT.war, everything works fine form someec2instance.com.
However, when I access mainhost.com/subdirectory, all the asset urls and link_to urls are wrong and point to mainhost.com instead of mainhost.com/subdirectory.
I've set grails.app.context and confirmed via application.properties that the correct grails.env is being set.
Why isn't grails.app.context being respected when I deploy as ROOT.war? I would expect the site to be accessible on someec2instance.com/context, but it's like it ignore grails.app.context entirely.
The reason is doesn't work is that those settings are for running locally, not when deployed as a WAR file. When you use the tomcat or jetty plugin in run-app we configure the container to make it look like it's running an "exploded" war (similar to when a WAR gets unpacked to the file system by various servers). Since the container is running in embedded mode, it's easy to configure it programmatically as needed.
But when you deploy a WAR file there's nowhere near as much configurability. In run-app the build logic of Grails starts the server, configures it, and deploys the app, but a WAR file deployed to a "real" server is managed by the server and not the other way around.
I have followed the imageresizer's troubleshooting for when images do not appear as they are listed here:
Potential causes:
You are using the .jpg.ashx syntax, and you did not register the HttpModule properly in both places of your Web.config file.
You are using the .jpg.ashx syntax, but you're not using a query string. You should drop the '.ashx' unless you actually want to process the file.
You are using ASP.NET MVC, but do not have the MvcRoutingShim plugin installed.
You have Precompilation enabled, and are using an image provider. This is caused by a long-standing bug in the .NET framework.
However, everything works perfectly in my local development environment. I have the MvcRoutingShim plugin installed and all the correct web.config references. On the live site, all images referenced by either just a querystring OR the RemoteReaderPlugin.Current.CreateSignedUrl procedure are not found.
All images are resulting in a 404 error.
Any ideas?
The answer: DiskCache(ConfigurationError): Not working: Your NTFS Security permissions are preventing the application from writing to the disk cache
Please give user read and write access to directory "C:\inetpub\wwwroot{site}\imagecache" to correct the problem. You can access NTFS security settings by right-clicking the aformentioned folder and choosing Properties, then Security.
Im trying to work in my project, when I change files it changes the file inside the directory that I imported the projects into my workspace. But the changes aren't showing up on the server because the server is using the folder inside .metadata/webapps/myapp etc
what have I done wrong here?
Sounds like you're deploying to the integrated Tomcat server. The deployment is normally to the .metadata/.me_tcat/webapps/myapp folder. Is this what you meant? If not then I suggest you remove the deployment and then deploy again and let the deployment location default. The folder .metadata/.me_tcap is simply where the integrated Tomcat installation looks for applications when it starts up.
You can check the deployment location by looking in the servers view. Expand the integrated Tomcat server. The deployment location for your project is shown there.
The deployed location should be kept in synch with your code. If that's not happening, it may be that the changes you're making are the kind that require a redeployment. I'm not sure what the conditions are for propagating changes but I guess there might be some situations where changes can't be picked up automatically in this way. The changes should be picked up on a redeploy.
To check, create a new web project, which will create some default configuration and a default index.jsp file. Deploy this to the integrated Tomcat server. Now make a change in the index.jsp file and save it. Check if the change is made in the deployment location, or simply run the server and check that your new index.jsp gets displayed.
For more help, I suggest you post to the forums at www.myeclipseide.com/forums
The answer to this may be a link to a good tutorial, but I've been unable to find one and it's getting rather frustrating.
I'd like to dive into the source code of DotNetNuke 5.2 which I have downloaded to a folder. I've opened up the solution that ships with it and it opens & compiles just fine.
What are the recommended steps for:
Setting up the database for this
source/compiled version of DotNetNuke?
Configuring IIS 7 (on the local
machine) to run/serve the site?
(Windows 7, VS2008, SQL-Server-2005, DotNetNuke 5.2)
FOr the setup you will follow the standard installation process, using the /website folder as the root for the configuration within IIS.
I have an installation tutorial on my blog that you can use, the specific tutorial is for 5.0.0, but the installation process is the same. The short order process is as follows.
Create a database and SQL user for the database, giving them DBO permissions
Setup a virtual directory in IIS that points to the /website folder of your dnn installation
Grant the ASP.NET worker process account full permissions to the /website folder
Navigate to the /install/installwizard.aspx page, follow the instructions and set the database values for what you specified in number 1 above.
NOTE: the use of a source version of DNN for production use is not recommended, additionally it is my personal recommendation to not modify the source, unless you are truly willing to accept that future upgrades might not be possible due to your modifications.
Expanding on Mitchel's Answer:
Create a database and SQL user for the database, giving them DBO permissions
Go into DNN/Website folder. Copy release.config and name the copy web.config
Setup a virtual directory in IIS that points to the /website folder of your dnn installation
Open the solution and compile the project
Grant the ASP.NET worker process account full permissions to the /website folder (NETWORK SERVICE)
Had to give users group read/write/modify access to the entire website folder otherwise I got some errors about file access. This is more than is necessary but it worked.
Navigate to the /install/installwizard.aspx page, follow the instructions and set the database values for what you specified in number 1 above.
Edit: This is as of version 5.2 available 2/25/2010
I am setting up a 3rd party website which makes heavy use of httpHandlers. When configured as a virtual directory under Default Site on a 2003/IIS6 machine, everything works as expected. When configured as a standalone site on the same machine, pointing to the same directory and web.config however, httpHandlers do not work (404).
I have tried various changes to the path values of the handler's tags with no results. The pages themselves, and the application's code, all seem to execute find within the standalone site.
Any obvious things I might be missing?
Found my own answer, was a very simple thing.
An installer package had installed the virtual directory version of the site, and it had taken care of adding the file extension mappings. The standalone was manually configured and as such, I missed adding the mappings.
Resolved.