X

Geertjan's Blog

  • December 1, 2005

Destroying Struts (or JSF) Support in NetBeans IDE

Geertjan Wielenga
Product Manager
Here's something fun—create a web application with Struts (or JSF) support in NetBeans IDE 5.0. Then right-click the project, choose Properties, and go to the Frameworks panel in the Project Properties dialog box. You'll see a list of 'Used Frameworks' where the framework(s) you selected previously are listed. Now exit the Project Properties dialog box. Go to your web.xml file and make one tiny change to the servlet-class declaration. For example, just change one letter. Now go back to the Frameworks panel in the Project Properties dialog box. Your framework isn't listed there anymore!

Question: Why?

Answer: Because the IDE looks for the web framework's servlet in the web.xml file's servlet-class declaration to determine whether a framework is supported or not! For example, in the Wicket support module that I'm building (and that will find itself in the NetBeans IDE 5.0 Web Framework Module Tutorial soon), this is my implementation of the isInWebModule method of the NetBeans API's WebFrameworkProvider class:

public boolean isInWebModule(WebModule webModule) {
return WicketConfigUtilities.getActionServlet(webModule.getDeploymentDescriptor()) == null ? false : true;
}

The method above is called in the Project Properties dialog box to determine whether the framework is supported or not. As you can see, it calls another method, getActionServlet in WicketConfigUtilities. This is what it does (exactly the same as what the Struts and JSF equivalents do):

public static Servlet getActionServlet(FileObject dd) {
if (dd == null) {
return null;
}
try {
WebApp webApp = DDProvider.getDefault().getDDRoot(dd);
return (Servlet) webApp
.findBeanByName("Servlet", "ServletClass", "wicket.protocol.http.WicketServlet");
} catch (java.io.IOException e) {
return null;
}
}

So, if the servlet-class declaration in web.xml isn't exactly the same as the Wicket framework's fully-qualified servlet class, null is returned, and the Project Properties dialog box tells you that your application does not support the framework.

It's a pretty safe bet that if you're working with Struts, JSF, or whatever web framework that the IDE supports, you'll have the framework's servlet correctly defined in web.xml. Firstly, it is automatically generated there when you select the checkbox that indicates that you want a particular framework to be supported. Secondly, why would you change that servlet afterwards? Once it's defined, you're unlikely to touch it. Still, if something goes wrong with your web.xml file, and you make some kind of error (any kind of error that results in the servlet-class being incorrectly declared) when recreating the web.xml file, you'll not be able to edit properties in the Frameworks panel (which you couldn't do anyway because they're read-only fields). But, what's probably worse than that, you might be confused into thinking that there's something more seriously wrong than simply a mistake in the servlet declaration (which is a mistake that you'd soon have to solve anyway, because deployment isn't going to work).

So, if you've added support for JSF or Struts to a web application, and you go to the Frameworks panel and find that the framework you added isn't listed there, the only thing that that can mean is that the servlet class is incorrectly defined in the web.xml file. It's a small thing, but good to know, I think, especially in those moments where a lot of things are going wrong all at the same time... (By the way, the converse is equally true: create a web application without any web framework support, then declare the JSF or Struts servlet class in the web.xml file, and the IDE will believe that your application supports the framework, so that the Frameworks panel will inform you that the framework in question is being used.)

Join the discussion

Comments ( 1 )
  • guest Sunday, January 29, 2006
    test
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.