Is there a way to know which bean properties are referenced in xhtml files of a JSF project?

I inherited a JSF project developed a year ago by someone which does not work in my company anymore, and the code is really hard to understand. A lot of it seems to have been generated automatically by the IDE, especially getters and setters of classes. In fact, every private field has associated getter and setter, even if they are not referenced anywhere in the project.

I wanted to get rid of all this useless code before trying to understand the project, but given that it's a JSF project, beans' properties may be referenced in xhtml files and thus won't show up when using the "show references" com开发者_如何学Gomand.

Is there a way to know which methods are really useless in order to safely remove them?

I use eclipse but every tool allowing to do this would be a great relief!

I don't think there is a way, apart from a search for .fieldname. But more importantly - generated setters and getters, if they are on data-only objects, are not a serious obstacle to understanding a project. So you can skip that cleanup part.

I think it's better to learn and play around with JSF first before diving in an existing JSF project. Getters/setters are solely there to get data for display in HTML output and set request parameters from HTML form input. E.g. <h:inputText value="#{bean.foo}" /> in the view requires a bean.getFoo() to display the value and a bean.setFoo(String value) to set the submitted value. So just leave them there and concentrate on the action methods.

As to the tools, Eclipse doesn't offer tools/facilities for this since they may be invoked by reflection and not by direct references. It's nearly impossible to detect that. At least, it's good to know that the setters are never called for output-only components, like <h:outputText value="#{bean.foo}" /> or for nested beans like <h:inputText value="#{bean.nested.foo}" />. However the setter is mandatory whenever the nested bean is to be injected as managed property.

I myself just hide the getter/setters far away to the whole bottom of the class. The action methods (at least, non getter/setter methods) are just right after the constructor(s). You can even configure the IDE to place them over there during autogeneration.