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.
[20040304:release36] There is a problem with -bad- webmodule dataobject recognition when using VSS (Visual Source Safe). If an user have a webmodule created and stored in the VSS repository and mount this using IDE, then the WEB-INF node is created in the workdir automatically by the VSS (because it's in the repository). Then the filesystem is recognized as a webmodule and offers all actions like 'execute', 'debug' etc. Since there are missing all files (at least the deployment descriptor) the deployment fails. Even if the user checkouts all files the deployement is still broken (throws a CCE during webmodule execution). This bugs is very likely connected with #40086 filled against vcsgeneric.
Created attachment 13826 [details] The CCE
This is likely to be caused by issue #40086 as Marek correctly pointed out. The exception is in web module, but it is likely caused by existing folders and not-existing files.
We will wait until 40086 is fixed.
Fixed in trunk. The fix is based on the fact that filesystem will not be recognized as web module filesystem if web.xml File Object is in virtual state. This is the case of VSS filesystem. Diff : http://web.netbeans.org/source/browse/web/core/src/org/netbeans/modules/web/context/WebContextLoader.java.diff?r1=1.18&r2=1.19 Code reviewer : P.Pisl The patch is being checked by reporter.
I am affraid I must object agains this fix. It causes some additional problems when checking out the webmodule. Try to follow this scenario: 1) mount a VSS filesystem with clean workdir and repository containing a webmodule 2) try to checkout the whole webmodule (apply checkout action on the FS node) 3) => you will get a bunch of exceptions (attached) and since that the deployment doesn't work.
Created attachment 13871 [details] java.lang.RuntimeException: Failed to lookup configuration for Tomcat5 in
There is a problem in communication between the web module and j2eeserver. The exception is thrown because : Server configuration file cannot be recognized as DataObject with Configuration cookie : ------------------------------------------------ DataObject dobj = DataObject.find(fo); storage = (ConfigurationStorage) dobj.getCookie(ConfigurationStorage.class); storage is set to null; ------------------------------------------------ This is the case when VCS(VSS) filesystem is being checked out. The filesystem is being converted to Web Module FS, the j2eeserver is looking for context.xml, but context.xml exists in an inconsistant state yet (Virtual File Object).
See also the issue 40836.
Marku, I tested the scenario that you describe and it works for me. I mount a vss with module that I have created in IDE and then do recursive checkout and it works. It works even with "Get Latest Version" that creates the files R/O. (until I tried to modified the context.xml, then I got some exceptions that might have been handled more nicely, but that is a separate issue, I believe). It does not work if I try to checkout a module that does not have the META-INF/context.xml in VSS. In this case the IDE is trying to create the META-INF/context.xml file and needs access to web.xml which is non existent at that time and the first exception that you attached to this issue is thrown. If this is different from your observations please describe what exactly is happening including what the web module structure/content is. now to the code level: Both these problems (no access to context.xml that I cannot reproduce, and no access to web.xml) are caused by the code that is checking the value of context path when the web module is mounted (in WebContextObject). That invokes the code in j2eeserver that wants to read the web.xml/context.xml. The check in WebContextObject is needed for upgrade from 3.5 and for modules created outside of IDE. The code checks that the context.xml exists and if the value of context path property in context.xml is empty and the values was stored in 3.5 format (in nbattrs) it is moved into the context.xml. See also #40768. Doing this check later then when the module is being mounted would probably solve this problem (without creating regression in the above functionality) but it is not obvious to me when to check it then. I will follow up on this.
Ahoj Pavle, Regarding the case you cannot reproduce - try to follow this: 1) cretate a VSS repository and put a webmodule into 2) create a new VSS filesystem (with an empty workdir!) for the repository 3) click to the WEB-INF node. => Then the webmodule is recognized and a bunch of exceptions appears. Milan has created a patch which specifically address the part of the code where the webmodule is -recognized- (by adding an additional test fo.isVirtual() on the web.xml FO). This fixes the scenario described above, but causes some additional problems (which is IMO more severe than the I have just described). I have already written a scenario which allows you to reproduce the problem when you have the Milan's patch in code: One again: 1) mount a VSS filesystem with clean workdir and repository containing a webmodule 2) try to checkout the whole webmodule (apply checkout action on the FS node) 3) => you will get a bunch of exceptions (attached) and since that the deployment doesn't work. Let me know if this really works for you - to reproduce the first problem use release36 build since Milan has intergrated his path to trunk. To reproduce the second one please use trunk.
First, when you are talking about "checkout" I assume you mean "Get Latest Version", since "Check Out" does not pull the individual files. Please correct me if I am wrong. I see what I was doing differently (and it worked for me because of that) -- in release36 if you do not click on the WEB-INF node and you first do "Get Latest Version" it works ok, assuming you have META-INF/context.xml in the source tree. If you do not have it you need to get latest version and make the root folder writable (outside of IDE) before expanding WEB-INF or clicking on it so that the IDE can create the META-INF/context.xml in the root folder. In trunk I do not get any exceptions at all. I mount a vss with empty work dir and "get latest version" and everything works. If I first expand the WEB-INF node then nothing happens (what is good) but after I "get latest version" I cannot make the IDE recognize the web module. In summary, expanding WEB-INF node before you "get latest version" is problematic, without Milan's fix it throws exception, with the fix it does not throw anything but does not work either. As I described earlied it is not clear to me how to fix this. Unless somebody has an idea Milan should ask for waiver for 3.6 - at least I see a workaround we can advise (do not touch "WEB-INF" before getting latest version or if you do restart IDE after you get the latest version). You can still choose whether to apply his patch or not. regards.
Thanks Pavlet for evaluating this. Regarding the function of the 'Check out' command in VSS: as far as I know it is different from the CVS. In VSS you can use the checkout either for folders (they are named projects in VSS terminology) or for individual files. The meaning of the checkout is something like 'I wanna work on the file exclusively' - so it's locked for others until you commit it back or perform undo checkout command. If you use the 'Get Latest Version' command for individual files in the VSS workdir when using Milan's patch (trunk) the behaviour is as you described - it works without exceptions but the webmodule is not recognized. The workaround is to unmount and mount the FS. Then it's recognized well and deployment works. Since it seems it's not easy to find a safe fix for this we agreed with Milan to waive this problem and probably add a comment how to avoid the situation into release notes. To summarize this: When using Milan's path: o you can click to WEB-INF without any exception o you can checkout / get latest versions of individual files, but then the webmodule is not recognized (workaround for this is described) o you CANNOT checkout the whole filesystem at once (performing the checkout on FS root) since it produces a lots of exc. and makes the deployment impossible. Without Milan's patch: o you CANNOT click to WEB-INF, otherwise you get a buch of exceptions and deployment doesn't work o you can do the checkout of the whole webmodule In my opinion the state without the patch is better - user can checkout whatever s/he wants and only has to be aware of that s/he must not click on the WEB-INF node before checking out the files.
Note that the some problem applies for PVCS!
On behalf of Milan Kuchtiak: - the fix would require to make deeper changes in web-apps architecture since the web module filesystem doesn't count with virtual file objects - it's too risky for now
No objections came from Bug Waiver Council members.
I suggest to mention this problem in release notes in VCS or Webapps section. There should be mentioned something like that it's necessary to checkout the whole webmodule before expanding the VSS or PVCS filesystem node otherwise it a subsequent deployment is not possible.
Marek, at this point in the release cycle, please CC me and John when something is marked RELNOTE so that we know to start working on it right away. proposed relnote: In VSS filesystems, the web module commands in the contextual menu do not work if the VSS repository is not yet checked out. Workaround: Check out the VSS repository before working with the web module.
I am sorry Patrick to forgot to CC you. The suggested text is not -right- since the problem is in something else. The release notes text should be something like: It is neccessary to checkout the whole webmodule in PVCS and VSS filesystems just after mounting it, otherwise the deployment of the webmodule will not be possible. (the main problem is that the VSS&PVCS filesystems created a virtual nodes for files residing in repository and not in workdir. The webmodule code is -confused- and thinks that this is a valid webmodule (even if there are no physicall files)).
OK. Another attempt. Also, is the workaround as I stated it necessary? Or is it sufficient just to check out the web module to get it to work? Description: In PVCS and VSS filesystems, if you have not checked out the complete web modules from the version control system immediately after mounting the filesystem, you can not deploy the web module. Workaround: Unmount the filesystem. Then remount the filesystem and check out the web module immediately afterwards.
Hi Patrick, Now the description is even better, but anyway I would change the ending: ... after mounting the filesystem, you must *not* expand the filsystem node, otherwise the webmodule deployment wont be possible. Workaround: Checkout the whole webmodule before expanding the filesystem node. The workaround you suggested is appropriate when the user expands the filesystem node - then the webmodule is wrongly recognized and nothing works properly. The only way how to get rid of it is to restart IDE or unmount/mount the filesystem.
OK, that feedback helps, so here's another try: Description: In PVCS and VSS filesystems, you have to check out the complete web modules from the version control system immediately after mounting the filesystem. If you expand any of the nodes in the filesystem before checking out the web module, you can not deploy the web module. Workaround: If you have expanded folders in the filesystem before checking out the web module, unmount the filesystem. Then remount the filesystem and check out the web module immediately afterwards.
This issue seems not be relevant to the current web project architecture. Web module filesystem was replaced by web project.
v