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.
We had originally designed the JSP wizard so that it restricted placement to what the IDE considered a web module. This doesn't work well for folks using Jakarta or some variant thereof (placing jsps in a peer to the Jakarta recommended "web" directory. See this thread: http://www.netbeans.org/servlets/ReadMsg?msgId=657966&listName=nbusers, esp "Harsha R" and "snpe" for their webapp structure. The soln for this release would be to allow the choice of putting within a web module or within a chosen directory, same as the Servlet and Filter wizard. (Radio button and combobox choosers) Though not ideal, it's the best we have until the IDE has a better notion of a web project and correct placement of objects such as JSPs.
Note that I will not be able to bugfix tomorrow. When is UI freeze?
Even if we allow creating JSPs outside a web module, how will the user deploy it? Will that work? Re. UI freeze: Ana, I suggest you talk to Chris and ask when she needs the UI finalized.
Since we originally agreed not to support JSPs placed outside of the webmodule the QE doesn't support this 'defect' to be fixed for probo-B. I suggest to change this bug to enhancement and let it to be solved in promo-D. There is no real need to do such a change now, and as Peter Jiricka mentioned, there would be some limitations (JSPs not executable, validable) and also problems regarding this change like taglibs code completion not working etc. It seems to be a good solution to put this off to the promo-D which is going to introduce the new build system, that can be IMO customized for this purposes better. At last but not at least the QE has no resources for testing this feature for it would have very likely an extensive impact.
This bug was filed in response to user feedback on nbusers. The reason for filing it is that we wish to support people who use the Jakarta source structure. Ann and I assumed erroneously that people who use this source structure would mount both the top level directory (which contains the ANT build script); the classes directory (to compile JSP) and the doc source directory (for web components). Technically, this already meant that we had to support placing JSPs outside of web modules, because the docsrc of the Jakarta source structure does not have the attributes of a web module (e.g. no WEB-INF/classes). However, because of issue 38252, such directories are automatically (if erroneously) corrected to web modules, so we skipped the arbitrary placement of JSPs for now. As you can see in issue 38252 I point out that the wizard has to be modified when this bug is fixed. The problem was that a poster (snpe) on nbusers reported that he could no longer create JSPs because he only mounts the root of the Jakarta directory and classes, not the docsrc. The bug report should have contained a link to this discussion, as it is relevant to the priority assigned to the bug. (Further, this prevents users from creating new JSPs from the templates on the options tab, should they choose to do so, but I doubt many people know about that option). In essence, this is the same problem as we have with Servlets. We have to allow people to create Servlets outside web modules too (they clearly can't be executed there either, and we can't modify the deployment descriptor). But we can't prevent people from working with ANT either. I'm reopening, because I think Ann should have the final say as the one who filed the bug.
> he only mounts the root of the Jakarta directory and classes, not the > docsrc. If this is the case, is't a simple workaround to just mount the docbase as well? Also, the important question here is whether the user has web.xml under $DOC_BASE/WEB-INF, or in some kind of a "conf" directory. Does anyone know? This makes all the difference.
We-ell it's a simple workaround but IMO it's not an obvious one, so I am not sure if it will be discoverable to users. If it happened to me, it wouldn't occur to me that mounting the doc source directory might work, because as far as I know, that's not an expanded WAR. There's no way I can know that the IDE treats it as such because of the bug reported in issue 38252 :) Whether they have a deployment descriptor or not in there depends. If they generate the DD with XDoclet, then they won't. I think the vanilla recommendations at the Jakarta developer site does have an explicit web.xml in place.
Ok, I'll ask again the following question: if we do allow creating JSPs outside the web module, and user does this, what will the user be able to do with this JSP? What will work? And here's my answer: - JSP editor will work a bit, but code completion will not work well, as tag libraries will not be found. - Deployment and debugging will not work, as the filesystem root will be deployed as the docbase. - JSP validation will not work, as syntax like <%@include file="/included.jspf"%> relies on the knowledge of docbase. - HTTP Monitor will not work, because deployment does not work and we can not expect the users to discover how to deploy it manually. Is there anything left that _will_ work? So my final opinion is this: for several years, we've had the limitation that DocBase == filesystem root. Even though this certainly has usability issues, this actually works, and that's what we've designed for. Changing that is not a casual bugfix, but a wholesale architecture change, that will happen when we have projects aka build system. Let's accept that for now and tell the users to mount the document base.
Ana - the link to the nbusers thread is linked in the original description of the issue. To answer Petr - Yes, one can mount the docsrc as a workaround, though the snpe poster mentioned some side effects - the context path changing to "/web" (b/c we take the context path automatically from the mounted filesystem. SNPE also mentions some issues with wanting to refactor from the app base, instead of just the web/. I'm unclear on the impact of that. As noted before in the informal survey I did on how IDEs and developers structure web app src, 10/15 have web.xml under WEB-INF*, and 5/15 didn't. *Note, that WEB-INF/web.xml isn't necessarily directly under *DOC_BASE* as defined by jakarta tomcat docs. I'm willing to live with this issue for promoB given the impact at this stage. chris already has an article on how to work with Jakarta structures within the IDE, which should help too. this might be good to note for knowledge base or in online help itself.
Duh, apologies for the comment about the thread reference. I think this is for Ann and Petr to decide, and I'm obviously not wild about starting any work on the wizard before I go on vacation, I just want to make sure we have all the info :) Petr, you are of course that a lot of things won't work in this scenario (which is, btw, why Ann and I made the assumption to start with) but clearly the person who brought it up disagreed). My suggestion would be that Ann and Petr review the thread and see if you agree with the guy (as far as I remember he is actually using Eclipse for most things and only starts Netbeans for the JSP functionality, so there must be enough left for him). Perhaps the best option is to sit tight for a while and wait for the beta feedback? If so I recommend reassigning it to Ann. It's a shame we can't have a "Pending more feedback" evaluation....
Yah, I was hoping for beta feedback too. Starting today, right ? =) From the email thread we had two users discuss this issue. snpe was given the workaround and seems to work with it, minus the few issues I mentioned. Harsha R will have troubles with the way we set things up now, since the directory for the jsps is a peer to the web/ directory instead of within it , as the jakarta recommended src structure.
I have met with one other developer who uses a different structure for developing web apps (neither Jakarta, nor expanded WAR), FWIW.
*** Issue 39912 has been marked as a duplicate of this issue. ***
I would just like to comment on this further about the recent change in 3.6. I am in favor of leaving it the way it was in 3.5, being able to use the JSP wizard without needing a web module, and being able to compile and view the JSP servlet code without having to execute it. Some of us do not use JSP's in web modules; therefore this change has rendered the JSP editor in NB not much better than notepad :-). There is no need to be forced to use the Tomcat server and web module to test a JSP when I have my own separate developement server for that purpose. Trying to implement an all in one solution into the editor makes the setup and usefulness of the editor too complicated. rgds
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss