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 40251 - j2eeserver always returns 1.4 for J2EE version.
Summary: j2eeserver always returns 1.4 for J2EE version.
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Nam Nguyen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-18 21:03 UTC by _ pcw
Modified: 2004-02-27 08:26 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pcw 2004-02-18 21:03:22 UTC
NB 3.6 may not support creating Servlet 2.3 spec
web apps, but it should be able to load existing
ones (created, for example, by NB 3.5).  You can
fake creating one by creating a webapp and in
web.xml change the servlet spec version from 2.4
to 2.3.

However, on doing so, the DDBeans still identify
themselves as J2EE 1.4.  The behavior is as follows:

DDBeanRoot.getDDBeanRootVersion() is not
implemented (hardcoded to return null).

This JSR88 method is the preferred method to use
for determining the J2EE version of a module.

DDBeanRoot.getModuleDTDVersion() returns "1.4". 
This method is supposed to be replaced by the
above method though.

DeployableObject.getModuleDTDVersion() returns
"1.4".  This method is deprecated in JSR-88 1.1 also.

Anyway, for a Servlet 2.3 webapp, I believe all of
these methods were supposed to return "1.3".
Comment 1 Nam Nguyen 2004-02-19 16:06:26 UTC
Do we support generating/saving web.xml 1.3 version?  If not I don't
this is a bug. Peter:  I still don't understand the issue.  A J2EE 1.4
web.xml still can refer to 2.3 servlets.  So having a 2.3 servlet in
the module, I don't think it should mean we should save web.xml as
J2EE 1.3?
Comment 2 _ pcw 2004-02-20 17:08:05 UTC
So it looks like I misstated the version numbers then.  So, for a web
app implementing Servlet 2.4, should the version methods return "1.4"
or "2.4".  In order to allow distinguishing a Servlet 2.3 webapp from
a Servlet 2.4 webapp inside an EAR for example, it seems they would
have to return the Servlet Spec version, not the J2EE version.  Does
anyone have a different reading of the JSR-88 specification?  It is
not clear on this distinction as far as I can tell.
Comment 3 Pavel Buzek 2004-02-23 23:23:43 UTC
Web module now returns 2.3 or 2.4 as its version and 
DDBeanRoot.getDDBeanRootVersion() delegates it.

I think there was also a problem that the xpath events were lost after
the version changed and I am not sure if that was filed separately. I
am reassigning to Nam to check this and fix if needed.
Comment 4 Nam Nguyen 2004-02-25 00:54:19 UTC
What j2eeserver listens to is the BaseBean returned from the
J2eeModule.getDescriptor() call.  Even though the WebApp root object
survive the version reparsing, this contained BB is gone with the
discarded old graph.

So I don't see we can avoid the need of explicit API to detect module
version change something like:

J2eeModule {
   void addModuleVersionListener(VersionListener vl);
}

This seems to be not reasonable at this time.  So, I think the best we
can do is documentation and minimize the effect by allow the action of
close/open the ConfigDO to be the manual refresh of the whole DDBean
and ConfigBean caching.
Comment 5 Nam Nguyen 2004-02-27 08:26:51 UTC
Complete the fix with VersionListener implementation.
On version change we do save if needed, disposal of uneeded listeners,
reload configuration storage, refresh ConfigBeanTopComponent.