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.
This is a maven project. Whenever I "find usages" for any class, the ide returns an error: INFO [global]: Refactoring plugin threw exception: java.lang.NullPointerException at org.netbeans.modules.web.jsf.refactoring.Occurrences.getAllOccurrences(Occurrences.java:416) at org.netbeans.modules.web.jsf.refactoring.JSFWhereUsedPlugin.prepare(JSFWhereUsedPlugin.java:113) [catch] at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare(AbstractRefactoring.java:358) at org.netbeans.modules.refactoring.api.AbstractRefactoring.prepare(AbstractRefactoring.java:181) at org.netbeans.modules.refactoring.spi.impl.ParametersPanel$Prepare.run(ParametersPanel.java:733) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:539) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:964)
Created attachment 49305 [details] The logfile showing all stack traces
Is the project web application with jsf? Or does it happen for every invocation Find usages independently on the kind of project?
The Project is a Maven Proyect. It is not a web project. But... I made a "web project with existing sources". Same Exception.
Maybe I shoud clarify. I made a "web project with existing sources" and configure it so it would generate the same .war, and tried to find usages. It came back with the same exception. Maybe it has something to do with the application itself. This application is using spring framework integration with jsf, myfaces instead of the ri and apache trinidad and tomahawk components. It is also using web services using apache cxf and the jaxb reference implementation.
Thanks for the message. Could you describe the structure of your project, I would like to reproduce this. I'm interested mainly where is faces configuration file and which version the faces configuration file has. Could you provide a snapshot of expanded nodes of your project?
Created attachment 49511 [details] my faces-config.xml
Created attachment 49512 [details] web.xml
May this help? $ find src -type d -maxdepth 3 |grep -v svn src src/main src/main/assembly src/main/java src/main/java/name src/main/resources src/main/resources/spring src/main/webapp src/main/webapp/css src/main/webapp/if src/main/webapp/images src/main/webapp/META-INF src/main/webapp/wav src/main/webapp/WEB-INF src/site src/site/apt src/site/resources src/site/resources/figures src/site/resources/pdf src/site/resources/screenshots src/test src/test/java src/test/java/name src/test/java/general src/test/java/helper src/test/java/procesos src/test/resources
All dependencies acegi-security-1.0.3.jar activation-1.1.jar antlr-2.7.6.jar antlr-runtime-3.0.jar aopalliance-1.0.jar asm-1.5.3.jar asm-attrs-1.5.3.jar aspectjweaver-1.5.3.jar cglib-2.1_3.jar commons-beanutils-1.7.0.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-csv-1.0-SNAPSHOT.jar commons-dbcp-1.2.1.jar commons-digester-1.6.jar commons-el-1.0.jar commons-fileupload-1.0.jar commons-httpclient-3.0.1.jar commons-lang-2.1.jar commons-logging-1.1.jar commons-net-1.4.1.jar commons-pool-1.3.jar commons-vfs-1.0.jar cxf-api-2.0.1-incubator.jar cxf-common-schemas-2.0.1-incubator.jar cxf-common-utilities-2.0.1-incubator.jar cxf-rt-bindings-soap-2.0.1-incubator.jar cxf-rt-bindings-xml-2.0.1-incubator.jar cxf-rt-core-2.0.1-incubator.jar cxf-rt-databinding-jaxb-2.0.1-incubator.jar cxf-rt-frontend-jaxws-2.0.1-incubator.jar cxf-rt-frontend-simple-2.0.1-incubator.jar cxf-rt-transports-http-2.0.1-incubator.jar cxf-rt-ws-security-2.0.1-incubator.jar cxf-tools-common-2.0.1-incubator.jar derbyclient-10.2.2.0.jar dom4j-1.6.1.jar ehcache-1.2.3.jar encryptproperties-1.0-SNAPSHOT.jar geronimo-annotation_1.0_spec-1.1.jar geronimo-spec-jta-1.0.1B-rc4.jar geronimo-ws-metadata_2.0_spec-1.1.1.jar hibernate-3.2.5.ga.jar hibernate-annotations-3.2.1.ga.jar jaxb-api-2.0.jar jaxb-impl-2.0.5.jar jaxb-xjc-2.0.jar jaxws-api-2.0.jar joda-time-1.4.jar joda-time-hibernate-0.8.jar jsch-0.1.31.jar jstl-1.1.0.jar jt400-full-5.2.jar log4j-1.2.12.jar lucene-core-2.0.0.jar mail-1.4.jar myfaces-api-1.1.5.jar myfaces-impl-1.1.5.jar neethi-2.0.jar ognl-2.6.9.jar oro-2.0.8.jar persistence-api-1.0.jar poi-3.0.1-FINAL.jar quartz-1.5.2.jar remesas-swift-lang-1.0-a1.jar saaj-api-1.3.jar saaj-impl-1.3.jar spring-aop-2.0.3.jar spring-beans-2.0.3.jar spring-context-2.0.3.jar spring-core-2.0.3.jar spring-dao-2.0.3.jar spring-hibernate3-2.0.3.jar spring-jdbc-2.0.3.jar spring-jmx-2.0.3.jar spring-support-2.0.3.jar spring-web-2.0.3.jar spring-webmvc-2.0.3.jar stax-api-1.0.1.jar tomahawk-1.1.6.jar tomahawk-sandbox-1.1.6.jar trinidad-api-1.0.1.jar trinidad-impl-1.0.1.jar wsdl4j-1.6.1.jar wss4j-1.5.1.jar wstx-asl-3.2.1.jar xml-resolver-1.2.jar XmlSchema-1.2.jar xmlsec-1.3.0.jar
Hi Erno, could you please help Petr with this bug? Thanks.
Sure, I'll have a look at this.
Reporter, thanks for the listings. It is probably the project structure that is causing this problem, it would be great if you could attach your project (or just some mockup project in which this is reproducible) to nail this down. If it is not possible for you to attach the project, could you please specify in which directory you have the faces- config.xml file? Thanks.
I cannot post the entire proyect. Maybe sometime this weekend i can post a smaller one to reproduce the problem. Hopefully this will help $ find . -name '*xml' ./checkstyle.xml ./nbactions.xml ./pom.xml ./private/cache/retriever/catalog.xml ./profiles.xml ./src/books/manual-sistema.xml ./src/books/manual-usuario.xml ./src/main/assembly/dep.xml ./src/main/resources/spring/context.xml ./src/main/webapp/META-INF/context.xml ./src/main/webapp/WEB-INF/applicationContext.xml ./src/main/webapp/WEB-INF/faces-config.xml ./src/main/webapp/WEB-INF/jboss-web.xml ./src/main/webapp/WEB-INF/sun-web.xml ./src/main/webapp/WEB-INF/trinidad-config.xml ./src/main/webapp/WEB-INF/trinidad-skins.xml ./src/main/webapp/WEB-INF/web.xml ./src/main/webapp/WEB-INF/webServices.xml ./src/site/site.xml ./src/test/resources/extraSpring.xml
Thanks, I'm able to reproduce this now so no need to create a project for this. Turns out that the project structure is not the problem, but rather the faces-config.xml file itself - more specifically, the xml namespace declaration in the faces-config element causes the NPE (the code doesn't expect it to be there since it is a DTD constrained document). I will fix it soon, as a workaround for beta 1 removing the namespace declaration helps, i.e. instead of <faces-config xmlns="http://java.sun.com/JSF/Configuration"> have just <faces-config>
I'm attaching a patch with a test case for web/jsf that fixes the NPE. I don't want to commit it now though since even with the patch applied some problems remain. Since the JSFConfigQNames#getQName method takes only a version as an argument, it is not possible to know within this method whether the underlying xml model has a namespace defined or not. Currently we make the assumption that if the version is 1.1, there is no namespace, i.e. the QName returned by that method has a null namespace. This causes all kinds of problems for models like the one in this issue (i.e. the version is 1.1 but a namespace is still defined) since the QNames retrieved from the model differ from the QNames got from the JSFConfigQNames#getQName method. For instance, find usages for managed beans doesn't work correctly in this case - no NPEs, but since the comparison of QNames fail, the reference for the bean is not found in the model. Probably this could be solved by introducing a new JSF version, 1.1 with a namespace. That way existing code using JSFConfigQNames#getQName would not need to be changed. I'm not sure however what kind of overall impact this would have (for the friend modules and otherwise). Petr P, what do you think?
Created attachment 50403 [details] patch for web/jsf
The workarround works. I really appreciate it. For me, it makes perfect sense to change <faces-config xmlns="http://java.sun.com/JSF/Configuration"> to <faces-config> since the document already has a DOCTYPE, and it is an error to include a namespace attribute. I don't know what i was thinking... but... Shouldn't netbeans point out my mistake?
I was also wondering why do you have a DOCTYPE and namespace there. Anyway, a google search revealed that there are also other faces-config files out there with a doctype and namespace, so I think we should still somehow gracefully handle them. But maybe this not a P2 really as the workaround is simple and I can't think of any reason for needing both a doctype and namespace in the file. So I'm downgrading this to P3 for now, if you disagree, please provide justification (I would be interested in whether there is a case when both are needed). Thanks.
I agree, this does not seem serious enough to rush it. However, IMHO, even if using a doctype and a namespace together was legal, and i'm not saying that it is, doing so seems like nonsense and i believe is just looking for trouble. This not only applies to faces-config.xml but on every xml document, and may also affect behaviour on sevlet container (don't know if it actually does). All can be addressed by just issuing some kind of warning. I would have been very gratefull if there was someting to point out a mistake like this. is this worth an enhancement issue?
Hi, Erno (emononen), Looks like we have several issues are related to this faces-config.xml namespace problem. How is the patch you previous provided? I don't see it has been integrated into NetBeans. If that will just introduce some more harmless checking, then I suggest we integrate it into NetBeans 6.1. As I guess, people are trying to migrate their non-NetBeans created projects like Eclipse/Maven projects to NetBeans. The namespace in file faces-config.xml may be unexpected under current NetBeans' codes.
By google searching "java.sun.com/JSF/Configuration", I found that many JSF tutorials do have the following declaration that current NetBeans web/jsf cannot handle! <!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN" "http://java.sun.com/dtd/web-facesconfig_1_1.dtd"> <faces-config xmlns="http://java.sun.com/JSF/Configuration"> e.g., http://www.oracle.com/technology/products/jdev/101/howtos/jsfdrilldown/faces-config_xml.html http://www.jmalin.com/techwriter/portfolio/sample1/sf_rcf_configelements.html http://download-uk.oracle.com/docs/html/B25947_01/appendixa009.htm
Yes, I also noticed that there are some example faces-config.xml out there with DOCTYPE and namespace. Still, AFAIK it is not correct to have both in one file and can't think of any reason why one would want them both. That said, it should be reasonably safe to apply the attached patch, I didn't want to apply at the time as we were so close to the final 6.0 release then. I noticed that the patch doesn't include the test case I wrote for this, I'll attach it here.
Created attachment 55474 [details] test
As discussed with Petr Pisl, the solution should follow xml specification. Which means that if there is an element defining a namespace, then all subelements without a namespace has the same. Therefore, we will always use the namepsace that appears in the <faces-config> for the comparison. I.e., the getQName() method has been restructured. changeset a4c7ae2ae10c in main details: http://hg.netbeans.org/main?cmd=changeset;node=a4c7ae2ae10c changeset 3ce9b72283dd in main details: http://hg.netbeans.org/main?cmd=changeset;node=3ce9b72283dd