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.
Build: NetBeans IDE Dev (Build 200908030201) VM: Java HotSpot(TM) 64-Bit Server VM, 11.3-b02-83, Java(TM) SE Runtime Environment, 1.6.0_13-b03-211 OS: Mac OS X, 10.5.7, x86_64 User Comments: mschovanek: Opened 'Configuration FIles > sun-web.xml' from ejb31-war web project from Java EE 6 samples. Stacktrace: java.lang.NullPointerException at org.netbeans.modules.j2ee.sun.ddloaders.multiview.web.ServletMetadataReader.genProperties(ServletMetadataReader.java:79) at org.netbeans.modules.j2ee.sun.ddloaders.multiview.web.ServletMetadataReader.run(ServletMetadataReader.java:69) at org.netbeans.modules.j2ee.sun.ddloaders.multiview.web.ServletMetadataReader.run(ServletMetadataReader.java:58) at org.netbeans.modules.j2ee.dd.impl.web.metadata.WebAppMetadataModelImpl$1.call(WebAppMetadataModelImpl.java:93) at org.netbeans.modules.j2ee.metadata.model.api.support.annotation.AnnotationModelHelper.runCallable(AnnotationModelHelper.java:252) at org.netbeans.modules.j2ee.metadata.model.api.support.annotation.AnnotationModelHelper.access$100(AnnotationModelHelper.java:82)
Created attachment 85690 [details] stacktrace
to reproduce: ------------- 1) open the sun-web.xml and select the Servlets section in the Multiview Editor ERROR: IDE throws the NPE
NPE is caused by metadata model api violation -- metadata root should not be null, even when web.xml is not present and there are no annotations. In such case, an empty root should be passed. See how ejb-jar.xml is handled (EjbJarMetadataImpl.java and EjbJarMetadataModelImpl.java constructors). Not sure who to reassign this to, so reassigning to issues@j2ee.
Re. "NPE is caused by metadata model api violation -- metadata root should not be null, even when web.xml is not present and there are no annotations. In such case, an empty root should be passed." - right now it is different. WebAppMetadata.getRoot() is documented to return null which I think is better than returning "empty root". It clearly says there is no web.xml. WebAppMetadata has new methods which represent merged information from different sources, eg. WebAppMetadata.getServlets() returns all servlets defined via annotations and web-fragments and web.xml. org.netbeans.modules.j2ee.sun.ddloaders.multiview.web.ServletMetadataReader should be fixed to use this new API.
So WebAppMetadata api has different lifestyle characteristics from EjbJarMetadata? Is this wise? I know the web vs ejbjar dd api design and implementation have many differences, but I've been trying (hoping) to encourage normalization of behavior. The point of metadata api is that the consumer should be insulated from where the data is coming from (web.xml or annotations) as much as possible since most of the time, the source of a dd node is irrelevant. When it is relevant, there are api's to determine the answer. Additionally, having the root always exist avoids an entire level of null checks in the consumer code. I can work around this, but I really think the standard dd code should all behave the same (web metadata, ejbjar metadata, application metadata, appclient metadata).
I can see your point and in general I agree that web and ejb models should behave similarly. And it would be unwise to change behaviour without a reason. On the other hand I think that modelling merged web application deployment model using WebApp interface is wrong from architecture point of view. It would be beneficial to insulate clients from where data are coming from but that has disadvantage as well: if a client tries to update that model (for example adding a new Servlet) they would ended up with an exception that modification is not supported (actually out of 100 methods of WebApp only about 5 would be implemented)(this itself is pretty ugly IMO). So in that respect I would prefer clients to be aware that WebApp represents physical web.xml file and it can be read/written as needed and merged data are provided some other distinctive way. My first reason though why I would not want to model merged DD as WebApp is that WebApp interface is not a superset of DD attributes. With EE6 we've added WebFragment which extends WebApp and which has additional attributes (mostly ordering related). I know that we will not need these in the merged model and they could be ignored but strictly from architecture point of view these are different data and therefore should not be model via subset interface. Rather then that a dedicated interface (or list of methods) for merged model should be added. And that's why we enhanced WebAppMetadata. What do you think? I'm open to any changes. I just wanted to clarify why we did it this way.
I understand. It's easy to put in the null check so let's do that.
Fixed -- http://hg.netbeans.org/web-main/rev/e7cee39c57cd Wait for integration notice before testing.
Integrated into 'main-golden', will be available in build *200908140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e7cee39c57cd User: pcw@netbeans.org Log: #169730 Fixed NPE when web.xml does not exist. Preempted potential similar case wrt/ ejb-jar.xml.