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.
After configuration transport-guarantee to INTEGRAL value, when select to run the application, the invoked browser does not run with SSL. STEPS TO REPRODUCE: 1. Install Nebean IDE 5.5 - build 6/30 2. Install AppServer 9 PE 3. Install javaee5tutorial package 4. Open ..\javaeetutorial5\examples\jaxws\helloservice-basicauth project 5. Right click at the helloservice-basicauth project, select properties and enter /hello for the Relative URL field 6. Open web.xml file and change the Tranport Guarantee value from NONE to INTEGRAL 7. Save the file and run the project BUG: The application url was invoked on the broswer as: http://localhost:8080/helloservice/hello while it should be invoked as https://localhost:8181/helloservice/hello since Tranport Guarantee value is INTEGRAL, not NONE
-> sunappserv
Download location for tutorial???
http://java.sun.com/javaee/reference/tutorials/
can duplicate. As far as I can tell, this will need changes in the web project and the serverplugin api and implementation. The web project needs to check and see if the transport is INTEGRAL. It then needs to ask the server plugin for the https info somehow. Since the security constraint can be on resource collections, JSR-88's TargetModuleID.getWebUrl() doesn't have enough granularity. It looks like that is what is used currently.
Link to Java EE Code Samples & Applications http://java.sun.com/javaee/reference/code/index.jsp
org.netbeans.modules.j2ee.deployment.impl.projects.DeploymentTargetImpl uses TMID to create the URL that will be invoked to display the page. My best guess is the following: 1. extend J2eeModule with a method like boolean securedAccessRequired(String partialUrl) A web module would have to look at its DD (and annotations???) to determine if the partial url has some transport guarentees in place. 2. Extend Server Instance with a method like String securedAccessChannel(Protocol p) (where Protocol has some type of enum, for http and rmi-iiop [at least]) This method would return the https://machine-name:port-value that is correct. When DeploymentTargetImpl constructs the URL, it would need to replace part of the output of TMID.getWebUrl() with the return value from securedAccessChannel(HTTP)... so http://localhost:8080/webApplication1/integraltransport/page.html would become https://localhost:8181/webApplication1/integraltransport/page.html
This definitelly cannot be treated as a bug, changing this to enhancement. Vince, thanks for the evaluation.