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.
From the following log I note: 1) TLD process is searching *.jar files but under /gfdeploy there are not jars at all as it contains unzipped folders only. 2) this double "lib" folder is not real and it is erroneously generated by TLD: file:/C:/NetBeansProjects/CSIPortal-J2EE6/dist/gfdeploy/CSIPortal-J2EE6/lib/lib/CSIPortalBroker.jar Hope this helps. Roberto LOG: ---------------- AVVERTENZA: PWC6351: In TLD scanning, the supplied resource file:/C:/NetBeansProjects/CSIPortal-J2EE6/dist/gfdeploy/CSIPortal-J2EE6/lib/lib/CSIPortalBroker.jar does not exist java.io.FileNotFoundException: C:\NetBeansProjects\CSIPortal-J2EE6\dist\gfdeploy\CSIPortal-J2EE6\lib\lib\CSIPortalBroker.jar (The system cannot find the path specified) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:127) at java.util.jar.JarFile.<init>(JarFile.java:135) at java.util.jar.JarFile.<init>(JarFile.java:72) at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:72) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:80) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104) at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71) at org.apache.jasper.runtime.TldScanner.scanJar(TldScanner.java:438) at org.apache.jasper.runtime.TldScanner.scanJars(TldScanner.java:689) at org.apache.jasper.runtime.TldScanner.scanTlds(TldScanner.java:350) at org.apache.jasper.runtime.TldScanner.onStartup(TldScanner.java:239) at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:5405) at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:558) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5302) at com.sun.enterprise.web.WebModule.start(WebModule.java:500) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:755) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1980) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1630) at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)
I must say I don't understand. What is the structure of your app? And is the problem in the IDE, or in GlassFish? And what exactly is not working well?
this is an INFO level message in the server log, right? The connection to the IDE is that you were using it when you ran into this, right? Is there a negative affect on your app from this exception? can you provide more details about the app? Can you show me what the layout of the ear file is?
>this is an INFO level message in the server log, right? yes it is >The connection to the IDE is that you were using it when you ran into this, >right? yes, it is like the TLD process in unaware of the /gfdeploy folder structure and behaviour. >Is there a negative affect on your app from this exception? I was not able to start the application. >can you provide more details about the app? it is a J2EE EAR with some EJB 2.1 and 3.0 I was running on GF 2.1.1 it is a big application with 13 databases connected but it is quite simple as it uses just stateless Session beans and some CMP. >Can you show me what the layout of the ear file is? About this I have an evolution, I just found GF 3.1 ha renamed all sun-*.xml deployment descriptors and my application is fully based on descriptors and not annotations. Now I replaced all sun-*.xml files with new glassfish-*.xml (and their new versions) and pasted the original content inside. This problem desappeared actually, so it could be the old sun-*.xml descriptors are not supported anymore. It should be clearly stated for people downloading such new version or even upgrading from 3.0.1 (as I did initially). Noone can expect this change. I would suggest you to verify my conclusions are correct anyway. Thanks. Roberto
(In reply to comment #3) > [snip] > > >can you provide more details about the app? > > it is a J2EE EAR with some EJB 2.1 and 3.0 I was running on GF 2.1.1 > it is a big application with 13 databases connected but it is quite simple as > it uses just stateless Session beans and some CMP. > > >Can you show me what the layout of the ear file is? I was interested in finding out the names and location of the various modules and jars in the ear file produced by NB. > > About this I have an evolution, I just found GF 3.1 ha renamed all sun-*.xml > deployment descriptors and my application is fully based on descriptors and not > annotations. Now I replaced all sun-*.xml files with new glassfish-*.xml (and > their new versions) and pasted the original content inside. > > This problem desappeared actually, so it could be the old sun-*.xml descriptors > are not supported anymore. Hmm. That is not expected. The GF team has said that all sun-*.xml descriptors are supported, so this may be a GF issue. quick Q: were you able to deploy the original ear file onto GF 3.1 (the one with the sun-*.xml descriptors) using 'asadmin deploy'? > > It should be clearly stated for people downloading such new version or even > upgrading from 3.0.1 (as I did initially). > > Noone can expect this change. > > I would suggest you to verify my conclusions are correct anyway. Do you have a small sample app that replicates this behavior that I could use to try to verify your conclusion? > Thanks. > > Roberto
decreasing the priority to P2 , we do not consider this as a stopper for NB 7.0
please attach the output that appears in the 'ant output window', the server log and the ide log when you trigger a deploy that encounters this problem.
this looks like a parallel bug report in the glassfish JIRA: http://java.net/jira/browse/GLASSFISH-10334 There also seems to be a parallel issue in the NB tracker: http://netbeans.org/bugzilla/show_bug.cgi?id=180707 See http://old.nabble.com/Glassfish-WARNING%3A-PWC6351%3A-In-TLD-scanning,-the-supplied-resource--file-does-not-exist-td28969004.html, too. One of the GF engineers says this exception is ignorable/harmless I am closing this issue as invalid since this exception can be caused by things created outside NB that get fed to GF. Please add additional comments, etc. in the GlassFish issue