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.

Bug 39670 - JSP wizard should be flexible in placement
Summary: JSP wizard should be flexible in placement
Status: RESOLVED WONTFIX
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Ann Sunhachawee
URL:
Keywords:
: 39912 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-05 22:01 UTC by Ann Sunhachawee
Modified: 2016-07-07 08:54 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ann Sunhachawee 2004-02-05 22:01:24 UTC
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.
Comment 1 Ana.von Klopp 2004-02-06 01:49:05 UTC
Note that I will not be able to bugfix tomorrow. When is UI freeze?
Comment 2 Petr Jiricka 2004-02-06 09:01:32 UTC
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.
Comment 3 Marek Fukala 2004-02-06 09:39:42 UTC
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.
Comment 4 Ana.von Klopp 2004-02-06 18:14:44 UTC
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. 
Comment 5 Petr Jiricka 2004-02-06 18:21:12 UTC
> 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.


Comment 6 Ana.von Klopp 2004-02-06 18:44:04 UTC
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. 

Comment 7 Petr Jiricka 2004-02-06 18:59:06 UTC
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.
Comment 8 Ann Sunhachawee 2004-02-06 19:19:56 UTC
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.

Comment 9 Ana.von Klopp 2004-02-06 20:15:26 UTC
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....


Comment 10 Ann Sunhachawee 2004-02-06 20:49:44 UTC
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.

Comment 11 Ana.von Klopp 2004-02-09 16:16:21 UTC
I have met with one other developer who uses a different structure for 
developing web apps (neither Jakarta, nor expanded WAR), FWIW. 
Comment 12 Ann Sunhachawee 2004-02-12 17:18:03 UTC
*** Issue 39912 has been marked as a duplicate of this issue. ***
Comment 13 leejk421 2004-04-29 15:56:23 UTC
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
Comment 14 Martin Balin 2016-07-07 08:54:54 UTC
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