Bug 181992

what is a dot-dar file?

it looks like this is a problem in the Ent App project or the EJB Module project build file....

Let the owner of the project types evaluate the situation first.

A dar file is deployment of a database JDBC JNDI entry for Borland Application Server...ignore it!  Can't see that the dar is related to this issue because the application deploys to glassfish from the commandline, just not from netbeans.

We are porting away from Borland, to Glassfish, maintaining backwards compatibility for the time being. Glassfish configures such things using the admin console.

As you can see below, the same thing happens when deploying the ear without the Borland-style dar included:

pre-init:
Copying 115 files to /big/dcampbel/clients/deh/tabs/cr_46258_2/tabs
init-private:
init-userdir:
init-user:
init-project:
do-init:
post-init:
init-check:
init:
deps-jar:
deps-j2ee-archive:
Copying 115 files to /big/dcampbel/clients/deh/tabs/cr_46258_2/tabs
tabs-ejb.init:
tabs-ejb.deps-jar:
/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/nb/tabs/nbproject/build-impl.xml:160: The following error occurred while executing this line:
/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/nb/tabs-ejb/nbproject/build-impl.xml:479: The following error occurred while executing this line:
/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/nb/tabs-ejb/nbproject/build-impl.xml:176: Cannot build classfiles for source directories: [/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/src, /big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/meta/properties, /big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/nb/tabs-ejb/build/generated-sources/ap-source-output]
BUILD FAILED (total time: 1 minute 34 seconds)

Thanks for the info on the DAR file.

From the looks of the ant output, the IDE has not started to attempt to do the operations that are equivalent to 'asadmin deploy xyz.ear'...  It is still trying to build the directory structure that will be used for directory deployment...  I think.

Are there any flags I can pass to netbeans to produce more useful debug for this case?

It might be nice to see:

the output of ant's verbose setting... 

Use the Options item of the Tools menu to open the dialog that allows you to change the ant output level.

Select the Miscellaneous/Ant page and tab and change the Verbosity Level to Verbose or Debug.

Close the dialog with OK.

Created attachment 95147 [details]
output with ant debug setting

Added attached output as requested

Java guys, what can be causing build script to fail in JavacTask:

/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/nb/tabs-ejb/nbproject/build-impl.xml:176: 
Cannot build classfiles for source directories: 
[/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/src, 
/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/meta/properties, 
/big/dcampbel/clients/deh/tabs/cr_46258_2/tabs/nb/tabs-ejb/build/generated-sources/ap-source-output]

        at org.netbeans.modules.java.source.ant.JavacTask.execute(JavacTask.java:85)

Setting project property ensure.built.source.roots=false causes the "Cannot build classfiles for source directories" issue to go away.

However, having done that, then the deploy goes ahead but dies with an exception  that is shown in the glassfish log saying that one of the EJB session bean classes is not found.  And it does this even though from the commandline, and when deploying from the admin web, the ear file build by netbeans deploys JUST FINE.

Here's the glassfish exception [let me know if this should go into a different bug case]:

[#|2010-03-18T15:00:38.704+1000|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=29;_ThreadName=Thread-1;|Exception while deploying the app
java.lang.RuntimeException: Error processing EjbDescriptor
	at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:273)
	at com.sun.enterprise.deployment.EjbDescriptor.visit(EjbDescriptor.java:2400)
	at com.sun.enterprise.deployment.EjbCMPEntityDescriptor.visit(EjbCMPEntityDescriptor.java:328)
	at com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:726)
	at com.sun.enterprise.deployment.Application.visit(Application.java:1744)
	at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:774)
	at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:253)
	at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:222)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:145)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:78)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:612)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:554)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:262)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
	at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
	at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
	at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
	at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
	at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
	at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
	at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
	at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
	at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
	at java.lang.Thread.run(Thread.java:636)
Caused by: java.lang.ClassNotFoundException: au.gov.sa.environment.tabs.ejb.entity.CustomerTenementBean
	at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:736)
	at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:626)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
	at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:218)
	... 39 more
|#]

I tried to resolve that (without a reproducible test case, I have no means the verify whether or not the fix actually helps):
http://hg.netbeans.org/jet-main/rev/b6fdd12e9bdb

David, the last exception seems unrelated to java.source, please take a look at it. Thanks.

Integrated into 'main-golden', will be available in build *201003200200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/b6fdd12e9bdb
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #181992: cache may not (and should not) exist for target directory of annotation processing.

