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.
Create Enteprise Application containing EJB Module and Web Application. Run the EAR. Invoke action 'View Servlet' on index.jsp. Error message says that I had to run JSP first, but I run whole EAR. If I undeploy EAR and run only Web Application it works.
Similar is happening to me. I have a J2EE app. I deploy just the webapp to SJS. The server is already running in debug mode. I right click JSP and try view servlet. The same thing happens. "The view servlet action cannot be performed. You must run JSP page first" Meanwhile, I'm able to repeatedly hit F5 on my browser and witness the page "running". Even attachning to the process, I still cannot view the servlet.
The problem is in org.netbeans.modules.j2ee.sun.ide.j2ee.jsps.FindJSPServletImpl class where in the method getServletTempDirectory is hardcoded File hostBase = new File(domainDir, "/"+domain+"/generated/jsp/j2ee-modules".replace('/', File.separatorChar)); In the case of ear application it should be different. Something like: File hostBase = new File(domainDir, "/"+domain+"/generated/jsp/j2ee-apps"+earprojectname.replace('/', File.separatorChar));
Still is reproducible in NetBeans 5.5 and as I wrote before there has to be check , whether its standalone web module or module inside ear application.
What is the api to check if we are in a web app or an ear app?
org.netbeans.modules.j2ee.deployment.plugins.api FindJSPServlet API : public File getServletTempDirectory(String moduleContextPath) does not give the web app or ear project name, so this cannot be done with the curretnt API. Moving to J2eeserver module for a better API to fix this. So far, it is too web centric.
Petr or Stepan, any ideas?
I think, it can be fixed for 5.5 without the api change. On the other hand, the change should be easy, but probably influence all server plugins. Stepan what do you think?
TM -> 5.5. The API change is not that straitforward as it might appear. Here is a list of problems that must be solved before making any API change * Glassfish uses archive name as a part of the generated servlet path unlike JBoss or JOnAS which uses context path (the one from the application.xml). How should look the signature of the new method? * If a web app is deployed as part of an EAR and also as a standalone module at the same time what servlet should be displayed - the one generated for the standalone module or for the EAR? * What if a web module is part of two EARs. What servlet should be displayed? How might the user influence this? Please note that the web module and the EAR (or the two EARs) can be targeted to different servers and thus the generated servlets might differ. BTW, I don't think that the current API even allows to find out about the module part of which EAR(s) it is.
Can you elaborate "I think, it can be fixed for 5.5 without the api change" ? I am interested.
Yesterday I was thinking about a hack, something like: If there is not appropriate folder (I thought that the folder name is context path) under generated/jsp/j2ee-modules/ we should look in all enterprise applications under generated/jsp/j2ee-apps and use the first web application, which has the same context path. But today I have realized that the name of folder is not context path of the web application, but probably the name of the war file. And there are next obstacles that were mentioned by Stepan. So probably for NetBeans 5.5 should be fixed at least the messsage, which is displayed, when the servlet is not available and should be documented.
*** Issue 81822 has been marked as a duplicate of this issue. ***
http://www.netbeans.org/issues/show_bug.cgi?id=81822 was a P2 bug and is related to this one. Same P2 also for jBoss plugin. So bumping this one as P2 as well.
Changing the priority back to P3. You cannot increase priority of some issue only because the issue is somehow related to some other issue with higher priority. P2 issue 81822 and issue 81948 are bugs without any doubt, since the web module 'View Servlet' action simply does not work as it was meant to work. This issue, however, is different, one could almost consider it an enhancement and it is not clear how it should work from the user perspective, as mentioned above. Lets consider this situation, you have a web module targeted to Tomcat and this module is also part of an EAR project targeted to Glassfish. Then you will invoke the 'View servlet' action, what the user wants to see? Tomcat or Glassfish version of the generated servlet? All I wanted to show on this example is that this issue is not really about fixing the current feature but more about enhancing it.
I agree "related" does not mean "same". It's an issue in the same area, but not the same thing. Definitely a P3, see also the bug priority criteria: http://qa.netbeans.org/bugzilla/bug_priority_guidelines.html "Part of a product feature is affected, a viable workaround exists"
The issue still exist, tm -> 6.0
I filed http://www.netbeans.org/issues/show_bug.cgi?id=121846 against the GF plugin and then found out that this issue has been known for a long time... I wish somebody had mentioned it... I would assume that the other server plugins could fix this issue in their code...
none of these TM values are valid at this point
I guess this needs to get set back to TBD since no one is assigned to work on it.
there is still the issue in 6.9, but first I got issue #186366 and after restart View Servlet just do nothing(no dialog), but may be new one blocking issue can be filed. also initial issue itself may not be an issue in my opinion.
Nobody seems to be really interested in this issue. Also see the last comment "also initial issue itself may not be an issue in my opinion".