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.
Hi, I have some problem with the tomcat integration when I used an application for the ROOT context. By default, the ide create a context like this : <Context docBase="E:\sandbox\Webification\webapp" path="/"/>. When I launch tomcat, it create a file .xml instead of ROOT.xml. In order to make it work, I change the context to : <Context docBase="E:\sandbox\Webification\webapp" path=""/> but when I restart the ide the "" goes back to "/".
This is a P3 so I am setting target to promo-D but I would appreciated opinion of QA about the priority. If they think it is a P2 we may want to try fixing this for 3.6. The IDE is indeed setting the context every time you restart the IDE or mount the web module and you have an empty context path or the META-INF/context.xml does not exist at all. The first condition was there before Ana (avk@netbeans.org) added the UI for context path into the web module wizard (since before Ana's change there was no other way to ensure a "reasonable" default) and it could now be removed. The context is set to the name of the folder in which you have your web module, in your case to "/webapp" -- unless you have imported the module from 3.5 in which case it will set it to the value that was set in 3.5 (that is probably your case and you probably had "/" set in 3.5, correct?)
No , i didn't import a NB 3.5 project. I use to recreate the project when I change NB version. Our project is a CVS one with some "src-xxx" directories and a webapp. We use treef to "mount over filesystem" the src and webapp directories. When nb mount the webapp, it set the "/" context. The only workaround I found for the moment is to modify the context. xml to "" and after put the file read-only in windows. It is very important for use because with the "/", we get all the links like "http://xxx.gif".
The user is right - when you set the context path property of a webmodule to an empty string and then restart the IDE the property is changed to a default value. Since it's really annoying and in fact a corruption of a valid property value, it should be fixed in promo-B, so increasing the priority to P2.
I putted code in trunk that does not change the value found in context.xml except when upgrading from 3.5 when I take the value stored in 3.5 format (and then delete the old format do this is only done once) -- that upgrade code is there to solve another bug. My testing looks ok. This could potentially have impact on various ways of creating WM (from wizard, mount a 3.5 wm, convert to WM) in combination with "" set as context value. I would like Martin to review the code and commit to release36 tommorow night if all works.
Created attachment 13885 [details] diff commited into trunk
Marku, would you please verify the fix in trunk so that Martin can integrate it later to release36 branch ? Thanks !
I have checked this and found only one problem: When an user has a webmodule in nb3.5 with context path set to an empty string and then imports it into 3.6 the context path is changed to the webmodule directory name. Since the user can change the property easily I do consider this fix as acceptable.
Well, we specifically discussed the import issue and specifically agreed that the web module should continue to use the empty path, because many applications are not contextpath-independent. So I think this is a bit more serious.
The mentioned problem is the only one I found while reviewing the code. It can be fixed, too, by some better differentiation of "" and null in getURIParameter().
Now the user can change the property and it preserves the IDE restart - that differs from the previous state. If this can be fixed completely (as Martin mentioned) it will be great! Since we pay so much attention to this problem I have another one which seems to me to be important and is also about deployment to an empty context path: <a href="show_bug.cgi?id=40837">40837</a>
Created attachment 13914 [details] diff for additional fix
Thanks for catching this. I think the fix is simple but please review and test again. The getURIParameter() is not used anywhere else so returning null should not break anything. (well, in fact it is referenced from private String getContextPath() in CompileData which is called only from another private method: private String getContextRootString() -- and that one is not called anywhere. .. so just dead code..)
Pavle, what does the else if (ctxRoot.equals ("")) { ... } part do? Why is "" context special?
Martine, you are right, this else part of this condition should be removed. I have problem accessing cvs. Can you integrate that change in to day? At least in trunk so that I can integrate in 36 tomorrow. Thanks.
Integrated in trunk: http://web.netbeans.org/source/browse/web/core/src/org/netbeans/modules/web/context/WebContextObject.java.diff?r1=1.68&r2=1.69 Marku, please test it so that we can finally get rid of this ;O)
I have tested the latest trunk sources and it works - even the problem with import. Unfortunately I found an additional problem with the imports: When an user has a webmodule in 3.5 with context path set to a string without leading slash, the deployment works in 3.5. However after import of such a module to 3.6 the deployment doesn't work until the user adds the leading slash to the context property. Even if having context without leading slash is not according to the specification, it worked in 3.5 and it can confuse users. Please try to fix also this problem.
Fixed in trunk, so I believe this is the final diff: http://web.netbeans.org/source/browse/web/core/src/org/netbeans/modules/web/context/WebContextObject.java.diff?r1=1.65&r2=1.70
Martine, thanks. The diff that should be merged is what you propose _minus_ the 1.67 which was an implementation of an unrelated task in trunk. ---------------------------- Revision : 1.67 Date : 2004/3/9 14:24:21 Author : 'mkuchtiak' State : 'Exp' Lines : +1 -1 Description : Tasks 39900, 39905 - hadling invalid DD states (status and error properties added to WebApp class) - changes that enable clients working with copy of s2b bean graph rather than with original There is probably some anomaly around this issue ;-)
I did the following tests once more: create 3 web modules in 3.5.1 with context paths set to "", "/" and "/foo" and imported them in 3.6. It imports the context path correctly and removes the old format of value. Thne I restarted the IDE to verify that it will not iniciatively change any of the values (esp. ""). Everything looks ok. I merged the 1.70 into release36 (without the change made in 1.67).
I checked it on release36 branch and it doesn't work as I would expect. Context Path "/root" is imported correctly. Context Path "root" is imported correctly as "/root". Empty Context Path "" is imported as directory name "dirname". I would expected to leave it empty. Context Path "/" is imported as illegal context path "/" which lead tomcat to unstable state. This webmodule is stopped and can't be undeployed. I would expect to import it as empty context path "".
Did you use a regular build (which one), or did you build it yourself?
I built it myself because I suppose the fix isn't in regular build yet.
Since the main problem (unwanted change of empty context path after restart) was fixed I downgrading to P3. I would add remaining problem to release notes, e.g.: "If you import webmodule with empty context path from NetBeans 3.6, the context path will be changed after import to name of directory where webmodule resides. You can change the context path back to empty one. Remember, due to another bug #40837, you have to manually undeploy webmodule with empty context path deployed outside IDE."
I agree with release noting it. Problem with importing of "" is that if you never changed it, then the value contains null and we do not know whether to import or not. If you manually changed the value to "" then it should work. Import of "/" is a problem that could be fixed, too, but we spent quite a time on this issue, and I don't think it's worth it, so I'm replanning this to promo-D.
Bug to release note. Adding Patrick to CC.
Here's an attempt at the relnote. I don't understand the last sentence, so I will try to insert clarifying details. Please tell me if I'm getting it wrong (which I probably am) and how. "Description: If you import a web module with an empty context path into NetBeans IDE 3.6, the context path will be changed to the name of the directory where the web module resides. Workaround: You can change the context path back to the empty one. However, due to issue 40837, you have to manually undeploy the web module in the IDE before deploying it outside the IDE. "
As you noticed, I incorrectly wrote "import from NetBeans 3.6". I meant "import from NetBeans 3.5" and I would write it by this way to emphasize that the webmodule was created in previous version of NetBeans. User can also 'import' webmodule created himself or in another IDE. The second bug 40837 says if you deploy webmodule with some context path and another webmodule with the same context path was already deployed outside IDE, it will fail. Since Tomcat has by default deployed documentation under empty context path (root), deployment of other webmodule with empty context path inside IDE will fail. Workaround is to manually undeploy old webmodule which was deployed outside IDE. I would change workaround to something like this: "Workaround: You can change the context path back to the empty one. However, because Tomcat has by default documentation under empty context path and because of issue 40837, you have to manually undeploy it before deploying your webmodule with empty context path."
Libor, thanks for the further explanation. Based on what I think I've learned, I've completely changed the wording of the workaround. Please review again. "Description: If you import a web module with an empty context path from NetBeans IDE 3.5, the context path will be changed to the name of the directory where the web module resides. Workaround: Undeploy the web module with the incorrectly changed context path. Then change the context path and redeploy the web module. (You must go through this procedure because Tomcat has its documentation under the empty context path by default and because of issue 40837)."
The workaround is not correct. You have to undeploy webmodule with documentation. If you import webmodule then it isn't deployed yet. So correct workaround process is following: 1. Change context path of your webmodule to empty one. 2. Undeploy Tomcat's default webmodule with documentation which has also empty context path. 3. Execute (it means deploy) your webmodule. Step 2 should not be needed, but it is because of issue 40837. If you skip this step, execution in step 3 will fail.
OK. I think we've got it now: 1. Change the context path of your web module to the empty one. 2. Undeploy Tomcat's default web module along with its documentation, which also has an empty context path. (This step is needed because of issue 40837). 3. Execute your web module.
Patrick, The second item seems to be to confusing little bit, specifically the part ... along with its documentation ... . I am not sure, maybe it's my language problem, but I would understand the sentence that I have to undeploy the -default- webmodule mapped to / and I also have to undeploy it's documentation. What is basically false. My suggestion to item #2 is: 2. Undeploy one of the Tomcat's default web modules mapped to the empty context, which in fact contains Tomcat's documentation. (This step is needed because of issue 40837). Marek
OK. I'll reword step 2 to the following: 2. Undeploy one of default Tomcat web modules that is mapped to the empty context, which in fact contains Tomcat's documentation. (This step is needed because of issue 40837). The final result will be here in a few minutes http://testwww.netbeans.org/community/releases/36/relnotes.html
won't fix - import from 3.5 to 4.0 is not supported so it makes no sense to fix in 40