Looks like another problem with GF, this works differently (and correctly) when using Weblogic 12.1.1. I was trying to verify my expectations using Ant project, but unfortunately it wasn't possible - because of the issue 231084 I'm not able to create Ant EAR project.

Please be aware there is also another problem (issue 215454) because of this behavior. Easier steps to reproduce copied and modified from the 215454:

- open new project wizard
- choose "Maven|Enterprise Application" and finish the wizard
- add session bean with business method to -ejb sub project
- build main project
- run -ear project. It opens browser at address
http://localhost:8080/mavenproject14-ear which is invalid

j2ee.deployment.impl.projects.DeploymentTarget.findWebUrl() is calling getChildTargetModuleID() on line 219. The call is further delegated based on the server type. If I'm using Weblogic it ends up in WLTargetModuleID which correctly returns two module children. But when using GF4 it ends up in Hk2TargetModuleID which returns zero children. Because of that DeploymentTarget is not able to evaluate correct context path and returns default value instead(mavenproject1-ear).

Reassigning to Glassfish component for evaluation

OK, looks like another problem around GlassfishConfiguration.getContextRoot().
I'll have a look at this now.

I'm debugging code around getChildTargetModuleID() first and yes, there are no children in -ear.

Module initialization:
----------------------
In following context I see J2eeModule object with MVN web module coming to be registered:

org.netbeans.modules.glassfish.javaee.ModuleConfigurationImpl.<init>(ModuleConfigurationImpl.java:92)
org.netbeans.modules.glassfish.javaee.Hk2ModuleConfigFactory.create(Hk2ModuleConfigFactory.java:128)
org.netbeans.modules.j2ee.deployment.config.ConfigSupportImpl$1.run(ConfigSupportImpl.java:802)
org.netbeans.modules.j2ee.deployment.config.ConfigSupportImpl$1.run(ConfigSupportImpl.java:784)
org.openide.util.Mutex.readAccess(Mutex.java:295)
org.netbeans.modules.j2ee.deployment.config.ConfigSupportImpl.getModuleConfiguration(ConfigSupportImpl.java:784)
org.netbeans.modules.j2ee.deployment.config.ConfigSupportImpl.ensureConfigurationReady(ConfigSupportImpl.java:242)
org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.fireServerChange(J2eeModuleProvider.java:902)
org.netbeans.modules.maven.j2ee.BaseEEModuleProvider.setServerInstanceID(BaseEEModuleProvider.java:133)
org.netbeans.modules.maven.j2ee.utils.MavenProjectSupport.setServer(MavenProjectSupport.java:178)
org.netbeans.modules.maven.j2ee.utils.MavenProjectSupport.assignServer(MavenProjectSupport.java:162)
org.netbeans.modules.maven.j2ee.utils.MavenProjectSupport.changeServer(MavenProjectSupport.java:126)
org.netbeans.modules.maven.j2ee.ProjectHookImpl.projectOpened(ProjectHookImpl.java:94)
org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectOpened(ProjectOpenedHook.java:85)
org.netbeans.spi.project.ui.support.UILookupMergerSupport$OpenHookImpl.projectOpened(UILookupMergerSupport.java:248)
org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectOpened(ProjectOpenedHook.java:85)
org.netbeans.modules.project.ui.OpenProjectList.notifyOpened(OpenProjectList.java:1230)
org.netbeans.modules.project.ui.OpenProjectList.access$1600(OpenProjectList.java:137)
org.netbeans.modules.project.ui.OpenProjectList$LoadOpenProjects.loadOnBackground(OpenProjectList.java:504)
org.netbeans.modules.project.ui.OpenProjectList$LoadOpenProjects.run(OpenProjectList.java:382)
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1432)
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2042)

In ConfigSupportImpl I see instance being passed to plugin: j2eeModule attribute with pointer #9756. This instance is being stored as key in ModuleConfigurationImpl.

Deploy:
-------
In following context I see J2eeModule object with MVN web module coming to be found in previously registered modules:

org.netbeans.modules.glassfish.javaee.ModuleConfigurationImpl.get(ModuleConfigurationImpl.java:102)
org.netbeans.modules.glassfish.javaee.ide.FastDeploy.getContextRoot(FastDeploy.java:133)
org.netbeans.modules.glassfish.javaee.ide.FastDeploy.initialDeploy(FastDeploy.java:188)
org.netbeans.modules.glassfish.javaee.ide.FastDeploy.initialDeploy(FastDeploy.java:122)
org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy(TargetServer.java:670)
org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:197)
org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:170)
org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:121)
org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:235)
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)

