1. WEB项目部署，网页浏览器未响应问题
1、首先说您描述的信息内容不够，而且这个原因有很多种；
2、不论您用什么语音进行的开发，都需要有日志输出，可以通过日志输出查看一下是不是程序或者数据库的问题；
3、web部署不论是linux还是windows环境都要保证基础环境的可用性，请检查防火墙、网络、以及apache/nginx等服务的可用性；
4、至于问题中提到的死循环需要开发人员自己进行检测，系统资源可以通过top等命令查看或者联系运维同学。
2. linux测试服务器如何部署web项目
使用tomcat, nginx ,apache之类的app就可以部署web项目
如何部署可以参考相关app的官方文档。
3. 如何获取web应用的部署路径
在java中获得文件的路径在我们做上传文件操作时是不可避免的。
web 上运行
1:this.getClass().getClassLoader().getResource("/").getPath();
this.getClass().getClassLoader().getResource("").getPath(); 得到的是 ClassPath的绝对URI路径。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war/WEB-INF/classes/
System.getProperty("user.dir");
this.getClass().getClassLoader().getResource(".").getPath(); 得到的是 项目的绝对路径。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war
2:this.getClass().getResource("/").getPath();
this.getClass().getResource("").getPath(); 得到的是当前类 文件的URI目录。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war/WEB-INF/classes/com/jebel/helper/
this.getClass().getResource(".").getPath(); X 不 能运行
3:Thread.currentThread().getContextClassLoader().getResource("/").getPath()
Thread.currentThread().getContextClassLoader().getResource("").getPath() 得到的是 ClassPath的绝对URI路径。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war/WEB-INF/classes/
Thread.currentThread().getContextClassLoader().getResource(".").getPath() 得到的是 项目的绝对路径。
如：/D:/jboss-4.2.2.GA/server/default/deploy/hp.war
在本地运行中
1：this.getClass().getClassLoader().getResource("").getPath();
this.getClass().getClassLoader().getResource(".").getPath(); 得到的是 ClassPath的绝对URI路径。
如:/D:/myProjects/hp/WebRoot/WEB-INF/classes
this.getClass().getClassLoader().getResource(".").getPath(); X 不 能运行
2：this.getClass().getResource("").getPath();
this.getClass().getResource(".").getPath(); 得到的是当前类 文件的URI目录。
如：/D:/myProjects/hp/WebRoot/WEB-INF/classes/com/jebel/helper/
/D:/myProjects/hp/WebRoot/WEB-INF/classes/ 得到的是 ClassPath的绝对URI路径。
如:/D:/myProjects/hp/WebRoot/WEB-INF/classes
3：Thread.currentThread().getContextClassLoader().getResource(".").getPath()
Thread.currentThread().getContextClassLoader().getResource("").getPath() 得到的是 ClassPath的绝对URI路径。。
如:/D:/myProjects/hp/WebRoot/WEB-INF/classes
Thread.currentThread().getContextClassLoader().getResource("/").getPath() X 不 能运行
最后
在Web应用程序中，我们一般通过ServletContext.getRealPath（"/"）方法得到Web应用程序的根目录的绝对路径。
还有request.getContextPath(); 在Weblogic中要用request.getServletContext().getContextPath();但如果打包成war部署到Weblogic服务器，项目内部并没有文件结构的概念，用这种方式是始终得到null，获取不到路径，目前还没有找到具体的解决方案。
4. web站点部署是什么意思,
Web站点部署就是指将web项目部署到不同web服务器(tomcat或weblogic,tomcat是目前用的最多的一个客服服务器)上,在本地测试外网访问等可以直接访问,
5. Docker部署WEB 应用
1、环境：阿里云服务器
2、CentOS7系统
3、Docker成功部署
这里前提docker 已经成功部署啦，现有有一个简单的测试案例，在docker上部署一个应用从而访问web。
接下来让我们尝试使用 docker 构建一个 web 应用程序。
我们将在docker容器中运行一个 Python Flask 应用来运行一个web应用。
通过 -p 参数来设置一样的端口：
docker ps 查看正在运行的容器
容器内部的 5000 端口映射到我们本地主机的 5000 端口上。
这时我们可以通过浏览器访问WEB应用
发现 访问失败
指定外网端口为5000，
1. 本地测试能否打开测试页
本地没有问题。
2. 浏览器中访问
在任意一台电脑上输入公网IP+端口号 (此端口号为运行WEB应用时指定的端口号5000) 如我的阿里云公网IP为123.11.11.11 此时在任意一台有网络的浏览器地址栏输入公网IP：http://123.11.11.11:5000 应该会出现测试页
但现在出现如下图所示：
显示打不开
查啦大量资料，以前曾经也解决过，一定弄明白自已购买的地区后，再去设置安全组的配置规则。
***1. 登录阿里云管理控制台****
2.找到云服务器ECS-概览
5. 手动添加端口5000
6. 最后保存，再从浏览器地址栏输入公网IP加端口号5000成功显示测试页如图：
6. 如何部署python web程序
Python Web 程序的部署方案
综合而言, 高性能的Python web站点部署方式首推 nginx + uwsgi
apache + mod_wsgi 是简单稳定但性能一般的方式
API服务器 可以直接使用tornado或者gevent
mod_python
非常原始的cgi模式部署python已经没有什么好介绍了。对于不太追求性能的管理系统和网站来说，使用 Apache 部署是一个不错的选择。较早的时候，使用 mode_python 部署python的web应用十分流行,在Django 0.96 的时候官方文档甚至推荐这种方式。
它将Python解释器嵌入到Apache server,以提供一个访问Apache server内部的接口。mod_python 在现在看来性能是不佳的，每一个http请求 mod_python 都会由一个进程初始化python解释器、载入代码、执行、然后销毁进程。
mod_wsgi
如果非要用Apache来部署python应用，mod_wsgi是一个更好的选择。WSGI 全称是 Web Server Gateway Interface ,由 PEP-333 定义。 基本上所有的python web框架都实现了wsgi接口，用mod_wsgi 能部署任何实现了wsgi的框架。实际上，不需要任何框架也可以用mod_wsgi 部署python程序。使用mod_wsgi的daemon模式，python程序会常驻内存，不会有很大的初始化和销毁进程方面的开销，所以性能是好于mod_python的。综合来说，使用Apache部署python web程序，推荐使用mod_wsgi的daemon模式。
Fastcgi
先说观点：不建议用fastcgi的方式部署Python web。
前几年由于lighttpd风头正劲和豆瓣的成功案例，fastcgi是一种很流行的部署方式。fastcgi与具体语言无关，也与web服务器无关。是一种通用的部署方式。fastcgi是对于cgi的增强，CGI程序运行在独立的进程中，并对每个Web请求建立一个进程。面对大量请求，进程的大量建立和消亡使操作系统性能大大下降。
与为每个请求创建一个新的进程不同，FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI服务器管理，而不是web服务器。 当进来一个请求时，web服务器把环境变量和这个页面请求通过一个socket比如FastCGI进程与web服务器都位于本地）或者一个TCP connection（FastCGI进程在远端的server farm）传递给FastCGI进程。
主流的web服务器，Apache,lighttpd,nginx 都支持fastcgi，在几年前，lighttpd的mod_fcgi模块性能强劲，lighttpd+fastcgi十分流行。无论是python,ruby还是php，都有大量的站点使用这种方式部署。由于nginx的崛起，现在很少有人使用lighttpd了。
fastcgi 并不是专门为python设计，并不是所有的python框架天然的支持fastcgi，通常需要flup这样的容器来配适。flup由python编写，和专门的c实现的wsgi容器比起来性能显得相当不堪。fastcgi的稳定性对于新兴的wsgi容器来说也有差距。无论从哪个方面来看，部署python web程序，fastcgi 都已经是过去式。
uwsgi
前几年nginx还未内置uwsgi模块的时候，部署uwsgi还是一件挺麻烦的事情。随着能够在nginx中直接使用uwsgi模块，uwsgi已经是最可靠，最方便的高性能python web程序的部署方式了。
在1U的四核XEON服务器上，一个简单的wsgi handler甚至能用AB压到8000以上的qps,这已经是完爆tornado,接近gevent的性能了。 同时，uwsgi的稳定性极好。之前我们有个每天500w-1000w动态请求的站点使用uwsgi部署非常稳定，在一个渣HP 1U 服务器上，基本不用管它。
上面提到的部署方式都是相对于web网站的方式，在移动互联网的时代，我们需要的是高性能的API服务，上面这些都是过时的东西。
tornado
tornado 号称高性能，如果拿他写网站，其实一般般，只不过跟uwsgi加一些简单框架差不多而已。它真正的作用，是用来写API服务器和长连接的服务器。
由于tornado能够直接处理http请求，很多人直接拿他来裸奔直接提供服务。这种方式是不可取的，单线程的tornado只能利用cpu的一个核心，并且一旦阻塞直接就废了。通常情况下，由supervisor启动多个tornado进程，通过nginx进行反向代理负载均衡。nginx 1.14 以后的版本反向代理支持长连接，配合tornado的comet效果很好。
tornado还有一些比较奇葩的用法，比如用来做wsgi容器之类的。
gevent
gevent是一个神器，能做的事情很多。在web方面，处理http请求，用起来其实跟tornado差不多，但是要简陋很多，cookie之类的都没有。用gevent写的一些API服务，部署方式还是类似tornado，用supervisor管理多个守护进程，通过nginx做负载均衡。 同样的它的奇葩用法也和tornado一样，可以当wsgi容器用。
7. Web 部署任务失败
直接输入localhost:8080/sms这个有反应吗，如果有的话那说明项目部署成功，如果没反应说明项目部署失败，你需要查看日志看看项目到底部署成功没有。
查看log下面的catalina.log这个文件，看看有没有error
8. eclipse中tomcat如何识别是否为web工程的，并根据什么判断是否能部署到tomcat服务器上的
java吧11级大神!!!
膜拜膜拜..
不了解 但是知道可以搜
maven部署到tomcat 用eclipse自动部署要配置pom.xml,setting.xml还要给tomcat配置用户 eclipse直接新建要插件吧
以前看过一点 一直没学maven
大神可以去看看csdn和新浪的博客 网络一下maven部署tomcat
最后javaProject 和 Dynamic Web Project
新建动态web项目的时候 在eclipse的服务器项目中的server.xml中 已经添加了项目信息 然后eclipse再将改项目加载到eclipse下的tomcat工作空间下的
而普通项目则不会