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.

Bug 177214 - Build with dependencies causing error when run EAR with cross-refernced modules
Summary: Build with dependencies causing error when run EAR with cross-refernced modules
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Maven (show other bugs)
Version: 6.x
Hardware: PC All
: P2 normal (vote)
Assignee: issues@javaee
URL:
Keywords:
Depends on: 184979 186221 186223
Blocks:
  Show dependency tree
 
Reported: 2009-11-19 08:31 UTC by Jaroslav Pospisil
Modified: 2010-08-23 22:15 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
non finalized maven side patch (2.59 KB, application/octet-stream)
2009-11-20 09:29 UTC, Milos Kleint
Details
Glassfish error with the new approach (8.64 KB, text/plain)
2010-05-12 14:24 UTC, Petr Jiricka
Details
A new partial fix (5.96 KB, text/plain)
2010-05-17 16:06 UTC, Petr Jiricka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Pospisil 2009-11-19 08:31:33 UTC
build 200911190201,JDK1.6.0_16,Win Vista,Mac

1.Start with new userdir
2.Create new maven enterprise application with war and ejb modules
3.Create session bean in ejb module and add bussiness class,select Remote interface in wizard,save ejb
4.Create servlet in war module,call enterprise bean on previously created bean and then call its bussiness method somewhere in processRequest method of servlet.
5. Now,if you invoke build with dependencies action on ear,and then Run app,deployment fail(see Glassfish v3 log):

19.11.2009 16:18:06 com.sun.enterprise.glassfish.bootstrap.ASMain main
INFO: Launching GlassFish on Felix platform
Welcome to Felix
================
INFO: Perform lazy SSL initialization for the listener 'http-listener-2'
INFO: Grizzly Framework 1.9.18-e started in: 29ms listening on port 8181
INFO: Grizzly Framework 1.9.18-e started in: 95ms listening on port 8080
INFO: Starting Grizzly Framework 1.9.18-e - Thu Nov 19 16:18:08 CET 2009
INFO: GlassFish v3 (72) startup time : Felix(1982ms) startup services(869ms) total(2851ms)
INFO: Starting Grizzly Framework 1.9.18-e - Thu Nov 19 16:18:08 CET 2009
INFO: Grizzly Framework 1.9.18-e started in: 32ms listening on port 4848
INFO: Grizzly Framework 1.9.18-e started in: 966ms listening on port 7676
INFO: Grizzly Framework 1.9.18-e started in: 977ms listening on port 3700
INFO: Binding RMI port to *:8686
INFO: JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://129.157.251.170:8686/jndi/rmi://129.157.251.170:8686/jmxrmi
INFO: javassist.util.proxy.ProxyFactory.classLoaderProvider = org.glassfish.weld.WeldActivator$GlassFishClassLoaderProvider@3d2e6c
INFO: Hibernate Validator bean-validator-3.0-JBoss-4.0.2
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: Using com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the delegate
INFO: Grizzly Framework 1.9.18-e started in: 10ms listening on port 8080
INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started
INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir = C:\Program Files\glassfish-v3-b72\glassfish\modules\autostart, felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = C:\Users\JP154641\AppData\Local\Temp\fileinstall-5485210572382598094, felix.fileinstall.filter = null}
INFO: SEC1002: Security Manager is OFF.
INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir = C:\Program Files\glassfish-v3-b72\glassfish\domains\domain1\autodeploy\bundles, felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = C:\Users\JP154641\AppData\Local\Temp\fileinstall--3588956835725094013, felix.fileinstall.filter = null}
INFO: Security startup service called
INFO: SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
INFO: Realm admin-realm of classtype com.sun.enterprise.security.auth.realm.file.FileRealm successfully created.
INFO: Realm file of classtype com.sun.enterprise.security.auth.realm.file.FileRealm successfully created.
INFO: Realm certificate of classtype com.sun.enterprise.security.auth.realm.certificate.CertificateRealm successfully created.
INFO: Security service(s) started successfully....
INFO: Created HTTP listener http-listener-1 on port 8080
INFO: Created HTTP listener http-listener-2 on port 8181
INFO: Created HTTP listener admin-listener on port 4848
INFO: Created virtual server server
INFO: Created virtual server __asadmin
INFO: Virtual server server loaded system default web module
INFO: Updating configuration from org.apache.felix.fileinstall-autodeploy-bundles.cfg
INFO: Installed C:\Program Files\glassfish-v3-b72\glassfish\modules\autostart\org.apache.felix.fileinstall-autodeploy-bundles.cfg
INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir = C:\Program Files\glassfish-v3-b72\glassfish\domains\domain1\autodeploy\bundles, felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = C:\Users\JP154641\AppData\Local\Temp\fileinstall--7028099859007330931, felix.fileinstall.filter = null}
INFO: JTS5014: Recoverable JTS instance, serverId = [3700]
INFO: Portable JNDI names for EJB NewSessionBean : [java:global/com.mycompany_MySimpleEE6EntApp-ear_ear_1.0-SNAPSHOT/MySimpleEE6EntApp-ejb-1.0-SNAPSHOT/NewSessionBean, java:global/com.mycompany_MySimpleEE6EntApp-ear_ear_1.0-SNAPSHOT/MySimpleEE6EntApp-ejb-1.0-SNAPSHOT/NewSessionBean!ejb.NewSessionBeanRemote]
INFO: Glassfish-specific (Non-portable) JNDI names for EJB NewSessionBean : [ejb.NewSessionBeanRemote#ejb.NewSessionBeanRemote, ejb.NewSessionBeanRemote]
SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
        at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:219)
        at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:198)
        at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:64)
        at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
        at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:336)
        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:362)
        at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:201)
        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:789)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:952)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
        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:619)
