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 81822 - View Servlet doesn't work on Glassfish
Summary: View Servlet doesn't work on Glassfish
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 9 (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Nitya Doraisamy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-03 16:00 UTC by Petr Pisl
Modified: 2006-08-11 20:11 UTC (History)
1 user (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 Petr Pisl 2006-08-03 16:00:09 UTC
Open the new web application wizard. As target server choose Sun Java System
Application Server and also change the Context Path. Then invoke action View
Servlet over the the index.jsp. The message "The View Servlet action cannot be
performed. You must run JSP page first". Even you run the JSP the view servlet
doesn't work too.

If you use Tomcat or JBoss as target server, then it works.
Comment 1 _ ludo 2006-08-03 16:52:29 UTC
Regression?
Comment 2 _ ludo 2006-08-03 17:05:32 UTC
cannot reproduce on my system...

Can you chheck if the app is deployed?
can you check if you see a 
DOMAINSDIR\domain1\generated\jsp\j2ee-modules\WEBAPPNAME

and 
 org/apache/jsp/index_jsp.java
file
on your system?
Comment 3 _ ludo 2006-08-03 17:10:03 UTC
Ho... I did not the context root...
So the API should not give context root, but the web project name in our case
which is used by the backend...

How can I get the project name from the context root???

Bug for you again?
Comment 4 _ ludo 2006-08-03 17:13:19 UTC
Equivalent to 61749

We do not have enought context: we need a project handle then to get if its an
EAR of not, then the project name etc...

*** This issue has been marked as a duplicate of 61749 ***
Comment 5 Sherold Dev 2006-08-04 09:16:01 UTC
Reopening...

Ludo, please do not mix these two issues. Issue 61749 is far more complex
problem when we do not even know how it should be solved from the user perspective.

This issues is on the other hand quite clear and can be fixed even with the
current API. Note that it works for all the other server plug-ins.

The context path parameter uniquely identifies the JSP page on the server for
which you want to see the servlet source code.

All you have to do is to look into the domain.xml file and find the web module
with the given context path... once you find the module it should be simple to
find the generated sources.
Comment 6 Petr Pisl 2006-08-04 13:01:30 UTC
I agree with Stepan. This issue is similar to issue #61749, but not exactly the
same. This issue is more visible and more users can run into it.
Comment 7 _ ludo 2006-08-04 15:19:16 UTC
API need:
need to know which EAR prject (or not is used for this given JSP file.
Need is not specific to AS.
Comment 8 _ ludo 2006-08-04 15:32:47 UTC
Your solution can work but it is not performant at all. The IDE has the info.
Alos jBoss plugin has similar bug.
Comment 9 Sherold Dev 2006-08-04 17:13:14 UTC
Please, keep this issue assigned to the proper component and do not reassign it
to the j2eeserver where it does not belong. If you like, you can test it on
Tomcat to see that it works.

Note that this issue is NOT about EARs, this one is about Web modules. 

And Yes, module name requirement is AS specific. JBoss, Tomcat or JOnAS needs
just the given context path. Btw, what exactly do you mean by module name for
the Web module?

> Alos jBoss plugin has similar bug.

It is not a similar bug, JBoss plug-in does not implement the FindJSPServlet
interface at all, but as I said, it would not require any API change.

If you insist that you cannot fix this issue until some new API is introduced,
you can file an API enhancement against the j2eeserver and make this issue
depend on it, but if you do so, please specify exactly all your requirements.
Comment 10 _ ludo 2006-08-11 18:52:55 UTC
Fixed is now there in the plugin.

The remaining issue is for EAR that the context root which is given is from the
web app and not from the content of application.xml.
So Nb needs to know  (and it does) if this web app is inside an enterprise
application or not, annd give the correct context root there for this EAR file
that contains the Web app and the JSPs...
The fix was mainly done by Nitya: Thanks...
Comment 11 Sherold Dev 2006-08-11 19:07:57 UTC
> Fixed is now there in the plugin.

Nitya, can you please attach the commit log and close this issue as fixed?

The problem with the EAR is far more complex and is tracked in issue 61749.