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.
I'm using the Visual Web Pack to create JSF application. I add new managed beans to the faces-config.xml, but I cannot see them neither in the value binding dialog, nor in the list of accessible managed beans (some dialog on the left side of the screen). It is the same error regardless how I create the beans (e.g. with the right click wizard on the xml file or by hand), however if I add a very new class as a managed bean, I can see it in the bindings mentioned earlier.
The outline window only shos
Can you please attach the Bean class that you added to faces-config.xml file and the faces-config.xml file itself. The Navigator(Outline) window only shows that are sub classes of AbstractPageBean AbstractRequestBean AbstractSessionBean AbstractApplicationBean as those are so called life cycle beans. wjprakash can comment on why other beans do not appear in binding dialogs. The reason may be the same as above.
Binding dialog gets the models (DesignContexts) from insync. So if it doesn't appear in the outline, it won't appear in the binding dialog too.
The solution for the user is to subclass the beans from Abstract*Classes mention in the other comment. With that one gets the benefit of the lifecycle methods such as init(), preprocess(), prerender() and destroy() etc. Otherwise this is considered an enhancement in the sense that VisualWeb should handle non-visualweb prescribed managed beans also.
Why would you enforce the users to subclass from those abstract classes? It just doesn't make sense as in general, JSF doesn't enforces such requirement. For example I can generate a web service client that contains generated classes from the XSDs. I'd like to create a managed bean from the request class to bind directly to the page, but I cannot change these to inherit from Abstract..., but on the other hand I do not require it anyway. I think this is very reasonable requirement, isn't it?
You are right and no argument there.But unfortunately, VWP design time system was written that way and it is lot of work to change that now. That is why we are considering it as enhancement for future release.