initialcontextejb上启动时有警告，WARN [SessionFactoryObjectFactory] InitialContext did not implement EventContext

InitialContext()是什么意思

InitialContext()是可以加载配置文件的（jndi.properties)，构造方法也可以带参数的（见API），以下是我的看法，它的初始化是由容器来（系统内部）来完成的,如果你的客户端和服务器都在一台机子上且同一个JVM，那么Context namingContext = new InitialContext();是没问题，如果你的服务器端在另一台机器上，想想也知道，肯定要配置个IP的，对于JNDI的编程都是先注册资源（数据库连接，EJB等），然后再用，这样的原则的，我在EJB3，也同样用到InitialContext（）我想道理是相同的，以下是jnid.properties的配置文件（EJB）.jnp.interfaces.NamingContextFactory .jnp.interfaces java.naming.provider.url=localhost:1099 --------------------------------------------------------------------------------

Tomcat中Context是什么用的

Context元素代表一个web应用，运行在某个特定的虚拟主机上。

如Servlet Specification 2.2或以后版本中描述的那样，每个web应用基于一个Web Application Archive(WAR)文件，或者是一个目录，包含WAR文件解压后的内容。

有关Web Application Archive的更多信息，可以参考Servlet Specification和Tomcat 应用程序开发者指南。

通过将请求URI的最长可能前缀与每个Context的context路径进行匹配，Catalina选择相应的web 应用处理HTTP请求。

一旦选定，根据web application deployment descriptor 文件中定义的servlet映射，Context会选择一个正确的servlet来处理进来的请求。

servlet映射必须定义在该web应用目录层次结构中的/WEB-INF/web.xml中。

你可以在一个Host元素中嵌套任意多的Context元素。

每个Context的路径必须是惟一的，由path属性定义。

另外，你必须定义一个context路径长度为0的Context，这个Context称为该虚拟主机的缺省web应用，用来处理那些不能匹配任何Context的Context路径的请求。

除了在Host元素中嵌套Context元素以外，你也可以将它们存储在单个文件中（以.xml为后缀），放在$CATALINA_HOME/conf/[enginename]/[hostname]/目录下面。

有关这方面的更多信息，参考应用的自动发布。

这种方法允许动态重新配置web应用，因为如果修改了conf/server.xml，就必须重新启动Tomcat。

除了明确指定Context元素以外，还有其他几种技术可以自动生成Context元素。

参考Automatic Application Deployment 和 User Web Applications 以下的描述使用变量$CATALINA_HOME来指Tomcat 5安装的目录。

大多数的相对路径都是以该目录为基准。

但是，通过设置CATALINA_BASE目录，可以运行多个Tomcat 5实例，这时你应该使用$CATALINA_BASE来作为目录基准，而不是使用$CATALINA_HOME。

属性 通用属性 所有Context的实现支持如下属性： backgroundProcessorDelay 这个值代表在context及其子容器（包括所有的wrappers）上调用backgroundProcess方法的延时，以秒为单位。

如果延时值非负，子容器不会被调用，也就是说子容器使用自己的处理线程。

如果该值为正，会创建一个新的线程。

在等待指定的时间以后，该线程在主机及其 子容器上调用backgroundProcess方法。

context利用后台处理session过期，监测类的变化用于重新载入。

如果没有指定，该属性的缺省值是－1，说明context依赖其所属的Host的后台处理。

className 实现的Java类名。

该类必须实.apache.catalina.Context接口。

如果没有指定，使用标准实现（在下面定义）。

cookies 如果想利用cookies来传递session identifier（需要客户端支持cookies），设为ture。

否则为false，这种情况下只能依靠URL Rewriting传递session identifier。

crossContext 如果想在应用内调用ServletContext.getContext()来返回在该虚拟主机上运行的其他web application的request dispatcher,设为true。

在安全性很重要的环境中，设为false，使得getContext()总是返回null。

缺省值为false。

docBase 该web应用的文档基准目录（Document Base，也称为Context Root），或者是WAR文件的路径。

可以使用绝对路径，也可以使用相对于context所属的Host的appBase路径。

override 如果想利用该Context元素中的设置覆盖DefaultContext中相应的设置，设为true。

缺省情况下使用DefaultContext中的设置。

privileged 设为true，允许context使用container servlets，比如manager servlet。

path web应用的context路径。