Caused by: java.lang.RuntimeException: Error while binding JNDI name ejb.NewSessionBeanRemote__3_x_Internal_RemoteBusinessHome__ for EJB : NewSessionBean
        at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1528)
        at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:197)
        at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:161)
        at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:207)
        ... 32 more
Caused by: javax.naming.NameAlreadyBoundException [Root exception is org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0]
        at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:75)
        at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:596)
        at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:621)
        at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:659)
        at javax.naming.InitialContext.bind(InitialContext.java:400)
        at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishCosNamingObject(GlassfishNamingManagerImpl.java:224)
        at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:5417)
        at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1513)
        ... 35 more
Caused by: org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0
        at org.omg.CosNaming.NamingContextPackage.AlreadyBoundHelper.read(AlreadyBoundHelper.java:60)
        at org.omg.CosNaming._NamingContextStub.bind(_NamingContextStub.java:67)
        at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:585)
        ... 41 more

SEVERE: Exception while loading the app
java.lang.RuntimeException: EJB Container initialization error
        at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:219)
        at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:198)
        at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:64)
        at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
        at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:336)
        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:362)
        at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:201)
        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:789)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:952)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
        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:619)
Caused by: java.lang.RuntimeException: Error while binding JNDI name ejb.NewSessionBeanRemote__3_x_Internal_RemoteBusinessHome__ for EJB : NewSessionBean
        at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1528)
        at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:197)
        at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:161)
        at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:207)
        ... 32 more
Caused by: javax.naming.NameAlreadyBoundException [Root exception is org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0]
        at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:75)
        at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:596)
        at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:621)
        at com.sun.jndi.cosnaming.CNCtx.bind(CNCtx.java:659)
        at javax.naming.InitialContext.bind(InitialContext.java:400)
        at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishCosNamingObject(GlassfishNamingManagerImpl.java:224)
        at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:5417)
        at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1513)
        ... 35 more
Caused by: org.omg.CosNaming.NamingContextPackage.AlreadyBound: IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0
        at org.omg.CosNaming.NamingContextPackage.AlreadyBoundHelper.read(AlreadyBoundHelper.java:60)
        at org.omg.CosNaming._NamingContextStub.bind(_NamingContextStub.java:67)
        at com.sun.jndi.cosnaming.CNCtx.callBindOrRebind(CNCtx.java:585)
        ... 41 more

