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.
Hello, I'm new to the JSF technology and in the little time i've been using it i've seen some bugs that really decreases productivity. 1) Every time you deploy an application, it paginates some amount of RAM memory and never releases it (even is the web broser is closed), so passed some time, the pc is found overloaded in the RAM memory usage. So you need to shutdown the IDE very often and even restart the computer to release this memory (Maybe is the IDE, or maybe the Tomcat...). 2) The same problem is shown when you run a JSP file using right-click > Run File. It increases the RAM memory usage and never releses it. 3) The JSF visual editor has a poor stability, the JSP file is corrupted so often. 4) The visual editor becomes really slow after some time has passed. Maybe is because of the bad memory usage shown in point 1 and 2. Is really common to see the editor crashed because of a JavaHeap OutOfMemory exception. 5) Some features in the editor are very tricky, for example, centering a component on the page. Even when you've done centering a component on the page, the editor does not show this change, you only can see the component centered in the browser, not in the editor, for example: when you use a div to center a layout panel, or to center a page fragment. Another tricky feture is to make a table selectable. There should be a more direct implementations of these kind of features, For example: activate a flag or something like that to make a table selectable. 6) The root package for a jsf application should be able to be refactored. 7) In general, the editor is kind of slow, it should be faster and have a more stable rendering engine. 8) This is a sugestion: The great deal of eclipse is it's code editor, that editor is designed to increase productivity, from it's syntax coloring to it's functionality in code complention, caret wraps and all that. It would be a great deal to netbeans to implement a code editor like eclipse's one. These are the basic bugs and performance problems that my team and me have seen while using the JSF technology. This is a really usefull technology and is worth it to make it even better. Just for you to have it as a reference, the computer i've been using for the JSF application developement is a good performance pc: 1GB 800Mhz RAM Memory, Intel Core 2 Duo 2.33Ghz (1333Mhz Bus) 4MB Cache Processor, SATA Hard Drive. I expect a really visible correction of theses items for the next version release. Thanks, Manuel Lara
Hi, thanks for the feedback. This one includes a lot of independent issues which span more modules. Let me get this point by point: 1) That are the memory leaks, which should be fixed now (in 6.1), CC'ing Quy. 2) The same as 1) 3) The corruption belongs to insync or components; a case is needed (please provide log file or exception stack as a minimum), CC'ing Sandip and Winston. 4) That should be a consequence of the memory leaks (same as 1) and 2). 5) I just tried the centering (in 6.1) and it works there. It might have been fixed after 6.0, or if you have another case, please, provide it, CC'ing myself. Please, clarify about the selectable table. It sounds to me it belongs to the components (in case you ask for certain property to be available) - Winston; 6) This I am not sure where it belongs to, JSP editor, refactoring, insync? 7) This might be one part the memory leaks, and other is unfortunately inherent because of the architecture used. We are trying to solve it in some future release. 8) That belongs to JSP editor, web/jspeditor; I evaluated the designer problems (part of 5) and 7). Passing now to Quy to evaluate the memory leaks stuff. Then please, pass to the other guys.
Many of the common IDE memory leaks have been fixed in NB 6.1. This includes a number of memory leaks during deployment. See Issue 123530 for details.
There was no response long, time, I assume, the fixes in later releases satisfied the problem. Closing.
Hi, sorry for the delay. The new releases of netbeans has solved many of these problems, but i hadn't the chance to make a full test, later i'll post the results. Well, about the item number 5, i'll explain how it would be really nice to have a selectable table. At this moment, natively, the jsf table is kind of static, however it can be made selectable, and the process is as follows: You create a table, then you insert a radio button or check box, depending of what you need. After this, you have to implement an interface to receive events from the table. And finally, you have to make some manual bindings, and after that, the table is selectable. As you see, this process consumes some time while the developer makes all these steps, every time a selectable table is needed, what is very often, and because of that, this represents a decrease in productivity. What i propose about this is a way to make it easier to make a table selectable. Remember the behavior of a JTable in JSE. This table model allows row and column selection natively, and is also possible to disable the selectable feature. Just with a minor variable configuration, through a 'set' method or a simple method override, you can switch between a selectable table behavior to a non selectable table behavior. This is what i suggest a JSF table to support, a variable configuration to enable a selectable behavior (either for multiple as for single selection), and avoid all the current steps you have to make to enable this. Basically, enable a table.setSelectable(multiple or single) and a table.getSelectedRow() for single selection and table.getSelectedRows() for multiple selection, methods to make this usage much easier. Thanks.
OK, thanks for the response. So at this moment this boiled down to the need of selectable table jsf component (see previous comment). Passing to components to evaluate.
Ok, thanks.
What Visual JSF framework comes with is a set of components from Project Woodstock and doesn't have any component library of its own . So this is not a defect but a feature request for Project Woodstock. You can also file an enhancement against JSF RI to provide such a feature in standard JSF table. The other approach is for you to write your own custom component extending the APIs exposed by JSF if existing component libraries out there don't satisfy your needs. Sorry for not being to help you this regard. Thanks