- This topic has 11 replies, 4 voices, and was last updated 19 years, 3 months ago by
.
-
Posts
-
I am deploying a war file to a resin server. I opened the war file and discovered that the /WEB-INF/classes directory isn’t in the war file.
The source code and the .class files are both is the WEB-INF/classes directory and the project preferences are set to ‘Allow output folders for source folders.’ This worked fine in 3.8.2. What changed and what do I need to do to fix this. (moving the source files to a different directory is not an option)
Thanks.
Upon research, the functionality of the deployer was changed to fix a bug that caused Java source folders to be deployed in web projects that don’t user an explicit web root. It looks like this change is preventing your class folder from deploying. Basically, this is an unforseen edge condition as we’ve never seen a user set up WEB-INF/classes as a source directory. We’ve entered an enhancement request to allow a user override of the change to allow source folders to deploy. In addition, only exploded deployment was affected. Packaged deployment will still work properly for this configuration.
I take it you don’t get many people coming from the older Netbeans IDE’s then, cause this was the default for Netbeans until recently (well last year or 2, I have been using NB for a long time and some of our developers still do, which is why I can’t change the structure). And you’re wrong about the effect, it happens for all deployment types, packaged/exploded and default/custom/external. Trust me, I tested all variations looking for an alternative before posting this.
How soon will this be fixed? In the meantime, can I revert back to 3.8.2? And if so, how?
How soon will this be fixed? In the meantime, can I revert back to 3.8.2? And if so, how?
We will try to get it into the next quickfix (no ETA) in the mean time you can use the Help > Soft Updates > Manage Config > select ME > Disable (restart YES) approach of removing old ME. Then download 3.8.2 again and unzip it (Manual install) and then do Manage Config again > Add Exntesion > Point to new ME location, hit OK, restart YES. You might want to shutdown and restaart with -clean command line arg after that to make sure the plugin cache is rebuilt.
And you’re wrong about the effect, it happens for all deployment types, packaged/exploded and default/custom/external.
Perhaps I misunderstood your configuration then. I set up a web project and set WEB-INF/classes to be its own Java source folder as well as its own output folder, using the project root as the web root (ie. no explicit web root folder). I then deployed in exploded mode and noted the problem you reported. I then removed that deployment and packaged the web application as a war and then opened the war with Winzip. Inside the war, WEB-INF/classes was present as well as a test file and it’s output class file. Custom / External won’t have any effect if exploded is still used. However, I did get packaged deployment to deploy this configuration as you would’ve liked. Can you recheck my description and your results because I believe this would be a good workaround.
I have been using the packed deployment even when developing and testing simply because I’m anl that way and always develop with a model as close as possible to how we deploy. And since we deploy as a packaged .war file, that is how I have always done it. It was when this stopped working that I used winzip to examine the war file and fould that there was no WEB-INF/classes directory at all. I only tried the exploded method after I failed to get the packaged method to work.
Is it possible that I made some other change after the upgrade that caused this? I am not overly familiar with Eclipse and could have inadvertantly made another change not realizing that it would cause this behavior.
Thanks for the quick responses, by the way. Excellent support.
Is it possible that I made some other change after the upgrade that caused this? I am not overly familiar with Eclipse and could have inadvertantly made another change not realizing that it would cause this behavior.
Could be. I’ve emailed you a zip of a small test web project. Can you create a new workspace, import the project into it, and deploy it as a packaged war and check the contents?
@support-scott wrote:
And you’re wrong about the effect, it happens for all deployment types, packaged/exploded and default/custom/external.
Perhaps I misunderstood your configuration then. I set up a web project and set WEB-INF/classes to be its own Java source folder as well as its own output folder, using the project root as the web root (ie. no explicit web root folder). I then deployed in exploded mode and noted the problem you reported. I then removed that deployment and packaged the web application as a war and then opened the war with Winzip. Inside the war, WEB-INF/classes was present as well as a test file and it’s output class file. Custom / External won’t have any effect if exploded is still used. However, I did get packaged deployment to deploy this configuration as you would’ve liked. Can you recheck my description and your results because I believe this would be a good workaround.
The above is whats happening to me, although I’m on 3.8.1. I’m also coming over from Netbeans and as with other user cannot change my structure. Also having problem with the packaged options as it seems not to always take updates (ie I change a file redeploy and nothing changes). Is there any news on the quickfix?
Thanks
desdes,
Packaged deployment hasn’t ever supported hotsyncing of changes; the reason is that deployed WAR files can easily get quite large (big project + lot of classpath entries == 10s of megabyte WARs) and recreating that WAR every single time you change a JSP doesn’t make sense and then force your app server to uncompress/redeploy the changes. We have traditionally relied upon exploded deployment for this.There is no ETA for the quickfix just yet, but we are already targetting and knocking out bugs targetted for it. As soon as we have a timeline we will post it to the forums.
