I made a web project, packaged it in a war file and deployed in jboss - worked great (I have done this 100 times before and succeeded). Today, I modify the same project and created the war file again and deployed the project to a clustered jboss server (jboss-4.0.5.GA running on Red Hat Enterprise Linux Server release 5.4 (Tikanga)) as usual, I expect the changes to reflect.. When I accessed the project via the browser, my changes do not show. When I deploy the same war file on my laptop (Windows 7) the changes show perfectly! So I stop the jboss server, delete tmp and work directories on the clustered jboss servers plus the war file in farm folder... then deploy the new .war file.. I start the server again.. I expect the changes to show now on the server but they do not!! I have tried this over and over but no success in having the latest .war file run..
Has anyone experienced this and whats the solution?
Did you by any chance deploy to the 'default' configuration, while your cluster is running e.g. the 'all' one?
I thought it was only fair to share the answer. The reason why changes did not reflect was because our ISP was caching javascript and css files. the painful solution was to rename my css files.
Related
I know this is a long shot but I'm going to ask anyway.
I have a project I'm working on for a company that hosts their application from a server running Microsoft Server 2012. I've found the folder where the web app's files are stored and I want to deploy my own version with updated code - would I just replace those files and restart the server to deploy? (after backing that folder up, of course)
This is super out of my wheelhouse as I've only used Github, Heroku, etc for deploying applications. Please let me know if I need to provide any more information to help you help me.
Thanks in advance!
you host multiple websites on the same server. Use IIS to point to another website and start it on a different port number for your web app. Let me know if this isn't clear enough
If you only update HTML, CSS, JS these files, it will be updated after you restart the iis server, but if you change the cs file code you need to rebuild the project and republish it or just copy the bin folder.
I am having issue with the way tomcat deploys my files to the server.
I have installed Tomcat 7 to /opt/tomcat7.
In my eclipse i have specified this path as my tomcat server.
my workspace directory is /home/maciej/workspace/<projects here>
now if I edit a class file and i add simply log statement
log.info("blabla"); and then deploy 'NEW' version of the file via - run on server, i do not see this 'blabla' in my output. It seems like although i have modified the class file, it was not properly deployed into tomcat. Tomcat is reading god knows what but certainly not the file it should read.
EDIT: I have recofnigured my tomcat in eclipse and now:
Server Path = /opt/tomcat7
Deploy Path = /opt/tomcat7/webapps <- used to be .metadata/blablabla default
eclipse tomcat location
When I open 'Open Lunch Configuration' under arguments/working directory the default option is ticket with greyed out path /home/maciej/Desktop
Should this also be changed?
Isn't tomcat working directory /opt/tomcat7/work ?
Any suggestions / ideas? As this issue is slightly getting on my nerves as i can not develop the app.
The Server Path is the same as the Tomcat installation directory in the modal you see in Window > Preferences > Server > Runtime Environments after hitting Edit. That should be set to /opt/tomcat7 or wherever the root of your Tomcat installation lives.
The Deploy Path is relative to the Server Path. It should be webapps, unless you already have stuff there and you want a separate directory. You will not be able to edit this until you shut down Tomcat and remove all webapps underneath it through the Servers view.
Try unchecking Modules auto reload by default if you trust the JDK hot-swapping, which you should if you're using JDK 1.7 or 1.8 and just want to see a log statement inserted.
The working directory you mentioned is just the root directory that Tomcat uses to spit out thread dumps on crashes and the like. It has nothing to do with the Tomcat "work" directory.
Open server view: Window->Show view->Other->Servers. The select correct server, right click, select "Clean" and then restart tomcat. It should help.
If you change something in the project then Eclipse will build automatically and "deploy" the files to the location you have specified. By default, Eclipe's work stops there and the rest is up to tomcat.
Tomcat, like any Java web server, detects changes in JSPs and recompiles them. Nevertheless, changes in classes have no effect because of the way Java class loading works. For the new version of a class to be used by tomcat you need to:
Not have loaded the class before. For example, you start tomcat but then see an error before doing any request. If you change the class then that change will be used because the class was not yet loaded.
Reload the application. This means that all classes are discarded and everything starts fresh.
The easiest way to reload an application, by default, is to make a change to web.xml. If you look into tomcat's configuration conf/context.xml you can see that WEB-INF/web.xml is monitored. Any change will trigger a reload of the context. So you can either make an artificial change in the file or add a resource like WEB-INF/version.properties and generate a different version.properties with any build.
In any case, reloading a complex application takes time. That is why there are plugins like JRebel. But before you go down that path (which adds another moving piece to your setup) you can also try to use Eclipe's support for hot code replacement. You start tomcat in debug, connect to it with Eclipse, and then change some class. Eclipse will try to recompile the class and upload the new definition to tomcat. If it fails it will tell you. As a general rule it will fail when you change the structure of the program and succeed when you just change method's implementations.
i'm using JBoss 5.1.0.GA on a linux machine and i'm deploying an ear for an EJB project, while looking at the server logs, i undeploy the old ear and it undeploys successfully then i put my new ear in the deploy directory and also the logs show that it is deployed successfully but when running the project, the new changes don't take effect and the old ear content gets executed instead. please advise!
i had this problem with 5.1 EJB3 projects on a windows machine a couple of times. Something very fishy going on.
have you tried everything?
i.e. undeploy, stop the service, restart the machine if possible, start the service, re-deploy
i remember in my case it stuck until the machine was restarted. never actually found the problem though.
After shutting down the server, just delete all of the temporary folders that get generated when JBoss starts. Those folders are (if you use default folder):
/server/default/data
/server/default/log
/server/default/tmp
/server/default/work
After deleting them, just restart JBoss and all your new changes should be there.
I have this strange problem at which I have spent stupid amount of time.
To build my portlet, I haven't used sdk and I am using my own ant script do the job. It works all well till this wierd situation.
I am basically using a lot class from portal-service.jar to change role settings etc. When I include it in my build path and deploy it again. It doesn't get deployed. On shell it shows the deployment, below is the log:
Copying 1 file to C:\liferay-portal\tomcat-6.0.29\webapps\ch1_HelloWorld
Deleting directory C:\liferay-portal\tomcat-6.0.29\temp\20121016060846753
06:08:47,887 INFO [PortletAutoDeployListener:81] Portlets for C:\liferay-portal\tomcat-6.0.29\deploy\ch1_HelloWorld.war copied successfully.
Deployment will start in a few seconds.
16 Oct, 2012 6:08:56 AM org.apache.catalina.startup.HostConfig checkResources
INFO: Reloading context [/ch1_HelloWorld]
That's it! Later it doesnt show (as it does normally) that the portlet is available to use. In browser, under the "add tab", the option is never shown. What can be the issue for this. The portlet is a simple hello world portlet that access role information
I am basically using a lot class from portal-service.jar to change role settings etc. When I include it in my build path and deploy it again. It doesn't get deployed. On shell it shows the deployment, below is the log:
Did you put portal-service.jar to WEB-INF/lib? If so remove it from there and add it to some other (my_project/lib) directory than add it to build path.
Also make sure that after deployment portal-service.jar is not in your deployed WEB-INF/lib.
Better yet, first undeploy than redeploy.
Is this properly set in your liferay-display.xml ?
<display>
<category name="yourCategoryUnderAddMenu">
<portlet id="yourPortletId"></portlet>
</category>
</display>
Late answer, but maybe it will help someone:
- just shutdown your server;
- delete the portlet from the "webapps" tomcat folder;
- you should delete "temp" and "work" folders content;
- restart your server and deploy your portlet.
Everything should be OK.
I do not know why this happens, but I encounter this problem many times and fix it with the same solution.
Bye!
This is normally the case when the auto.deploy.dest.dir is pointing to the wrong place. Firstly, i came to realise the common mistake is to make this point to liferay_home/deploy which is not correct. This property specifies the destination of exploded files. For tomcat, it would be the webapps directory e.g. /opt/liferay-portal-6.2-ce-ga2/tomcat-7.0.42/webapps
In other words, tomcat, on receiving the exploded files,carries on. In your case, tomcat was never realising any changes.
Delete the old war from the webapps, and put your new war manually in the Deploy folder.
It looks like you might be deploying by copying it to the webapps folder, instead of the deploy?
go to plugins-sdk folder.
open build.userName.properties (In my case name of file is build.asif.properties)
open it..
add the below line
auto.deploy.dir = D:\\nWorkSpace\\liferay-portal-6.2.0-ce-ga1\\deploy
"D:\nWorkSpace\liferay-portal-6.2.0-ce-ga1\deploy" is the path of my deploy direcotory.
where nWorkSpace is my workspace. My problem is resolve.
I tried all of the above solutions but my issue was not resolved on a Liferay 6.2 EE sp2 bundle.
I was finally able to resolve portlet deployment issue by cleaning all the portlet xml files except the ROOT.xml from the Tomcat home/conf/Catalina/localhost folder.
This tip above was provided on the following post - how ever the blog post no longer exits and had to find in the archives below with google search in case someone is interested. It saved me hours of effort.
https://www.liferay.com/community/forums/-/message_boards/message/2124111
http://archive-ro.com/page/754918/2012-11-26/http://blog.ropardo.ro/2010/08/09/liferay-deployment-will-start-in-a-few-seconds-and-how-to-realy-start/
Trying to find the best way to setup the uriworkermap.properties file on IIS. We are using this:
/*=worker
With that line we can reach any new apps that are deployed to Tomcat without having to edit the properties file each time. The only issue with this method is that I can't seem to set an exclusion for any static files we might want IIS to handle. Is there a way to make this setup work?
The goal is to make deploying apps as simple as possible in production.
Looks like I had an old version of the isapi_redirect.dll installed. Installed the new one and this worked. In case someone stumbles on this question - the properties file works with:
/*=worker
!/includes/*=worker
So Tomcat ignores any request for the /includes URI and IIS can pick it up.
I got the latest isapi_redirect.dll file here:
Tomcat Connectors