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.
Created attachment 93733 [details] Two stack traces from when project creation is hanging Platform: Solaris x86 update 8 w/ Java SE 1.6 update 17 When creating an Enterprise Application Client (either as its own project or when creating an EAR project) the project creation may hang. In extreme cases the progress bar will hang at 56% for up to 15 minutes. The behavior was verified on multiple system at the Sun training center in Burlington, MA. Using some DTrace it was determined that there was some networking involved: libc.so.1`__open_syscall+0x15 libc.so.1`open+0xd1 libnsl.so.1`__can_use_af+0x25 libnsl.so.1`getnetconfig+0xad libnsl.so.1`__rpc_getconfip+0xb0 libnsl.so.1`getipnodebyname+0x24 libsocket.so.1`get_addr+0x16e libsocket.so.1`_getaddrinfo+0x49d libsocket.so.1`getaddrinfo+0x19 libnet.so`Java_java_net_Inet6AddressImpl_getLocalHostName+0x80 0xfc009bf5 0xfc003343 0xfc002e67 0xfc002e67 0xfc002e67 0xfc002e67 0xfc002e67 0xfc002e67 0xfc002fcd 0xfc002fcd Since one of the stack traces indicated some IPv6 code ("Inet6AddressImpl") I tried running NetBeans with -J-Djava.net.preferIPv4Stack=true but that didn't help. Using some more DTrace it was determined that name lookups were being attempted for java.sun.com and www.w3.org during creation of the project. Both domains appear in <project>/src/conf/application-client.xml. Using jinfo to get a Java stack dump it turned out that project creation hangs for long periods of time durning XML schema validation. See attachment for the stack dumps. A at the training center the firewall configuration was causing traffic to www.w3.org to be dropped. However the same problem was duplicated offsite, just not to the same degree. Does schema validation need to be enabled during project creation? Out of all the upcoming Java EE 6 courses from Sun this seems to only effect SL370-EE6. SL370-EE6 is the only course using Enterprise Application Client projects. The workaround is to add java.sun.com and www.w3.org as aliases to 127.0.0.1 in the /etc/hosts file.
I have no idea what's wrong. From thread dump I can see that appclient project was created and within that project empty application-client.xml from a template was created and being opened so that application name can be stored there. Opening application-client.xml triggers XML parser which in turn needs to load file's schema. There can be tree different schemas used from application-client.xml (versions: 6, 5, 1.4) and all these schemas are available in IDE: see Tools -> DTD and XML Schemas -> Enterprise Deployment Descriptors Catalogue where you can find XML schemas for all three versions of application-client.xml. Disconnecting myself from network and resetting all caches I can found I'm able to create new project without problems. Could QA re-test this please. chase, could you confirm please #1) which exact versions of IDE and Java you run on and also #2) what version of application-client.xml was created in your case and #3) that your DTD and XML Schemas dialog lists the schema from application-client.xml? Thanks.
(In reply to comment #1) > Disconnecting myself from network and resetting all caches I can found I'm able > to create new project without problems. Maybe to fully manifest it will require a router/firewall to DROP packets to www.w3.org and/or java.sun.com. But then why is this the only project type that seems to be impacted? > Could QA re-test this please. > > chase, could you confirm please #1) which exact versions of IDE and Java you > run on and also #2) what version of application-client.xml was created in your > case and #3) that your DTD and XML Schemas dialog lists the schema from > application-client.xml? Thanks. JDK 1.6 update 17 NetBean 6.8 (Java bundle which includes GlassFish v3) for Solaris x86 application-client.xml: <?xml version="1.0" encoding="UTF-8"?> <application-client version="6" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application-client_6.xsd"> <display-name>EnterpriseApplication2-app-client</display-name> </application-client> I see "http://java.sun.com/xml/ns/javaee/application-client_6.xsd" listed underneath "Enterprise Deployment Descriptors Catalog". I can say that the problem only manifests when DNS is enabled in /etc/nsswitch.conf and connectivity with external sites such as www.w3.org is either not possible or unreliable. The problem manifested on every machine in the classroom however a machine setup using the exact same copies of the software at a different location (but with no inet access) showed no signs of problems. I think DNS resolution must give back an external ip You might want to ping George.Ridley@sun.com and see if knows the exact firewall rule that they identified at that training location. I still think there would be a NetBeans bug since only this project type seemed to be impacted by the network issue.
Figured out a simple way to manifest the issue. Get a solaris x86 system with working internet access. Edit the /etc/hosts file to map www.w3.org to a ip that drops traffic to port 80. 1.1.1.1 worked for me. Creating other projects seems to be slightly slow after that but application client projects take much longer than anything else.
Changing /etc/hosts allowed me to reproduce it and it took me ages! to found the problem: there is special entity resolver which is used instead of global one which I was mistakenly following. Fix is trivial - patched java_ee6 schema from j2ee.dd module must be used and not the one from j2ee.ddloaders. Thanks for noticing this problem and raising it. Fixed in: 982347821c2d
The whiteboard changed to 68patch-candidate according to the NetBeans Patches Process (http://wiki.netbeans.org/NetBeansPatchesProcess)