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 176096 - index.jsp not displayed when run EAR
Summary: index.jsp not displayed when run EAR
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Maven (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vince Kraemer
URL:
Keywords:
: 188944 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-11-06 10:30 UTC by Jaroslav Pospisil
Modified: 2010-08-08 22:31 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Pospisil 2009-11-06 10:30:55 UTC
Run valid enterprise application(with session bean in ejb and servers set) - no index.jsp page is displayed in
browser,there's error page instead ("http://localhost:8080/com.mycompany_mavenproject1-ear_ear_1.0-SNAPSHOT")
If I manually change URL to "http://localhost:8080/mavenproject1-web/", index.jsp is correctly displayed.
Comment 1 Antonin Nebuzelsky 2010-01-14 06:58:26 UTC
Changing the default owner to issues@javaee.
Comment 2 Petr Jiricka 2010-03-31 14:50:26 UTC
I can not reproduce - in fact, for me the browser is not opened at all. Do you have exact steps to reproduce?
Comment 3 Petr Jiricka 2010-03-31 15:48:49 UTC
Here is what I found out. 

When I deploy a Maven EAR project, for some reason the TargetModuleID returned by GlassFish does not contain any children (corresponding to the web module included in the EAR). Because of this, method org.netbeans.modules.j2ee.deployment.impl.projects.DeploymentTargetImpl#findWebUrl returns null.
For Ant-based EAR projects, the returned TargetModuleID contains the correct children, as well as for Maven-based EAR projects targeting WebLogic. Passing to Vince.
Comment 4 Vince Kraemer 2010-04-01 15:15:41 UTC
PetrJ: which gf are you deploying to?
Comment 5 Petr Jiricka 2010-04-02 07:28:04 UTC
I am trying with v3 final.
Comment 6 David Konecny 2010-07-27 18:58:26 UTC
Vince, any update on this issue? Is it really a problem on GF side? Or does something else needs to happen on Maven EAR projest side? Thx.
Comment 7 David Konecny 2010-07-27 19:41:41 UTC
*** Bug 188944 has been marked as a duplicate of this bug. ***
Comment 8 David Konecny 2010-08-06 02:58:05 UTC
I should be doing something else but this issue was real pain for me and seeing that Vince in on holiday for next week or two I decided to fix it - 5a173d79a765
Comment 9 Petr Jiricka 2010-08-06 07:41:05 UTC
Thanks, though it looks like the current fix is a heuristic which may or may not work, right? E.g. if the artefact name is com.thisgreatcompanyiworkfor.app1_1.0-dev, will it do the right thing?
Comment 10 David Konecny 2010-08-08 22:31:53 UTC
(In reply to comment #9)
> Thanks, though it looks like the current fix is a heuristic which may or may
> not work, right? E.g. if the artefact name is
> com.thisgreatcompanyiworkfor.app1_1.0-dev, will it do the right thing?

It will work but in this case it will be slower because unrelated application will be returned by the query. The algorithm does initial query and then compare results against full module name so everything will work correctly (or at least that's how I understood - Vince can confirm).

So for com.thisgreatcompanyiworkfor.app1_1.0-dev the query would be *.thisgreatcompanyiworkfor.* which could return for example
* com.thisgreatcompanyiworkfor.app1_1.0-dev
* com.thisgreatcompanyiworkfor.foo.1
* com.thisgreatcompanyiworkfor.bar.2
but later they would be ignored because another test for full module name is done.