INFO: Perform lazy SSL initialization for the listener 'http-listener-2'
INFO: Created HTTP listener http-listener-2 on port 8181
INFO: Grizzly Framework 1.9.18-e started in: 7ms listening on port 8181
Comment 1 Jaroslav Pospisil 2009-11-19 08:33:31 UTC
WORKAROUND: If you build all modules separately - just Build on each module,ear last, Run works fine.
Comment 2 Jaroslav Pospisil 2009-11-19 09:17:40 UTC
Notice: From build log it seems to me,that Build with dependencies it taking ejb dependency jar from both war and ear modules,instead of only ear module,which happens when I build all modules separately.

IDE log excerpt:

INFO [org.netbeans.lib.profiler.infolog]: >>> Profiler agent [port=0, id=-111]: STATE_INACTIVE
WARNING [glassfish]: Exception while loading the app : java.lang.RuntimeException: EJB Container initialization error%%%EOL%%%Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method : java.lang.RuntimeException: EJB Container initialization error%%%EOL%%%
INFO [org.netbeans.modules.j2ee.deployment.impl.TargetServer]: Cannot incrementally deploy to more than one target
WARNING [org.openide.filesystems.Ordering]: Not all children in Loaders/application/x-java-archive/Factories/ marked with the position attribute: [org-netbeans-modules-java-jarloader-JarDataLoader.instance], but some are: [org.netbeans.modules.java.j2seplatform.resources.xml-ergonomics.instance]
WARNING [org.openide.filesystems.Ordering]: Not all children in Loaders/text/x-dd-application6.0/Factories/ marked with the position attribute: [org-netbeans-modules-j2ee-ddloaders-app-EarDataLoader.instance, org-netbeans-modules-j2ee-ddloaders-client-ClientDataLoader.instance, org-netbeans-modules-j2ee-ddloaders-ejb-EjbJar30DataLoader.instance, org-netbeans-modules-j2ee-ddloaders-ejb-EjbJarDataLoader.instance, org-netbeans-modules-j2ee-ddloaders-web-DDDataLoader.instance, org-netbeans-modules-j2ee-ddloaders-web-DDWeb25DataLoader.instance], but some are: [org.netbeans.modules.j2ee.ddloaders.resources.xml-ergonomics.instance]
WARNING [glassfish]: Dotted name path applications.application.* not found.%%%EOL%%%
INFO [org.netbeans.lib.profiler.infolog]: >>> Profiler agent [port=0, id=-111]: STATE_INACTIVE
INFO [glassfish]
java.util.concurrent.TimeoutException
        at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228)
        at java.util.concurrent.FutureTask.get(FutureTask.java:91)
[catch] at org.netbeans.modules.glassfish.common.EnableComet.run(EnableComet.java:85)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:602)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1084)
WARNING [glassfish]: Exception while loading the app : java.lang.RuntimeException: EJB Container initialization error%%%EOL%%%Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method : java.lang.RuntimeException: EJB Container initialization error%%%EOL%%%
INFO [org.netbeans.modules.j2ee.deployment.impl.TargetServer]: Cannot incrementally deploy to more than one target
WARNING [glassfish]: Dotted name path applications.application.* not found.%%%EOL%%%
Comment 3 Milos Kleint 2009-11-20 06:33:58 UTC
the problem seems to be in step 4. where the IDE will add the ejb project as dependency of the war project with scope compile. That will make the war file to include the ejb jar in the WEB-INF/lib folder.

diving some more to see who is responsible for the addition.
Comment 4 Milos Kleint 2009-11-20 06:53:15 UTC
BTW I don't see how it could work for you when building the projects separately. I guess you didn't build everything or didn't build things in the correct order. This never works.
Comment 5 Milos Kleint 2009-11-20 07:20:12 UTC
the workaround is simple. in the webapp, add <scope>provided</scope> in the ejb project dependency.
Comment 6 Jaroslav Pospisil 2009-11-20 07:23:58 UTC
Well,I admit it worked somehow only once - first time I've created this scenario (clean userdir,new name for ent app,stopped glasfish).Then I tried Build with dependencies and now I'm also unable to make it work again,no matter what I do.
Comment 7 Milos Kleint 2009-11-20 09:29:08 UTC
Created attachment 91439 [details]
non finalized maven side patch

