3.1 Sync-On-Demand seems not to work correctly for JSF

What M-build of Eclipse? What version of MyEclipse

Also if you are using an exploded deployment, your changes are immediately deployed the second you save the page (assuming you have Project > Automatically build turned on). So no need to keep deploying.

This is most likely a caching issue with your app server, try and use an exploded deployment and see if it suddenly works.

I’m confused, you mentioned an “exploded WAR” and then in the last post “redeploy our WAR”… if you are talking about a WAR file, then it is implicitly not exploded, exploded deployment is the only one that is hot syncable and is really a direct-copy of your WebRoot out to your app server (make sure there are no old stary WAR files hanging around in the deployment directory that could be usurping your exploded deployment).

So yes, if you are deploying a WAR (packaged deployment) you will need to deploy it every time if you wish to see changed.

Can you clarify your settings a bit more if this didn’t help?

Very strange.

Are you using EJBs, do you need to be using JBoss? I’d like you to try this with Tomcat 5 if possible.

Ultimately what you can do is navigate to the deployed directory of the JSP page in your app server, switch back to Eclipse and change the page and hit save, switch back to the deployed location, is the timestamp on the file updated? If it is, then this is an issue with JBoss reloading the page. If there is no timestamp, than make sure you have Project > Automatic Build turned on, if it is then likely an error occured and we will need to know what it is, so you will need to check your log file: <workspace dir>\.metadata\.log

Frank,
This is a JSF caching issue, it doesn’t relate to MyEclipse. Like I mentioned, if the timestamp is changing, then the issue lies elsewhere.

I can say that Sun’s RI of JSF has *many* bugs related to caching which have driven me crazy before. I suggest either using MyFaces or making sure you are using the most up to date versions of the RI libraries.

PanelGrid is one of the worst components with caching problems, I have changed entire page layouts before and the JSF component cache won’t update using Sun’s RI unless I restart the server. It was infuriating.

I’d like to know this as well as I do quite a bit of JSF development and this fact along really does wear my nerves thin by the end of the day.

Frank,
I’ve read over the spec for JSF 1.2 and it seems to improve some of this, it looks like a lot of big changes in the right direction (unified expression language for example) but won’t be out until year end IIRC (beta).

Also there is currently no way to only deploy a portion of an enterprise app, I’m sorry.

Frank,
We’ve been so hesitant for so long to augment the current (inferior) app server controls and deployment tool bar functionality because a lot of this is going to change in our 5.0 release (looks like closer to EOY), but with things getting pushed out I will ask the team if it is possible reevaluate our current setup.

The problem with adding a quick deploy button on the toolbar is that it will fail unless the app server is shut down, redeploy, then started back up (due to read locks on Windows). So this may not be as helpful as you would hope.

Additionally, YES I have had that frustratingly annoying caching issue with MyFaces as well (it was the only reason I tried MyFaces over the Sun RI in the first place). I would really encourage you to subscribe to the myfaces mailing list and ask the other devs what they do.

You *could* try and restart the web context each time and not the entire app server, you do this by keeping the Tomcat manager open in a browser window, and every time you hot deploy something (Save it) in MyEclipse, switch over to the browser window and click the “Reload” button next to the context you want to reload, sometimes that helps, but with some things a full server restart is needed.