catalina将每个URL的起始和context path进行比较，选择合适的web应用处理该请求。

特定Host下的context path必须是惟一的。

如果context path为空字符串（""），这个context是所属Host的缺省web应用,用来处理不能匹配任何context path的请求。

reloadable 如果希望Catalina监视/WEB-INF/classes/和/WEB-INF/lib下面的类是否发生变化，在发生变化的时候自动重载web application，设为true。

这个特征在开发阶段很有用，但也大大增加了服务器的开销。

因此，在发布以后，不推荐使用。

但是，你可以使用Manager应用在必要的时候触发应用的重载。

.apache.catalina.Wrapper实现类的名称，用于该Context管理的servlets。

如果没有指定，使用标准的缺省值。

标准实现 Context的标准实现.apache.catalina.core.StandardContext.它还支持如下的附加属性： 属性 描述 debug 与这个Engine关联的Logger记录的调试信息的详细程度。

数字越大，输出越详细。

如果没有指定，缺省为0。

swallowOutput 如果该值为true，System.out和System.err的输出被重定向到web应用的logger。

如果没有指定，缺省值为false useNaming 如果希望Catalina为该web应用使能一个JNDI InitialContext对象，设为true。

该InitialialContext符合J2EE平台的约定，缺省值为true。

workDir Context提供的临时目录的路径，用于servlet的临时读/写。

利用javax.servlet.context.tempdir属性，servlet可以访问该目录。

如果没有指定，使用$CATALINA_HOME/work下一个合适的目录。

嵌套组件 下列元素可以嵌套在Context元素中，但每个元素至多只能嵌套一次。

Loader－配置该web应用用来加载servlet和javabean的类加载器。

正常情况下，使用缺省的类加载器就足够了； Logger - 配置用来接收和处理所有日志消息的logger，包括调用ServletContext.log()函数记录的所有消息； Manager -配置用于创建，销毁，维持HTTP session的session manager.正常情况下，使用缺省的session manager配置就足够了； Realm - 配置Realm，该Realm的用户数据库以及相关的角色仅用于这个特定的web应用中。

如果没有指定，该web应用使用所属的Host或Engine的Realm。

Resources - 配置用于访问与这个web应用相关联的静态资源。

正常情况下，使用缺省的resource manager就足够了。

专有特征 访问日志 正常情况下，运行web服务器会生成访问日志。

访问日志以标准格式为每个请求输出一行信息。

Catalina包含一个可选的Valve实现，可以用标准格式生成日志,还可以使用任意定制的格式。

通过在Engine，Host或者Context中嵌套一个Valve元素，Catalina会为该容器处理的所有请求创建访问日志，如下所示： <Context path="/examples" ...> ... <Valve className=&essLogValve" prefix="localhost_ess_log." suffix=".txt" pattern=&mon"/> ... </Context> 参考ess Log Valve，以获得更多配置属性的信息； Context的自动配置 如果使用标准的Context实现，当Catalina启动，或者重载web应用的时候，如下的配置步骤会自动发生，不需要特殊的配置来使能这个特征。

如果没有定义自己的Loader元素，将会配置一个标准的web应用class loader； 如果没有定义自己的Manager元素，会配置一个标准的session manager； 如果没有定义自己的Resources元素，使用标准的resource manager。

在conf/web.xml中列出的web应用的属性会当做该web应用的缺省的属性。

这被用于建立缺省的映射（比如将.jsp映射成对应的JSP servlet），以及其他的标准属性。

列举在/WEB-INF/web.xml资源中的属性被处理（如果资源存在）； 如果web应用指定了安全限制，并且可能需要对用户进行认证，Catalina会配置选定的Authenticator，该Authenticator实现了login方法。

Context参数 可以在Context中元素中嵌套<Parameter>元素，配置带有名称的值，这些值作为servletcontext初始化参数，对整个web应用可见。

比如，你可以像这样创建初始化参数: <Context ...> ... <Parameter name=&panyName" value="My Company, Incorporated" override="false"/> ... </Context> 这与在/WEB-INF/web.xml中包含如下元素相等： <context-param> <param-name&panyName</param-name> <param-value>My Company, Incorporated</param-value> </context-param> 区别是，前者不需要修改deployment descriptor来定制这个值。