attached is a partial possible patch that could solve this problem. However it could also have unforseen consequences on other workflows..
Comment 8 Milos Kleint 2009-11-20 09:51:48 UTC
reassigning to j2ee/ejb with the following comments.

The location with the root logic is at 
org.netbeans.modules.j2ee.ejbcore.action.CallEjbGenerator#addReference
based on some conditions I don't fully understand, it adds the ejb jar dependency to the web project by either calling the EnterpriseReferenceContainer or ProjectClassPathModifier. 
In both cases I don't see a clear way on the maven side of things to decide if the maven dependency shall be "provided" or not (and therefore included/excluded from the war file)
The ERC scenario distinguishes between local and remote references. what implications does it have on the packaging of the web project? Still doing some smartisms here should be relatively encapsulated. What other codebase uses this api?

The case described in this issue goes the ProjectClassPathModifier way however which is rather generic and there is no additional information passed to the maven project that would tell it what type of dependency is to be added. Any change here on maven side could influence unrelated parts of the IDE. I guess we could come up with a unique ClassPath type which would encode this information. Is there a scenario when we want to ship the ejb jar as part of the webapp?

The maven side patch I've attached lists both classes involved on the maven side of the workflow. Please review the current state and suggested patches (the PCPM one is hacky and doesn't include the suggested ClassPath type addition.

Please evaluate and describe what is being done on the ejb side of things, why the generic PCPM api is used and what solution you suggest/prefer. Also please evaluate what other parts of yur codebase could exhibit similar problems.
Comment 9 Andrey Yamkovoy 2009-11-23 07:35:15 UTC
Since the simple workaround provided by Milos is working downgrade to P2.
Comment 10 Andrey Yamkovoy 2009-11-23 08:33:04 UTC
The problem is 2 ejb module jar files packed in the ear so application server unable to deploy such a ear with 2 ejbs with the same interface. There are no such a problems in the ant based Enterprise Application because it packed ear only with 1 ejb jar (war file not contains ejb jar when included into ear). If you build web app separately the ejb jar will be included (by default) into war file. 

I don't see any issues on the ejb side. In my understanding this should be resolved on the maven side by following the same scenario as ant based projects.
Comment 11 Milos Kleint 2009-11-23 09:13:41 UTC
sorry, andrey. reassigning back.

you haven't really commented on anything I described in my last comment. Let me reiterate. The EJB codebase is calling a *generic* non-j2ee API codebase and somehow I'm supposed to know (on the non-j2ee side) whether the ejb is being included in some sort of 3rd project or not. The fact that it works in ant projects is irrelevant and as I suggested you will have to change your code to accomodate maven projects.
Comment 12 David Konecny 2009-11-23 19:58:23 UTC
Re. "the problem seems to be in step 4. where the IDE will add the ejb project as dependency of the war project with scope compile. That will make the war file to include the ejb jar in the WEB-INF/lib folder" - before EE6 work I assumed that EAR packaging just works and so I ignored it. In recent weeks I discovered that there is several problems - some of them were fixed on NB side, some of them on GF side, some will need to be revisited in future. I will try to explain them without confusing you even more.

Ant based *Web* project can be build in two different ways based on whether you are building directly just Web project or whether Web project is being built as a dependency of EAR project build. When just WAR is build then all jars (including EJB jars) goes to WEB-INF/lib. When EAR is build then all WAR's jars are copied to EAR's root instead.

First thing to be aware of: prior EE6 it does not make any sense to have EJB jar in WAR's WEB-INF/lib. All what should be copied to WAR is Remote Interfaces of all EJBs. You could deploy such WAR and call remote EJB from it. Since EE6 you can deploy EJBs in WAR and placing whole EJB to WAR has very different outcome. This is something what should be resolved in future.

