This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Problem: ======== When exporting to a WAR-file manually or automatically(by starting the builtin Tomcat) all linked directories/files are included into the file, BUT THEY ARE NOT PLACED in the directory where the link originally was. They are instead placed in the ROOT directory. The webbapp then, of course, can't find the linked files... Example: ======== This link: \WEB-INF\Classes\LinkToSomeProject-> Is stored in the WAR-files as: \LinkToSomeProject It should have been included and stored at: \WEB-INF\Classes\LinkToSomeProject
Looks like too complicated bug to be fixed so late. There is a risk of side effects. This probably requires to patch ArchiveMembers or ArchiveEntry for web application to return correct target directory.
The fix requires to implement own ArchiveMember objects that will be processed during WAR packaging. This will allow to resolve them correctly if they represent DataShadows. Due to reason expressed in 19898 it would require to override JarCreator, ContentMemberList and ContentMember classes which are internal to JAR packager now.
Waiver approved.
I approve too.
So do I.
Jonas: can you explain us why you add the links here? Maybe that it works when application is executed but this is rather consequence of fact that we pass all filesystems as a classpath for executed Tomcat3.2. If you will deploy the same directory on external instalation of Tomcat if will likely fail. If you need to package additional resources try to remove your links and specify them as extra files on archive property set of WEB-INF node with explicit target directory. Technically we may be able to fix it if we write some hacks to handle this situation. One suggestion (thanks Roger) is to set target directory for DataShadows before they are resolved. Unfortunately all the content of filesystems that contains web application is processed recurcively at once so we would need to go through it too before this is done and check for datashadows. This doesn't look like optimal solution. Given the fact that this behaviour has to be in NetBeans for a long time and this is the only complaint we can adjust the priority
"can you explain us why you add the links here?" Because it seemed logical. I.e. this feature would be very nice. Linked files are added today by NetBeans, but they are placed in the wrong directory (the root). "...specify them as extra files on archive property set of WEB-INF node with explicit target directory" I have searched and searched, but can not find any "archive" property, or "extra files" property of the WEB-INF. Where exactly should I click? Please guide me...
However it can be natural to put link here it will not be possible to execute web app with new Tomcat 4 plugin. The resources in web-inf/classes has to be physically present here. Using IDE links doesn't help. Thus we don't want to support packaging of them too. My fault is that I asked you to use properties from Archive tab. They are plugged by JSP/Servlet Advanced module. The only distribution that contains it is Forte for Java (will be probably part of NB3.4). I suggest you to copy sources here directly (develop them here or use tools like ant for updating) or to use OS linking. We are not going to fix this due to reasons expressed above.
"However it can be natural to put link here it will not be possible to execute web app with new Tomcat 4 plugin. The resources in web-inf/classes has to be physically present here. Using IDE links doesn't help. Thus we don't want to support packaging of them too." But, you are physically putting linked files into the packaged WAR- file, but in the wrong directory. So, wouldn't it be nice to put them in the right directories...? AND If they are put into the right directories, why wouldn't the new Tomcat 4 plugin work? I.e. I'm sorry, but I don't see your point. ;-)
Resolved for 3.4.x or earlier, no new info since then -> verify.
Resolved for 3.4.x or earlier, no new info since then -> closing.