re. "java.lang.ClassNotFoundException: au.gov.sa.environment.tabs.ejb.entity.CustomerTenementBean" - I do not know what ensure.built.source.roots property is for and how does it alter build process. There are differences between directory deployment and JAR deployment, eg. compile on save affects whether class will be up to date in the directory to be deployed or not. It looks like above property caused CustomerTenementBean not being compiled??

Created attachment 95508 [details]
Binary patch.

Binary patch, to be installed into ${NETBEANS_INSTALL_DIR}/java/modules/patches/org-netbeans-modules-java-source/181992.jar (${NETBEANS_INSTALL_DIR}/java/modules should exist, patches/org-netbeans-modules-java-source need to be created).

Created attachment 95565 [details]
projects for reproducing this problem

I attach a tar containing an ejb project and an enterprise application project.  I am working with IDE Dev 201003210200.

If you build and deploy the ejb project, everything works perfectly.
If you build the enterprise application project it works perfectly.
If you deploy the enterprise application project, it fails with this error [ant verbosity level has been set to debug]:

Exiting /big/dcampbel/clients/deh/tabs/cr_46258_2/submission2/nb/tabstest-ejb/build.xml.
/big/dcampbel/clients/deh/tabs/cr_46258_2/submission2/nb/tabstest/nbproject/build-impl.xml:160: The following error occurred while executing this line:
/big/dcampbel/clients/deh/tabs/cr_46258_2/submission2/nb/tabstest-ejb/nbproject/build-impl.xml:436: The following error occurred while executing this line:
/big/dcampbel/clients/deh/tabs/cr_46258_2/submission2/nb/tabstest-ejb/nbproject/build-impl.xml:214: Cannot build classfiles for source directories: [/big/dcampbel/clients/deh/tabs/cr_46258_2/submission2/src, /big/dcampbel/clients/deh/tabs/cr_46258_2/submission2/meta/properties]
        at org.netbeans.modules.java.source.ant.JavacTask.execute(JavacTask.java:91)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:390)
        at org.apache.tools.ant.Target.performTasks(Target.java:411)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1360)
        at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1212)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:390)
        at org.apache.tools.ant.Target.performTasks(Target.java:411)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1360)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1329)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1212)
        at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:278)
        at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:521)
        at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151)
BUILD FAILED (total time: 0 seconds)

Well...I deleted the entire ~/.netbeans/dev directory and reopened the projects, and this problem seems to have gone away for now.  Don't know what confused netbeans to get that exception, but I'm not seeing it now.  I wish all my troubles went away like that.

Created attachment 96297 [details]
new projects for reproducing this problem

I think I have this issue narrowed down a little now.

I have attached some new projects for reproducing this problem.

I think that due to this problem, netbeans is unable to deploy any EARs to glassfish that contain EJBs where the EJB source is from an external source root.  The EJBs deploy just fine, as do built ears from the commandline, but they do not deploy in netbeans.

In the attached example_projects5.jar, deployment fails, but if you edit the EJB project.properties to make the src and meta refer to ./src and ./meta instead of ../../src and ../../meta, then it works fine.  There are symbolic links in the tar file already linking src to ../../src and meta to ../../meta.

In working with this problem, I've found it necessary at times to move aside my ~/.netbeans/dev directory and reopen projects from scratch, to get consistent behaviour.

I have found the root cause (thanks for the reproducible test case). The problem is that the external source root is now owned by the project, as per the FileOwnerQuery, only the package with the files are. This causes that the (Java) cache is not created for the source root (as ClassPath does not answer for such source root), and BinaryForSourceQuery also returns nothing, which leads to the error. When we were solving similar problems for J2SE Project, we changed the registration (call to SourcesHelper.registerExternalRoots) to register whole source roots. It is necessary to use the two-parameter version of registerExternalRoots and pass "false" as the second parameter. This should be done at least in EjbJarSources:152 and WebSources:168. I can do that myself if needed.

David, when the changes are done, you will probably need to delete ${userdir}/var/cache/index, so that the cache is filled with correct information.

Thanks Honza! I applied the changes you suggested (and patched AppClient as well) and problem disappeared. I wonder whether we could prevent something like that in future - by adding somewhere some warning or making SourcesHelper.registerExternalRoots by default work in "false" mode. Any ideas?

eb9064d058af