Second thing to be aware of: prior to EE6 all JARs were copied to EAR's root and ClassPath attribute was set in JAR's manifests to list of referenced JARs. EE6 spec clarified what is visible in classloader of WEB/EJB/AppClient executed in EAR's context. Since NB68 only J2EE module JARs (ejb,web,appclient) are copied to the EAR's root and all other JARs (eg. Java classes projects, JPA entity classes jar) are copied to EAR's lib folder. It is hardcoded in NB to use always "lib" folder but actually folder name can be overridden in application.xml. Because spec guarantees that all JARs in EAR's lib folder are visible to all J2EE modules the ClassPath manifest attribute is not specified anymore in individual JARs.

We used to have bunch of problems during GF deployment saying that one EJB cannot be deployed twice but these were resolved both on NB side (sometimes EJB jar was left in WAR's WEB-INF/lib and also in EAR and because EE6 allows deployment of EJB from WAR it was causing this duplicity error) and GF side (errors in AppClient deployment logic).

Other frequent complaint from GF/EE6 team is that EJB project should always have two parts (JARs): EJB interfaces and EJB impl and all other J2EE modules should reference only EJB interfaces jar. Which is nice in theory but totally useless overhead in practice - if EAR contains EJB and WAR and only local interfaces are used then why to bother separating EJB interface into separate JAR. But if we wanted to implement EE6 spec strictly then we would have to follow it. Check chapter "EE.8.3 Class Loading Requirements" in EE6 spec - according to that we basically building non-portable JEE6 applications in NB because we are relying on optional classloading requirement: "Portable [WEB] applications must not depend on having or not having access to these classes or resources:  The content of any EJB jar files included in the same ear file.".

It is likely I forgot to mention something so ask if something is not clear.

In this Maven issue I agree that "provided" should be used and should resolve it. If users want something different (like separate EJB interfaces and impl they still can do it by hand and then use compile scope).

Milos, does it answer all your questions? Your question about CallEjbGenerator does not seem to me relevant to your problem but if you think it is then I will have a look and try to read the code again - I had a look and it is not really obvious what's going on. While reading the code my ring finger, resting above Backspace key, was getting restless ticks. That or Delete Refactoring should be applied there.
Comment 13 Milos Kleint 2009-11-23 23:57:20 UTC
Thanks David for the explanation.

one thing I didn't explicitly mention is that within the web project, it is not known if the web project is embedded in the ear or not. There is no relevant information within the maven metadata about it. All projects are completely separate in terms of building. On the ear side we perform some gross hacks to figure the J2eeModules from opened projects. If not found we wrap the war/ejb in a dummy J2eeModule instance.

the CallEjbGenerator calls a generic, non-j2ee api for adding dependencies to a project. 
It can tell if the dependency is to be compile/runtime/test dependency. Fine. but based on what do I decide that a compile dependency you pass in, is a "compile" scope and not "provided" scope or vice versa. You seemed to suggest I always use provided, but that the same time asserted that for single, non-ear webapp it should be packed within the war file. The way to tell maven if the dependency is to be included in the war file is to define the proper scope: "Provided" means no inclusion, "compile" means do include. Both scopes compose the Compilation ClassPath.
I also have no knowledge of j2ee level of the given project within the CPModifier/Exterder classes.

I still don't see a way out on maven side only. The CallEjbGenerator needs to figure if provided or compile is to be used based on the j2ee environment or data entered by the user. If it cannot deduct it from current UI, it will have to add a maven-specific UI element that will let the user decide. And then we need to figure a way to pass that information to the maven project codebase that handles adding dependencies.
Comment 14 Milos Kleint 2009-11-23 23:58:35 UTC
Ken, this issue is most probably something to document in release notes.
Comment 15 Andrey Yamkovoy 2009-11-24 05:17:34 UTC
To decide 2 projects are parts of the same enterprise application you can use the utility method org.netbeans.modules.j2ee.ejbcore.Utils#areInSameJ2EEApp(Project project1, Project project2) or create you own like this in the maven codebase optimized for maven project types. So based on the result of this method you can set scope for the dependency: "provided" for projects in the same ent app and "compile" for others.
Comment 16 Antonin Nebuzelsky 2010-01-14 06:58:27 UTC
Changing the default owner to issues@javaee.
Comment 17 Petr Jiricka 2010-03-16 17:03:47 UTC
Though one thing that is true is that EJB functionality is not quite symmetrical wrt. Ant and Maven, e.g. the j2ee.api.ejbmodule module depends on AntArtifact + friends. Same for ejbcore, including David's recent fix for bug 179698 (which is related to this). Maybe we could make it more symmetrical?
Comment 18 cistox 2010-05-11 08:05:07 UTC
I have the same problem.

Even if the EAR is fully verified (all validations are passed) the application cannot be started successfully.

While working with Web Applications is solid the Enterprise Application project has too many troubles for a long time.

It is really tricky to build, deploy and run EARs with Netbeans.

Sorry but I suspect there are been few serious tests on Enterprise Application until now because it is really easy to catch these issues while working on classing J2EE apps...

There are issues like:
- JAR files that are locked if the Enterprise Application is running.
  So here the developer is constrained to stop the server to make a successfull clean and build.

- There are JAR files created (built) with 0 Kb... so the build process of the EAR will fail.
  Under this case a complete Clean is necessary and often Netbenas 6.8 (and previous) must be restarted !?!
  There have been situations where we are even contrained to clean the Netbeans cache...

NOTE: all of these situations can be catched with classic J2EE 1.5 applications (fully verified)
Comment 19 Petr Jiricka 2010-05-12 14:24:05 UTC
Created attachment 98862 [details]
Glassfish error with the new approach

After implementing enhancement 179698 (separate jar for remote interfaces), the best practice approach to this scenario is now the following:

1. Create a new Maven Java EE application with war and ejb modules
2. Create a Maven library project within this application and set its source level to 1.5
3. Create a session bean in the EJB module with remote interfaces in the library module. The library module will be added on classpath of the EJB module. Create a business method in this EJB.
4. Create a servlet in the war module, call enterprise bean on the previously created bean, and add call to the business method in the processRequest method. The library will be added to the dependencies of the war module.
5. Build with dependencies on EAR, then Run

This still does not work, even if I apply the workaround suggested by Milos to use the provided scope for the library jar in war (and ejb). I am attaching the GlassFish log - it seems like there is a packaging problem and the EAR does not correctly package the library.
Comment 20 Petr Jiricka 2010-05-14 19:04:30 UTC
Hi cistox,

regarding the problem you mention, they do sound serious, but unrelated to the specific case discussed in this bug report. Could I please ask you to file separate issues with steps to reproduce for each of these? 
Also, do you also see these problems when you build/deploy the project generated by NetBeans from the command line? Or does it only happen when using NetBeans? Thanks.
Comment 21 Petr Jiricka 2010-05-17 16:06:41 UTC
Created attachment 99098 [details]
A new partial fix

I am attaching a new patch which (partially) fixes this problem. Namely, it addresses the following subissues:
- When creating a EJB with remote interface in another library, Java EE API is added to the classpath of the library incorrectly (without the provided scope) - bug 186221
- After Call EJB is done in a servlet (against remote EJB with interface in the *same* EJB project), the EJB project is added to classpath of the web module incorrectly (without the provided scope)

This patch is based on Milos's previous patch. Here are some comments and some more questions:
1. Regarding the question whether the provided scope should always be used, or just sometimes, I believe (and this is what David also seems to say) that if you are adding an EJB module (or Web module) on classpath, the scope should be provided. Especially with Java EE 6, and especially since we now support client jars, you should NEVER package an EJB module inside WEB-INF/lib.
2. With client jar lib, it is not as clear if you should use provided scope or not. If the war file is not in the same EAR as the EJB, then the client jar must be packaged in WEB-INF/lib. If it is in the same EAR, then it should not be packaged. But I am wondering whether we can easily distinguish these cases, and whether we may need some UI for this after all, as Milos suggests. This part still does not work with this patch - currently the client jar is always packaged in WEB-INF/lib (provided scope is not declared).
3. Milos also suggests we may want to introduce a new type of classpath. I did not need this for item 1 above, but it may be useful for item 2.
4. Nevertheless, the patch does introduce a new kind of classpath, and this is used in the fix of the 186221 subissue. This approach was recommended to me by Tomas Zezula. (So the patch is kind of a hybrid - for aspect 4, the new kind of classpath is used, for aspect 1 it is not used.)
5. I am still hitting subproblem 184979, and because of this, the behavior appears kind of nondeterministic to me. Sometimes things work, sometimes the packaging has weird quirks.
6. When testing this, you still have to apply workaround for bug 186223 (documented in the report).
Comment 22 Petr Jiricka 2010-05-17 16:08:55 UTC
Cc'ing Dafe (as the patch modifies the base Maven module) and Tomas Z (as he recommended the introduction of the new classpath type discussed above). What does everyone think?
Comment 23 David Konecny 2010-05-17 23:16:45 UTC
(In reply to comment #21)
> 1. Regarding the question whether the provided scope should always be used, or
> just sometimes, I believe (and this is what David also seems to say) that if
> you are adding an EJB module (or Web module) on classpath, the scope should be
> provided. Especially with Java EE 6, and especially since we now support client
> jars, you should NEVER package an EJB module inside WEB-INF/lib.

Right. Packaging an EJB module in WEB-INF/lib could result in container trying to deploy one EJB twice - one directly from EAR and second time the same ejb packaged in WAR. So using provided scope should solve it. Although it depends on container behaviour which is not strictly required by EE spec - have a look at "EE.8.3.1 Web Container Class Loading Requirements" chapter section "Components in the web container may have access to the following classes
and resources. [...]". On the other hand if server does not support that it results in bothersome redundancy even for EJBs with Local interface so my expectation (confirmed by GF team) is that most of servers will always support it.

> 2. With client jar lib, it is not as clear if you should use provided scope or
> not. If the war file is not in the same EAR as the EJB, then the client jar
> must be packaged in WEB-INF/lib.

Yes, otherwise you would get ClassNotFoundEx.

> If it is in the same EAR, then it should not
> be packaged.

It will not do any harm if it is - it is just interface.

> But I am wondering whether we can easily distinguish these cases,
> and whether we may need some UI for this after all, as Milos suggests. This
> part still does not work with this patch - currently the client jar is always
> packaged in WEB-INF/lib (provided scope is not declared).

I would not worry about it. It can stay there. What Ant projects do is that both EJB and WAR will reference client jar lib and during packaging EAR the jar lib is copied to EAR/lib folder from where it is shared by both EJB and WAR and WAR/WEB-INF/lib is empty.
Comment 24 David Simonek 2010-05-18 07:04:02 UTC
No objections from my side on Maven CPExtender part.
Comment 25 Tomas Zezula 2010-05-18 07:47:16 UTC
Looks fine to me.
Comment 26 Petr Jiricka 2010-05-19 09:28:08 UTC
Committed the patch attached above: http://hg.netbeans.org/web-main/rev/9cbd59832985

As this is just a partial fix, I am leaving open as a P2 and requesting a waiver for NB 6.9.
Comment 27 Quality Engineering 2010-05-20 06:13:28 UTC
Integrated into 'main-golden', will be available in build *201005192201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/9cbd59832985
User: pjiricka@netbeans.org
Log: #177214, #186221 - addressing a couple subproblems of development of EJBs with remote interfaces use case with Maven. Namely, client stub jar should depend on the Java EE APIs with provided scope, and Java EE modules (Web, EJB) should be added on classpath of another module also with provided scope.
Comment 28 Petr Jiricka 2010-05-21 07:46:49 UTC
6.9 waiver approved.
Comment 29 David Konecny 2010-08-22 23:19:04 UTC
Petr, so what remain to be done?
Comment 30 Petr Jiricka 2010-08-23 08:37:09 UTC
I must say I am not sure - probably just bug 184979? I.e. when the new release of the Maven EAR plugin is released, update our archetypes to refer to it.
Comment 31 David Konecny 2010-08-23 22:15:53 UTC
(In reply to comment #30)
> I must say I am not sure - probably just bug 184979? I.e. when the new release
> of the Maven EAR plugin is released, update our archetypes to refer to it.

I think so too.