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.
Reported on nbusers alias: We have a small working JSF 1.2 application created using JBuilder 2006 & Eclipse 3.2; we use it for testing out new web technologies. I created a new NB6 project: "Web Project with Existing Sources." I named the project "IMApplication42NoAnt". I configured for this small web project, added the right JSF 1.2 libraries and got everything compiling. To keep things clean, I put the NB project files in a separate directory. I right clicked on the web folder and hit "Add New Visual Web Page.." The dialog came up. I fixed the path for the jsf file, but it wouldn't let me change the default package path, which was set to the name of the NB project: IMApplication42NoAnt. Obviously, this name has no resemblance to any of the folders in the real project. I clicked on OK and waited and waited but nothing happened. After about 10 minutes, I killed the process. I opened up Windows Explorer and noticed that it created hundreds of empty subdirectories. In the SRC folder under my WEB folder, it made a new subdirectory called IMApplication42NoAnt. Under it was another SRC folder. In that folder was a subdirectory called IMApplication42NoAnt, and under that was another SRC folder, and so forth. There were other junk folders here as well, such as taglib. Hundreds of them. There are so many nested folders now that I'm unable to delete this folder using Windows Explorer, and CHKDSK doesn't detect a problem. Problem with Visual Web and existing ANT scripts: Using the same example, enable the creation of Visual Web pages if I make a new web project based on an existing Ant Script. If necessary, warn or ask the user if it's ok that "Your existing ANT script and WEB-INF files will be edited to support Visual Editing and Woodstock JSF libraries." Or give us some way or guidance to adjust, on our own, our ANT scripts and WEB-INF files in order to support Visual JSF pages. Our project makes extensive use of custom ANT scripts and it would really give NetBeans a bad name here if we weren't able to incorporate them in our day-to-day NetBeans development of JSF pages.
As discussed with Mark, this is not supported.
Here is what I replied to nbusers: When you created your project, did you define your 'Source Package Folders'? If not, you should. You can add it later from the project properties dialog. VisualWeb page needs to add associated java files into your project, if you don't define 'Source Package Folders' before adding, then it won't work. Besides, if your web pages is not under $proj_dir/web as you said, then it may not work neither. Adding VisualWeb pages into projects created by IDEs other than NetBeans is not directly supported. But if you setup your project under NetBeans web project 'standard/default' structure, then it should work.
Hi all, I can't agree with ENHANCEMENT since user reported that he clicked on OK and waited and waited but nothing happened. After about 10 minutes, I killed the process. From point of view it's DEFECT. Do you think that users who want to switch from Eclipse think that this is enhancement? I guess that they will uninstall NetBeans and continue to use Eclipse and it's our fail.
*** Issue 109059 has been marked as a duplicate of this issue. ***
I made the original post in NBusers about this problem. I have a few things to add: 1) Primary Defect: The project was not tied to an IDE. We made our own ANT script for all builds. The only advanced things used was the Tomahwak component library and JSF 1.2. There is more info on the this primary defect below. 2) Secondary Defect: In my opinion, not being able to add a visual web page to a NetBeans project "Using an exiting ANT script" is a serious problem. At least it would be in my organization. I think this is a separate problem than the main defect represented by this ticket. I would recommend making a separate ticket just for that if you think it would be better to split up the two fixes. If we had the ability to add a visual web page to a "Web Project using an existing ANT script" but we had to make various changes to our ANT script in order to do a successful build, then that would be perfectly fine with a little guidance. Additional info regarding the primary defect: NB 6, Milestone 10 I created a new web project from existing sources. I had a small JSF web app I used for the project. This small JSF web app uses JSF 1.2 and Tomahawk from the Apache group. It's very basic and not IDE dependant; in fact, we compile this test-app with an ANT script and edit the code in it using both Eclipse 3.2 as well as JBuilder 2006 (not the newer Eclipse based JBuilder). The web app uses the standard EE setup for a JSF application with a WEB-INF folder and so forth. I called my project "ImApplication42NoAnt." This project descriptor does not match any package folder in my application. I got my new NB6 project compiling and creating the WAR file OK. I clicked on "Add new Visual Web page." The program hung for 10 minutes and I had to kill it. In my Web/SRC folder, it created 900+ additional folders. We had to write a special Java utility to recursively drill down and delete them; the path was too big for Windows Explorer to handle. I'm guessing it was trying to put a backing bean here but got stuck in some kind of infinite loop. For example, my app source folder initially looked like this: App-root/web/src ---> source doe under here. After experiencing the bug, my app source folder looked like this. App-root/web/src ---> ImApplication42NoAnt/src/ImApplication42NoAnt/src/ImApplication42NoAnt/src and so forth, 900+ levels deep. It also appears that the tool should have asked what package I wanted to put my backing bean in. It assumed the wrong package path. Because of this bug, my hard drive was temporarily corrupted, and I was unable to do builds against that project.
Kidvid, please attach a small example project that can reproduce this issue. For NetBeans 6.0 plan, we only support and test projects created under NetBeans IDE. If you can supply a small project that can reproduce this issue, then we may try to find some fix.
Attached two zip files. One for the Netbeans 6M10 project info, and one for the source code. This is how I have it set up on my machine. D Drive ------- nb-projects----> contents of nb-Projects.zip W Drive ------- projects ------> contents of imApplication42.zip
Kidvid, I don't see any files attached! Could you please try again? Thanks! BTW, you don't need to attach exactly your project if it's big. If you can make a small one that can reproduce the same issue, then that will make our progress faster.
Created attachment 44893 [details] nb projects
Created attachment 44894 [details] Sample Web app (may not actually work anymore..)
I finally found that it is caused by insync goes into an infinite loop that creates the looping directories and never ends! ... at org.netbeans.modules.visualweb.insync.models.FacesModelSet.ensureJspJavaFolderStructure(FacesModelSet.java:219) at org.netbeans.modules.visualweb.insync.models.FacesModelSet.ensureJspJavaFolderStructure(FacesModelSet.java:219) at org.netbeans.modules.visualweb.insync.models.FacesModelSet.<clinit>(FacesModelSet.java:189) at org.netbeans.modules.visualweb.designer.jsf.JsfForm.getJsfForm(JsfForm.java:297) at org.netbeans.modules.visualweb.designer.jsf.DesignerJsfServiceImpl.createDesignerMultiViewElement(DesignerJsfServiceImpl.java:48) at org.netbeans.modules.visualweb.project.jsfloader.JsfJavaEditorSupport$DesignerDesc.createElement(JsfJavaEditorSupport.java:514)
I also got a very very deep directory tree that Windows Explorer can't delete :-( The reason is "name too long"! Therefore attached is a small Java program I wrote to remove the tree. - javac rmlong.java - java rmlong imapp42noant
Created attachment 44911 [details] small program to remove 'filename too long' deep directory
Because the 2 attached zip files are originally created under 2 drivers, it's not obvious how to use them to reproduce this symptom. Here is what I do: 1. Create e.g. the following directory tree: TEST/projects 2. then unzip nb-Projects.zip and imApplication42.zip into TEST/projects 3. Remove TEST/projects/IMApp42NoAnt/nbproject/private 4. Then use NetBeans to open TEST/projects/IMApp42NoAnt Go into the infinite loop that creates the endless directories tree.
Created attachment 44985 [details] Full thread dump when insync is creating these directories
Today the thread dump is different (attached), it's now: at org.netbeans.modules.visualweb.insync.models.FacesModelSet$FolderStructureFileChangeListener.fileFolderCreated(FacesModelSet.java:166)
Created attachment 44986 [details] Full thread dump under other actions
I just attached the Full Thread Dump that is the same as the one I got yesterday.
Thanks for the thread dump. However it does not have: at org.netbeans.modules.visualweb.insync.models.FacesModelSet.ensureJspJavaFolderStructure (FacesModelSet.java:219) at org.netbeans.modules.visualweb.insync.models.FacesModelSet.ensureJspJavaFolderStructure (FacesModelSet.java:219) as expected. I gues earlier was a copy/paste problem.
I am able to reproduce it now. The problem seems to be because the so called page bean root JsfProjectUtils.getPageBeanRoot(project)) is nested inside the document root (returned by JsfProjectUtils.getDocumentRoot(project)): document root: TEST/projects/imApplication42/web page bean root: TEST/projects/imApplication42/web/src/imapp42noant Now the question is this: 1. Should we support this configuration? 2. Is it a good practice to have the source folder under the web folder. Can the user move the src folder outside the web folder hierarchy?
We can't just ask this individual user to change the project structure. It will happen when others have the similar issue. I do see many other non-NetBeans projects (some examples from some books that do not use any IDE as well) have their source folder under the web folder. Actually NetBeans project view also support this kind of structure. I think we had better to support this configuration.
Partial Bug Fix. Checking in FacesModelSet.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/models/FacesModelSet.java,v <-- FacesModelSet.java new revision: 1.14; previous revision: 1.13 done Added a check to not replicate folders under the src root under the page bean root. This prevents infinite recusrursive creation of folders under page bean root. Additional note: After fixing this some new exceptions are seen from dataconnectivity module. java.lang.NullPointerException: Passed null to FileOwnerQuery.getOwner(FileObject) at org.netbeans.api.project.FileOwnerQuery.getOwner(FileOwnerQuery.java:72) at org.netbeans.modules.visualweb.insync.ModelSet.getModelSet(ModelSet.java:387) at org.netbeans.modules.visualweb.insync.models.FacesModelSet.getFacesModelIfAvailable(FacesModelSet.java:359) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceTracker.isProjectModeled (ProjectDataSourceTracker.java:213) at org.netbeans.modules.visualweb.dataconnectivity.explorer.ProjectDataSourceNode.<init> (ProjectDataSourceNode.java:68) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceTracker$DSTracker.getNode (ProjectDataSourceTracker.java:408) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceTracker.getNode (ProjectDataSourceTracker.java:163) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceServiceImpl.getDataSourceReferenceN ode(ProjectDataSourceServiceImpl.java:58) at org.netbeans.modules.visualweb.project.jsf.ui.JSFNodeFactory$JSFNodeList.node(JSFNodeFactory.java:116) at org.netbeans.modules.visualweb.project.jsf.ui.JSFNodeFactory$JSFNodeList.node(JSFNodeFactory.java:60) at org.netbeans.spi.project.ui.support.NodeFactorySupport$DelegateChildren.createNodes (NodeFactorySupport.java:117) at org.netbeans.spi.project.ui.support.NodeFactorySupport$DelegateChildren.createNodes (NodeFactorySupport.java:96) at org.openide.nodes.Children$Keys$KE.nodes(Children.java:2225) at org.openide.nodes.ChildrenArray.nodesFor(ChildrenArray.java:145) at org.openide.nodes.Children$Info.nodes(Children.java:1271) [catch] at org.openide.nodes.Children.justComputeNodes(Children.java:750) at org.openide.nodes.ChildrenArray.nodes(ChildrenArray.java:74) at org.openide.nodes.Children.getNodes(Children.java:407) at org.openide.nodes.FilterNode$ChildrenAdapter.run(FilterNode.java:1479) at org.openide.nodes.FilterNode$Children.updateKeys(FilterNode.java:1433) at org.openide.nodes.FilterNode$Children.addNotifyImpl(FilterNode.java:1326) at org.openide.nodes.FilterNode$Children.addNotify(FilterNode.java:1318) at org.openide.nodes.Children.callAddNotify(Children.java:516) at org.openide.nodes.Children.getArray(Children.java:558) at org.openide.nodes.Children.getNodes(Children.java:400) at org.openide.explorer.view.VisualizerNode.getChildren(VisualizerNode.java:222) at org.openide.explorer.view.VisualizerNode.getChildCount(VisualizerNode.java:268) at javax.swing.tree.DefaultTreeModel.getChildCount(DefaultTreeModel.java:168) at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1461) at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1270) at javax.swing.tree.VariableHeightLayoutCache.ensurePathIsExpanded(VariableHeightLayoutCache.java:966) at javax.swing.tree.VariableHeightLayoutCache.setExpandedState(VariableHeightLayoutCache.java:164) at javax.swing.plaf.basic.BasicTreeUI.updateExpandedDescendants(BasicTreeUI.java:1556) at javax.swing.plaf.basic.BasicTreeUI$Handler.treeExpanded(BasicTreeUI.java:3649) at javax.swing.JTree.fireTreeExpanded(JTree.java:2235) at javax.swing.JTree.setExpandedState(JTree.java:3006) at javax.swing.JTree.expandPath(JTree.java:1742) at javax.swing.plaf.basic.BasicTreeUI.toggleExpandState(BasicTreeUI.java:2189) at javax.swing.plaf.basic.BasicTreeUI.handleExpandControlClick(BasicTreeUI.java:2176) at javax.swing.plaf.basic.BasicTreeUI.checkForClickInExpandControl(BasicTreeUI.java:2130) at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelectionImpl(BasicTreeUI.java:3499) at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(BasicTreeUI.java:3484) at javax.swing.plaf.basic.BasicTreeUI$Handler.mouseReleased(BasicTreeUI.java:3527) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:232) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5501) at javax.swing.JComponent.processMouseEvent(JComponent.java:3135) at java.awt.Component.processEvent(Component.java:5266) at java.awt.Container.processEvent(Container.java:1966) at java.awt.Component.dispatchEventImpl(Component.java:3968) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3803) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) at java.awt.Container.dispatchEventImpl(Container.java:2010) at java.awt.Window.dispatchEventImpl(Window.java:1778) at java.awt.Component.dispatchEvent(Component.java:3803) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) WARNING [org.openide.nodes.NodeOp] java.lang.NullPointerException: Passed null to FileOwnerQuery.getOwner(FileObject) at org.netbeans.api.project.FileOwnerQuery.getOwner(FileOwnerQuery.java:72) at org.netbeans.modules.visualweb.insync.ModelSet.getModelSet(ModelSet.java:387) at org.netbeans.modules.visualweb.insync.models.FacesModelSet.getFacesModelIfAvailable(FacesModelSet.java:359) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceTracker.isProjectModeled (ProjectDataSourceTracker.java:213) at org.netbeans.modules.visualweb.dataconnectivity.explorer.ProjectDataSourceNode.<init> (ProjectDataSourceNode.java:68) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceTracker$DSTracker.getNode (ProjectDataSourceTracker.java:408) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceTracker.getNode (ProjectDataSourceTracker.java:163) at org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceServiceImpl.getDataSourceReferenceN ode(ProjectDataSourceServiceImpl.java:58) at org.netbeans.modules.visualweb.project.jsf.ui.JSFNodeFactory$JSFNodeList.node(JSFNodeFactory.java:116) at org.netbeans.modules.visualweb.project.jsf.ui.JSFNodeFactory$JSFNodeList.node(JSFNodeFactory.java:60) at org.netbeans.spi.project.ui.support.NodeFactorySupport$DelegateChildren.createNodes (NodeFactorySupport.java:117) at org.netbeans.spi.project.ui.support.NodeFactorySupport$DelegateChildren.createNodes (NodeFactorySupport.java:96) at org.openide.nodes.Children$Keys$KE.nodes(Children.java:2225) at org.openide.nodes.ChildrenArray.nodesFor(ChildrenArray.java:145) at org.openide.nodes.Children$Info.nodes(Children.java:1271) [catch] at org.openide.nodes.Children.justComputeNodes(Children.java:750) at org.openide.nodes.ChildrenArray.nodes(ChildrenArray.java:74) at org.openide.nodes.Children.getNodes(Children.java:407) at org.openide.nodes.Children.findChild(Children.java:340) at org.openide.nodes.Children.getNodes(Children.java:473) at org.openide.nodes.FilterNode$Children.getNodes(FilterNode.java:1448) at org.openide.explorer.view.TreeView$2.run(TreeView.java:808) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:539) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:964) Basically the: org.netbeans.modules.visualweb.dataconnectivity.project.datasource.ProjectDataSourceTracker need to handle the condition better in isProjectModeled() method. Note for John: This is a very unusual project set up. I am not sure if we fully support this. I can help you set set up for the test case.
may be an easy fix for dataconnectivity but may not be enough to solve the main issue
To fix issue 109898, I removed some unnecessary call to check if model is available. From the stack trace, the exception from dataconnectivity should no longer occur potingwu please confirm that this no longer occurs using the latest bits
As I talked to Sandip yesterday, insync has fixed one exception. It needs to fix the other one. Fixed: org.netbeans.modules.visualweb.insync.models.FacesModelSet.ensureJspJavaFolderStructure Not yet fixed: org.netbeans.modules.visualweb.insync.models.FacesModelSet$FolderStructureFileChangeListener.fileFolderCreated
Fixed.
I'm getting this problem again with NetBeans 6.0, final release. I had to run a special java program to clean up thousands of unwanted directories on my hard drive. I created a web project using existing ANT script. My code structure is as following: /web /web/jsp /web/jsf/test <-- This is where I told the IDE to create my JSP file. /web/src /web/src/mil/tis/test <-- (I should be allowed to select this for my Java files, but it doesn't.) /web/WEB-INF /web/html Attached are two screenshots: one showing the properties of my NB project. The next one shows the "New Visual JSF Webpage" dialog options. The problem is that the new "Visual JSF" dialog box is not asking me where I want the backing java files to go. However, it is asking me where I want the new JSP files to go. As seen in the screenshot, I selected the /web/jsp/test directory for my new jsp file. However, for the backing java files, it defaults the package name to "new folder," and doesn't allow me to change that - I don't understand why this is the case. It should give me an option to select exactly where I want to put my backing classes as well. When I click on OK, it correctly creates a new JSP file in the /web/jsp/text directory. However, it creates a new folder under my src directory called "newfolder." Under "newfolder," it creates a thousands upon thousands of of nested directories, and it's impossible to delete them without a recursive java utility. I see two problems here: 1) It shouldn't be creating thousands of nested directories. 2) If the IDE is going to ask me exactly where I want my new Visual Web JSP, then it should also ask me exactly where I want the corresponding backing classes, instead of guessing and putting them in a brand new package that I don't have incorporated in my ANT script. As mentioned above, this is is a web project using an existing ANT script.
Created attachment 53862 [details] Web project using existing ANT
Created attachment 53863 [details] New Visual JSF options for a web project using an existing ANT script.
Supporting freeform project from Visual Web will be in post NetBeans 6.0 plan.
PotingWu, I STRONGLY disagree. This is a feature offered right now, in the NetBeans 6.0 final public release. Those screenshots are not from a beta or release candidate build, but from the latest public build. Consequently, it's incorrect to say it will be a feature offered in a future release of NB6. Any user can select that option right now and it's horribly broken. To reiterate, this feature is currently offered and available and causes a lot of problems. If you let the user click on something in the current release, and it causes a lot problems, then it's a defect, not a missing feature. A missing feature would be for an option the user does not yet have access to, such as turning off a menu item.
Setting the status back to "Defect" based on the fact that this feature is implemented in the current NB 6 final product. It is not invisible to the user, or turned off, and it has serious consequences to the user's file system if it is activated.
Quick question: /web /web/jsp /web/jsf/test <-- This is where I told the IDE to create my JSP file. Did you mean: /web/jsp/test above? Also can I use the original project to reproduce the problem? Po-ting do you have the project that I can use to reproduce the issue?
See my previous comment for how to reproduce it: > ------- Additional comments from potingwu Wed Jul 11 20:34:24 +0000 2007 ------- > > Because the 2 attached zip files are originally created under 2 drivers, it's not obvious how to use them to reproduce > this symptom. Here is what I do: > ...
Can you please attach the latest project which has the specified directory stucture?
Following Po-ting's procedure I am able to open the TEST/projects/IMApp42NoAnt project in NB6.0. I get Server and Library reference problems. I am able to fix the Server Reference problem using one of the installed servers. The library reference errors still remain. With that if I try to create new Visual JSF Page I get the following exception: java.lang.NullPointerException at org.netbeans.modules.visualweb.project.jsf.ui.PageIterator.initialize(PageIterator.java:166) at org.openide.loaders.TemplateWizardIterImpl.setIterator(TemplateWizardIterImpl.java:100) at org.openide.loaders.TemplateWizardIteratorWrapper.setIterator(TemplateWizardIteratorWrapper.java:76) at org.openide.loaders.TemplateWizard.setTemplateImpl(TemplateWizard.java:200) at org.openide.loaders.TemplateWizard.setTemplate(TemplateWizard.java:218) at org.openide.loaders.TemplateWizard.instantiateImpl(TemplateWizard.java:465) at org.openide.loaders.TemplateWizard.instantiate(TemplateWizard.java:381) at org.netbeans.modules.project.ui.actions.NewFile.doPerform(NewFile.java:147) at org.netbeans.modules.project.ui.actions.NewFile.access$200(NewFile.java:80) at org.netbeans.modules.project.ui.actions.NewFile$PopupListener.actionPerformed(NewFile.java:340) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.AbstractButton.doClick(AbstractButton.java:302) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1051) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1092) at java.awt.Component.processMouseEvent(Component.java:5517) at javax.swing.JComponent.processMouseEvent(JComponent.java:3135) at java.awt.Component.processEvent(Component.java:5282) at java.awt.Container.processEvent(Container.java:1966) at java.awt.Component.dispatchEventImpl(Component.java:3984) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3819) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) at java.awt.Container.dispatchEventImpl(Container.java:2010) at java.awt.Window.dispatchEventImpl(Window.java:1791) at java.awt.Component.dispatchEvent(Component.java:3819) [catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) Thus I am not able to get to the page creation scenario described by the user in the latest post. Po-ting please take care of this first then if then if the deep directory structure problem is still reproducible assign it back to me. Questions for kidvid: 1. What exact version of NB6.0 were you trying this with? 2. Can the projects you originally attached to this issue can still be used for testing? If not can you attach your new test projects.
I just retry the following steps and the attached projects open good (though server and references need to be resolved and they are not related to this issue). Then I can even add a Visual Web page with all the default without any issue. I agree there is no complete options for users to select the Java bean file location. But it's not supported feature. Since I don't see the long recursive directories and the visual web page is added without any issue by default. I don't think this is a P2 bug. And it is actually a new feature request, not a bug. (Visual Web in NetBeans 6.0 did not have plan for freeform support.)
The steps I try are: 1. Create e.g. the following directory tree: TEST/projects 2. then unzip nb-Projects.zip and imApplication42.zip into TEST/projects 3. Remove TEST/projects/IMApp42NoAnt/nbproject/private 4. Then use NetBeans to open TEST/projects/IMApp42NoAnt 5. Right click on Web Page and add a new Visual Web page. I see a new working Visual Web page.
I'll try to upload a new example in a few days. I can't upload the project that caused the infinite directory problem because it's our primary source code tree. The IMApp that caused the problem a long time ago, which is a small test app that I haven't touched since, is not nearly as complex. On a side note, why offer a "feature" if it isn't supported and is basically, useless but still available to the user? What point is there to that? For people at home who program in their mom's basement? It doesn't make sense. I don't know any enterprise developers that A) don't have their own ANT scripts already created and B) use a default package. Basically, the way NetBeans is working right now with existing ANT scripts, is very disappointing. I'd like to see NetBeans have more of a focus on real-world heavy-duty enterprise development shops and not just people who download it at home and tinker with it or use it at work as a glorified editor. In other words, if NetBeans is developed with the idea that people should change the way the normally do things, in order to take advantage of NetBeans specific features, then it's not going to ever beat Eclipse, and I would rather see NetBeans succeed. And by that, I mean people having to use the NetBeans ANT script instead of their own without some silly workaround like creating a project directory outside of where their source code is and having two different ANT scripts running.