In ModuleConfigurationImpl.get(J2eeModule j2eemodule) I see another pointer - #13836, but our registered web module with pointer #9756 is encapsulated there as .impl.module
But this is wrong, I should be getting what has been registered.

This is coming as child object of ear module (resolved in FastDeploy.initialDeploy). But source of this is DeploymentContext context passed to initialDeploy
 ... now going down in stack ...
TargetServer.deploy(...) is doing
DeploymentContextAccessor.getDefault().createDeploymentContext(
    deployable, dir, null, dtarget.getModuleProvider().getRequiredLibraries(), null);
and passing it to upper layers.

Maybe I'm wrong but think that J2eeModule hierarchy is not being build in GF plugin. Passing to Petr Hejl to have a look why child of -ear is not the same instance as the one I got to register during project initialization.

Putting breakpoints into ModuleConfigurationImpl constructor and static get method will show those stack traces.

For ant project this works fine and I'm getting the same instance for both stack traces.

(In reply to comment #4)
> In ModuleConfigurationImpl.get(J2eeModule j2eemodule) I see another pointer -
> #13836, but our registered web module with pointer #9756 is encapsulated there
> as .impl.module
> But this is wrong, I should be getting what has been registered.
Where is such assumption coming from? What registration do you mean?

> 
> This is coming as child object of ear module (resolved in
> FastDeploy.initialDeploy). But source of this is DeploymentContext context
> passed to initialDeploy
>  ... now going down in stack ...
> TargetServer.deploy(...) is doing
> DeploymentContextAccessor.getDefault().createDeploymentContext(
>     deployable, dir, null, dtarget.getModuleProvider().getRequiredLibraries(),
> null);
> and passing it to upper layers.
> 
> Maybe I'm wrong but think that J2eeModule hierarchy is not being build in GF
> plugin. Passing to Petr Hejl to have a look why child of -ear is not the same
> instance as the one I got to register during project initialization.
> 
> Putting breakpoints into ModuleConfigurationImpl constructor and static get
> method will show those stack traces.
> 
> For ant project this works fine and I'm getting the same instance for both
> stack traces.
There is no maven specific code in infrastructure and thus it's imo either GF or Maven. J2eeModuleProvider is usually implemented by projects so the project actually creates J2eeModule.

(In reply to comment #4)
> For ant project this works fine and I'm getting the same instance for both
> stack traces.

I'll take a look at it again. This wasn't possible to verify when I was creating the ticket because of issue 231084

I'll visit your office after lunch. We can have a look at it together. This may speed up things a lot.

No need I guess. I will evaluate if the problem is on Maven side and reassign it back if it shows up it's somewhere in GF plugin..

Now debugging this in 7.3.1 and yes, you were right.
    TargetModuleID[] children = module.getChildTargetModuleID();
returns war and ejb packages stored in ear.

This is Hk2TargetModuleID and the only way to set children in Hk2TargetModuleID is addChild method so I have to find out in which context it is used in 7.3.1 and why it's not being called in 7.4.

Great, thanks for quick evaluation. Reassigning back

I finally found cause. It's 246150 change set regression:
changeset:   246150:47068fdf172f
user:        Tomas Kraus <TomasKraus@netbeans.org>
date:        Thu Feb 14 15:33:11 2013 +0100
summary:     GetPropertyCommand moved to Tooling SDK

Wrong argument was passed to CommandGetProperty. Now typo is fixed.

This bug was quite hard to find. But it's working fine now.

Checking into web-main:
-----------------------
changeset:   259713:218fd1ac9f83
commit message:
#229328 - Redeployment doesn't work for maven EAR project
#232849 - Deploy on Save does not work

Fixed 246150 changeset regression where wrong argument was passed to

Integrated into 'main-silver', will be available in build *201307292300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/218fd1ac9f83
User: Tomas Kraus <TomasKraus@netbeans.org>
Log: #229328 - Redeployment doesn't work for maven EAR project
#232849 - Deploy on Save does not work

Fixed 246150 changeset regression where wrong argument was passed to
CommandGetProperty command.