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 177912

Product: javaee Reporter: masvacaquecarnero <masvacaquecarnero>
Component: DD EditorAssignee: Andrey Yamkovoy <kaktus>
Severity: normal CC: dkonecny, kganfield, matthies, pjiricka
Priority: P2 Keywords: RELNOTE
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 153863

Description masvacaquecarnero 2009-12-01 05:39:39 UTC
Netbeans appears to be too much dependent on the net.

When I open a project based on Servlet 2.3 or 2.2, the IDE seems to download things from the net. So, this error appears when I am not connected to the net, but it is a symptom of a more serious problem.

When the connection is unreliable or too slow (as it is often the case for me), the IDE just blocks, or shows 'slowness detected' on simple things like poping up the context-menu when pressing right button on project name.

Switching to the schema-based 2.4 Servlet specification seems to be a workarround
Comment 1 Petr Jiricka 2009-12-02 07:28:14 UTC
Yes, we stopped supporting servlet 2.3 in this release, and removed the associated code. This specification is a part of J2EE 1.3. We still support J2EE 1.4, Java EE 5 and now Java EE 6.

What kind of application, and what kind of server do you have? Is it just a very old application that was originally developed against J2EE 1.3? Or is it newer? Is updating to the 2.4 schema an acceptable solution for you, or is it problematic for some reason? Thanks.
Comment 2 masvacaquecarnero 2009-12-02 10:08:22 UTC
If you removed the associated code, why not keep the dtd around for the ones that don't want or cannot to move forward?. Even if there is no support for the old-style web.xml, it shouldn't cause these many issues. It definitely should not give random exceptions, refactoring fails or hog down the entire IDE.

IMHO, this is a very serious bug, which affect very negatively the performance of the IDE. For tour benefit, please remove the feature completely, or at least inform the user J2EE 1.3 is no longer supported and that there are going to be unexpected issues.

Note that is the least of the problems, something like ConnectTimeout is waaay more unconfortable (nonresponsive IDE for about 30 seconds). And for sure, you don't have thouse in the analytics server, neither on issues. Some coworkers just killed the IDE after it could not open the application and went back to 6.5.

This happens on an old and big (more than 1m loc) enterprise application originally coded against J2EE 1.3. The migration to maven was a huuuge pain. A change in web.xml not easy to commit without anyone noticing and asking questions.
Comment 3 Martin Schovanek 2009-12-02 13:31:46 UTC
A workaround could by to add the missing DTDs into: 'Tools > DTDs and XML Schemas > User Catalog'. Please let me now if it helped.
Comment 4 David Konecny 2009-12-02 14:14:46 UTC
Release notes for NB68 should say that JEE1.3 is not supported and that in order to continue developing JEE1.3 apps users should stay with NB6.7.1. Ken, are you the person who can make sure that it will be added to release notes please?

I agree that while removing JEE1.3 related functionality the DTDs/Schemas could/should have stayed in the code base. However, unless there is *very* strong demand for this I do not plan to re-add them back. I'm sorry for the inconvenience it causing you and your team. Workarounds are (in order of preference):
* stick with NB6.7.1; or
* upgrade to JEE1.4; or
* re-add DTDs by hand via 'Tools > DTDs and XML Schemas > User Catalog'
Comment 5 _ ludo 2009-12-02 15:20:48 UTC
not very happy about that.
The EE 6 spec allows old specs and old dtds or schemas, so all of them should be registered.
Our eclipse plugin does that, by the way.
You'll be amazed by the number of people using old legacy apps with minimal changes for EE 5 or 6 runtime.
See also the lib/dtds area of GlassFish v3: it contains them all!

I would reconsider your choice...
Comment 6 David Konecny 2009-12-02 15:49:34 UTC
Unfortunately it is too late to change this for 68 release. We could add them back in a 68patch if this should become common problem.
Comment 7 Kenneth Ganfield 2009-12-03 04:44:43 UTC
I will add this to the release notes for 6.8.

Would it be possible to modify the summary to reflect the actual issue?
Comment 8 Martin Schovanek 2009-12-03 08:04:38 UTC
According the Ludo's comment please reconsider to re-adding the J2EE 1.3 DTDs.
Comment 9 _ ludo 2009-12-03 10:09:28 UTC
of course, not a release stopper, but a good candidate for the patch release
Comment 10 David Konecny 2009-12-03 14:43:50 UTC
Martin, isn't NB68 FCS build running right now?

I will have a look at reverting removal in trunk and later we can decide when we will release it. I do not think this is show stopper either. I agree with Ludo that developers out there using often very old technologies, but on the other hand this is first and single report complaining about this.
Comment 11 Petr Jiricka 2010-02-02 05:29:11 UTC
Andrey, can you please look into fixing this? Thanks.
Comment 12 David Konecny 2010-02-02 12:42:15 UTC
Considering there are no votes, not many duplicates by exception reporter I'm tempted to downgrade this to P3 and remove 68patch-candidate. What others thing about this? QA? On the other hand fix is simple. There is also bug 179178 which scope could be expanded to notify also about old version of web.xml and other DDs.
Comment 13 Petr Jiricka 2010-02-03 05:53:20 UTC
I think the most problematic part is that if a version of web.xml is not suppored, the IDE still throws an exception, see e.g. this report:

Even if we don't re-add the schemas, I think at a minimum, we should avoid or hide the exception.
Comment 14 David Konecny 2010-02-03 13:41:59 UTC
Let's add schemas then.
Comment 15 David Konecny 2010-02-28 13:27:00 UTC
*** Bug 176429 has been marked as a duplicate of this bug. ***
Comment 16 David Konecny 2010-03-26 03:34:02 UTC
This has been fixed as part of my work on issue 179178.

*** This bug has been marked as a duplicate of bug 179178 ***