<Parameter>元素的有效属性值如下： 属性 描述 description 关于该context初始化参数的文字描述（可选） name 要创建的context初始化参数的名称 override 如果不希望/WEB-INF/web.xml中具有相同参数名称的<context-param>覆盖这里指定的值，设为false。

缺省值为true。

value 调用ServletContext.getInitParameter()时，返回给应用的参数值。

环境条目 可以在Context中嵌套<Environment>元素，配置命名的值，这些值作为环境条目资源(Environment Entry Resource），对整个web应用可见。

比如，可以按照如下方法创建一个环境条目： <Context ...> ... <Environment name="maxExemptions" value="10" type="java.lang.Integer" override="false"/> ... </Context> 这与在/WEB-INF/web.xml中包含如下元素是等价的： <env-entry> <env-entry-name>maxExemptions</param-name> <env-entry-value>10</env-entry-value> <env-entry-type>java.lang.Integer</env-entry-type> </env-entry> 区别是，前者不需要修改deployment descriptor来定制这个值。

<Environment>元素的有效属性所如下： 属性 描述 description 环境条目的文字描述（可选） name 环境条目的名称，相对于p/env context。

override 如果不希望/WEB-INF/web.xml中具有相同名称的<env-entry>覆盖这里指定的值，设为false。

缺省值为true。

type 环境条目的Java类名的全称.在/WEB-INF/web.xml中，<env-entry-type>必须是如下的值：java.lang.Boolean, java.lang.Byte, java.lang.Character, java.lang.Double, java.lang.Float, java.lang.Integer, java.lang.Long, java.lang.Short, or java.lang.String. value 通过JNDI context请求时，返回给应用的参数值。

这个值必须转换成type属性定义的Java类型 生命期Listeners 如果一个Java对象需要知道Context什么时候启动，什么时候停止，可以在这个对象中嵌套一个Listener元素。

该Listener元素必须实现.apache.catalina.LifecycleListener接口，在发生对应的生命期事件的时候，通知该Listener。

可以按照如下的格式配置这样的Listener： <Context path="/examples" ...> ... <Listener className=&pany.mypackage.MyListener" ... > ... </Context> 注意，一个listener可以具有任意多的附加属性。

属性名与JavaBean的属性名相对应，使用标准的属性命名方法。

请求过滤器（Request Filters） 对每个发送到Engine，Host或者Context的请求，可以要求Catalina检查IP地址或主机名称。

Catalina使用一系列配置好的“接受”或者“拒绝”过滤器对客户端的地址或者主机名进行检查，过滤器是按照正则表达式语法定义的，由Jakarta Regexp正则表达式库支持。

不被接受的请求会返回一个HTTP“Forbidden”错误。

下面是过滤器的定义。

<Context path="/examples" ...> ... <Valve className=&.apache.catalina.valves.RemoteHostValve" allow="*,"/> <Valve className=&.apache.catalina.valves.RemoteAddrValve" deny="192.168.1.*"/> ... </Context> 资源定义（Resource Definitions） 可以在/WEB-INF/web.xml中定义资源的特性。

使用JNDI查找<resource-ref>和<resource-env-ref>元素时，这些特性被返回。

对同一资源名称，还必须定义资源参数（见下面“资源参数”小节），这些参数用来配置对象工厂（object factory）以及对象工厂的属性。

比如，你可以按照如下方式创建资源定义： <Context ...> ... <Resource name="jdbc/EmployeeDB" auth="Container" type="javax.sql.DataSource" description="Employees Database for HR Applications"/> ... </Context> 这等价于在/WEB-INF/web.xml中包含如下元素： <resource-ref> <description>Employees Database for HR Applications</description> <res-ref-name>jdbc/EmployeeDB</res-ref-name> <res-ref-type>javax.sql.DataSource</res-ref-type> <res-auth>Container</res-auth> </resource-ref> 区别是，前者不需要修改deployment descriptor来定制这个值。

<Resource>元素的有效属性如下： 属性 描述 auth 指定时web应用代码本身sign on到对应的resource mananger，还是由container代表web应用sign on到resource manager。

该属性的值必须是Application或者Container。

如果在web application deployment descriptor中使用<resource-ref>，这个属性是必需的，如果使用<resource-env-ref>，这个属性是可选的。

description 资源的文字描述（可选） name 资源的名称，相对于p/env context scope 指定通过这个resource manager得到的连接是否共享。

该属性的值必须是Shareable或者Unshareable。

缺省情况下，假定连接是共享的。

type 当web应用查找该资源的时候，返回的Java类名的全称。

资源参数 资源参数用来配置资源管理器（resource manager，或对象工厂,object factory）。

在做JNDI查找时，资源管理器返回查找的对象。

在资源可以被访问之前，对<Context>或<DefaultContext>元素的每个<Resource>元素，或者/WEB-INF/web.xml中定义的每个<resource-ref>或<resource-env-ref>元素，都必须定义资源参数。

资源参数是用名称定义的，使用的资源管理器（或者object factory）不同，参数名称的集合也不一样。

这些参数名和工厂类的JavaBeans属性相对应。

JNDI实现通过调用对应的JavaBeans属性设置函数来配置特定的工厂类，然后通过lookup()调用使得该实例可见。

一个JDBC数据源的资源参数可以按照如下方式定义： <Context ...> ... <ResourceParams name="jdbc/EmployeeDB"> <parameter> <name>driverClassName</name> <value&.hsql.jdbcDriver</value> </parameter> <parameter> <name>url</name> </value>jdbc:HypersonicSQL:database</value> </parameter> <parameter> <name>user</name> <value>dbusername</value> </parameter> <parameter> <name>password</name> <value>dbpassword</value> </parameter> </ResourceParams> ... </Context> 如果你需要为某个特定的资源类型指定工厂内的Java类名，在<ResourceParams>元素中嵌套一个叫做factory的<parameter>条目。

<Resourceparams>元素的有效属性如下： 属性 描述 name 配置的资源名称，相对于p/env context。

这个名称必须与$CATALINA_HOME/conf/server.xml中某个<Resource>元素定义的资源名称匹配，或者在/WEB-INF/web.xml中通过<resource-ref>或者<resource-env-ref>元素应用。

资源连接（Resource Links） 资源连接用于创建到全局JNDI资源的连接。

在连接名称上进行JNDI查询会返回被连接的global 资源。

比如，你可以按照如下方法创建一个资源连接： <Context ...> ... <ResourceLink name="linkToGlobalResource" global="simpleValue" type="java.lang.Integer" ... </Context> <ResourceLink>元素的有效属性如下： 属性 描述 global 被连接的连接全局资源的名称 name 创建的资源连接的名称，相对于p/env context type 当web应用在该资源连接上进行查找时，返回的Java类名的全称 ------------------------------------------------------------ 梦里，无法抵挡你嫣然的笑语,无法抵挡你含情的双眸； 醒来，更是无法抵挡对你的眷恋,一生别无所求，唯愿拥有你.... 银河为证，我们相知，相恋，直到永远...... SQLdeclare type etype is table of emp.ename%type index by binary_integer; e1 etype; begin select ename bulk collect into e1 from emp; dbms_output.put_line(e1.count); for i in 1..e1.count loop dbms_output.put_line(e1(i)); end loop; end;

jsp Context 属于哪个包

这个context是jndi的内容，不是一两句话能解释清楚的。

你可以查一下jndi的相关资料，不难理解。

至于lookup方法中的jdbc/sqlserver是在tomcat的server.xml的配置,lookup的作用就是检索出这些配置。

enodeb为什么不在initial context setup response的时候 teid

控制包数据上面有initialcontextsetuprequest信令，这条信令（通过S1AP协议）是MME将S-GW的ip地址和TEID发送给ENodeB，这时，上行数据就可以从ENodeb发往S-GW；另外还有initialcontextsetupresponse信令，这条信令（通过S1AP协议）是ENodeB将自身的ip地址和TEID发送给MME；接下来ModifyBearerRequest信令，这条信令（通过GTPv2协议）是MME将eNodeB的ip地址和TEID发送给S-GW，并要求S-GW进行EPS承载，这时S-GW就可以向UE发送下行数据了。

ejb上启动时有警告，WARN [SessionFactoryObjectFactory] InitialContext did not implement EventContext

这个session factory 是指的Hibernate 吗？ 1,你用到的像 hibernate 这些 jar 是分散放置在几个地方吗？ 2,你能确认这个Hibernate 版本是正确的吗？ 这个问题可能有两个方面： 1,Hibernate 版本与某个第三方jar 版本不一致。

2,第三方jar 分散在几个地方导致类路径层次错误。