精华内容
下载资源
问答
  • java web上下文理解

    万次阅读 多人点赞 2018-03-01 17:34:55
    web上下文可以看成web应用的运行环境,一般用context名字来修饰,里面保存了web应用相关的一些设置和全局变量2.ServletContext,是一全局的储存信息的空间,服务器开始,其就存在,服务器关闭,其才释放。...

    1.context就是“容器”,放的就是应用程序的所有资源,要用时候就访问它,所以context里面的东西,在同一个应用程序里面是全局的;web上下文可以看成web应用的运行环境,一般用context名字来修饰,里面保存了web应用相关的一些设置和全局变量

    2.ServletContext,是一个全局的储存信息的空间,服务器开始,其就存在,服务器关闭,其才释放。request,一个用户可有多个;session,一个用户一个;而servletContext,所有用户共用一个。所以,为了节省空间,提高效率,ServletContext中,要放必须的、重要的、所有用户需要共享的线程又是安全的一些信息;

    HttpSession session =request.getSession();
    session.getServletContext();

    3.avaWeb中的上下文环境概念就是:一个web服务启动后的整个服务中的所有内存对象和他们之间的关系组成的一种环境

    spring 上下文和spring mvc上下文和web应用上下文servletContext之间的关系

    要想很好理解这三个上下文的关系,需要先熟悉spring是怎样在web容器中启动起来的。spring的启动过程其实就是其IoC容器的启动过程,对于web程序,IoC容器启动过程即是建立上下文的过程。

    spring的启动过程:

    1. 首先,对于一个web应用,其部署在web容器中,web容器提供其一个全局的上下文环境,这个上下文就是ServletContext,其为后面的spring IoC容器提供宿主环境;

    2. 其次,在web.xml中会提供有contextLoaderListener。在web容器启动时,会触发容器初始化事件,此时contextLoaderListener会监听到这个事件,其contextInitialized方法会被调用,在这个方法中,spring会初始化一个启动上下文,这个上下文被称为根上下文,即WebApplicationContext,这是一个接口类,确切的说,其实际的实现类是XmlWebApplicationContext。这个就是spring的IoC容器,其对应的Bean定义的配置由web.xml中的context-param标签指定。在这个IoC容器初始化完毕后,spring以WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE为属性Key,将其存储到ServletContext中,便于获取;

    3. 再次,contextLoaderListener监听器初始化完毕后,开始初始化web.xml中配置的Servlet,这个servlet可以配置多个,以最常见的DispatcherServlet为例,这个servlet实际上是一个标准的前端控制器,用以转发、匹配、处理每个servlet请求。DispatcherServlet上下文在初始化的时候会建立自己的IoC上下文,用以持有spring mvc相关的bean。在建立DispatcherServlet自己的IoC上下文时,会利用WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE先从ServletContext中获取之前的根上下文(即WebApplicationContext)作为自己上下文的parent上下文。有了这个parent上下文之后,再初始化自己持有的上下文。这个DispatcherServlet初始化自己上下文的工作在其initStrategies方法中可以看到,大概的工作就是初始化处理器映射、视图解析等。这个servlet自己持有的上下文默认实现类也是mlWebApplicationContext。初始化完毕后,spring以与servlet的名字相关(此处不是简单的以servlet名为Key,而是通过一些转换,具体可自行查看源码)的属性为属性Key,也将其存到ServletContext中,以便后续使用。这样每个servlet就持有自己的上下文,即拥有自己独立的bean空间,同时各个servlet共享相同的bean,即根上下文(第2步中初始化的上下文)定义的那些bean。

    servletContext 是web应用程序的大环境,用于存储整个web应用程序级别的对象.

    Spring上下文(ApplicationContext)
    方法一:ClassPathXmlApplicationContext --从classpath路径加载配置文件,创建Bean对象
    ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:applicationContext.xml");
    ClassName clazz =(ClassName)ctx.getBean("beanName");
    
    方法二:FileSystemXmlApplicationContext  --从指定的目录中加载
    ApplicationContext ctx = new FileSystemXmlApplicationContext("src/applicationContext.xml");
    ClassName clazz =(ClassName)ctx.getBean("beanName");
    
    方法三:Spring提供的工具类WebApplicationContextUtils获取ApplicationContext对象(通过ServletContext对象获得ApplicationContext对象,然后根据它获得需要的类实例)
    HttpSession session =request.getSession();
    ServletContext context = session.getServletContext(); //arg0.getSession().getServletContext();
    ApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(context);
    ClassName clazz =(ClassName)ctx.getBean("beanName");
    
    上面两个工具方式的区别是,前者在获取失败时抛出异常,后者返回null。
    
    方法四:继承自抽象类ApplicationObjectSupport
    说明:抽象类ApplicationObjectSupport提供getApplicationContext()方法,可以方便的获取到ApplicationContext。
    Spring初始化时,会通过该抽象类的setApplicationContext(ApplicationContext context)方法将ApplicationContext 对象注入。
    
    例如:
    import org.springframework.context.support.ApplicationObjectSupport;
    
    public class ContextOne extends ApplicationObjectSupport
    {
        ......
    }
    ........
    ContextOne one = new ContextOne();
      one.getApplicationContext();
    
    
    方法五:继承自抽象类WebApplicationObjectSupport
    说明:类似上面方法,调用getWebApplicationContext()获取WebApplicationContext
    
    例如:
    import org.springframework.web.context.support.WebApplicationObjectSupport;
    public class ContextOne extends WebApplicationObjectSupport {
        .......
    }
    ........
    ContextOne one = new ContextOne();
      one.getApplicationContext();
    
    
    方法六:实现接口ApplicationContextAware
    http://blog.csdn.net/kaiwii/article/details/6872642
    当一个类实现了ApplicationContextAware接口后,这个类就可以获得Spring配置文件中的所引用到的bean对象。
    说明:实现该接口的setApplicationContext(ApplicationContext context)方法,并保存ApplicationContext 对象。
    Spring初始化时,会通过该方法将ApplicationContext对象注入。
    
    例如:
    package com.auth.util;
    import org.springframework.beans.BeansException;
    import org.springframework.context.ApplicationContext;
    import org.springframework.context.ApplicationContextAware;
    //通过接口ApplicationContextAware获得spring上下文
    public class Context implements ApplicationContextAware {
     private static ApplicationContext ctx;
    //设置ApplicationContext对象
     public void setApplicationContext(ApplicationContext context)
       throws BeansException {
      // TODO Auto-generated method stub
       ctx=context;
     }
     //通过beanName获得实例
     public static Object getBean(String beanName)
     {
      return ctx.getBean(beanName);
     }
    }







    展开全文
  • 关于web应用上下文Context

    千次阅读 2015-07-31 11:51:28
    关于web应用上下文Context     很朋友都对Context不太了解,他们说"项目中没看到这对象啊""但是老是听人提起Context","经常看到ServletContext,PageContext.EJBContext, 还有Spring里面的...

    关于web应用上下文Context

     

     

    很多朋友都对Context不太了解,他们说"项目中没看到这个对象啊""但是老是听人提起Context","经常看到ServletContext,PageContext.EJBContext, 还有Spring里面的ApplicationContext等等"
    笔者总结了一些对Context的介绍,结合自己的理解,希望可以方便大家更好利用Context

    为了向SERVLET提供一个HTTP请求,又提供在运行时刻的请求的信息,容器将HTTP请求封装成JAVA对象,该对象也称为REQUEST,该对象也在其他对象中提供了类似剪贴版似的组件,不同的SERVLET通过它来交换信息,该组件被称为上下文。

    应用程序上下文是其中的对象对于应用程序的全部SERVLET使用。

    会话上下文其中的对象对于访问了用户的HTTPSESSION对象的SERVLET都可以使用,该HTTPSESSION通常通过调用HTTPREQUEST的方法,会话上下文会通过容器/SERVELT而失效。

    HTTP请求上下文,其中的对象对于处理该请求的全部SERVLET都可以使用,该HTTP请求可能从一个SERVLET转发另一个SERVLET,当一个SERVLET包含另一个SERVLET的时候,在HTTP请求上下文中请求也能共享页面上下文,对于当前的JSP而言,在该请求的生命周期中,该上下文可用,页面范围仅仅对JSP有效,对SERVLET无效。

    SERVELET上下文的另一种解释,JAVA的SERVLET可以在一系列被称为上下文的共享对象的存放对象,上下文中的名字都由一个相关联的对象组成,同一个应用程序中任何程序都可以从一个上下文中通过名字获得相关联的对象,一个应用程序中的SERVLET还经常需要在一个HTTP请求外来共享某些信息,因此为了管

    理这些对象的共享周期,容器提供了3个标准的上下文:应用程序上下文,HTTP请求上下文,会话上下文。一个页面范围内的上下文仅仅对一个页面有效。在页面范围内的对象不可能和其他JSP和SERVLET共享

    简单来说,Context就是一个存储器,把相关的东西存起来,可存可取.


    载自:http://blog.csdn.net/defonds/archive/2009/06/04/4241682.aspx

    展开全文
  • DDD—上下文映射图

    千次阅读 2019-11-17 16:34:22
    (1)比较容易的一种是画一个简单的框图来表示两个或多个限界上下文之间的映射关系。该框图表示了不同的限界上下文在解决方案空间中是如何通过集成相互关联的。 (2)另一种更详细的方式通过限界上下文集成的源代码...

    一个项目的上下文映射图(Context Map)可以用两种方式表示,
    (1)比较容易的一种是画一个简单的框图来表示两个或多个限界上下文之间的映射关系。该框图表示了不同的限界上下文在解决方案空间中是如何通过集成相互关联的。

    (2)另一种更详细的方式通过限界上下文集成的源代码实现来表示。

    1、上下文映射图为什么重要

    在开始采用DDD时,首先应该为你当前的项目绘制一个上下文映射图,其中应该包含你项目中当前的限界上下文和它们之间的集成关系。下图表示一个抽象的上下文映射图,后文将不断地向里面添加细节内容。

    在这里插入图片描述

    比如,当你为一个大型企业进行限界上下文之间的集成时,你可能需要与大泥球进行交互。大泥球的维护团队才不关心你的项目呢,因为你依赖于他们的API、因此,他们并不会深入到你的上下文映射图中,然而你的映射图依然需要反映出和他们的集成关系,因为这样可以使你了解到映射图的内部,并且可以指明在哪些地方需要与其他团队进行交流。这样对你团队的成功是有帮助的。

    假定你期望大泥球维护团队提供一套新的API。然而,他们并不打算这样做。此时你的团队和大泥球的维护团队的关系便成了客户方-供应方的关系。由于大泥球团队决定维持现状,你的团队不得不陷入一种遵奉者关系中。尽早绘制上下文映射图,这样可以迫使呢仔细思考你的项目和你所依赖项目之间的关系。

    CollabOvation团队应该在建模之初就使用上下文映射图,然而当时他们对于战略建模一无所知。后来,通过经验积累,在之后的ProjectOvation中,尝到了建模的甜头。

    上下文映射图表现的是项目当前的状态,如果项目发生变化,你可以更新上下文映射图。注意上下文映射图不需要画得太正式了,手绘即可。

    2、产品和组织关系

    这一节主要重复下,整个专栏的案例说明,详情见:DDD案例说明。

    SaaSOvation公司正在开发的3个产品:

    1、CollabOvation——一款社交协作软件。该产品允许注册用户发布对业务有价值的内容,发布方式是一些流行的基于Web的工具,比如论坛、共享日历、博客和wiki等。这是SaaSOvation公司的旗舰产品,也是该公司的第一个核心域。开发团队后来从CollabOvation中提取了IdOvation模型。对于CollabOvation来说,IdOvation是一个通用子域,而CollabOvation本身又作为ProjectOvation的支撑子域。

    2、IdOvation——一款可重用的身份和访问管理产品。IdOvation为注册用户提供安全的、基于角色的访问管理。这些功能一开始和CollabOvation混合在一起,这样导致的问题是:实现受到了限制,功能不可重用。SaaSOvation对CollabOvation进行了重构,引入了一个新的、结构清晰的限界上下文。SaaSOvation公司决定支持多个租户,这种功能对于SaaS产品来说是至关重要的。对于消费方来说,IdOvation扮演着通用子域的角色。

    3、ProjectOvation——一个敏捷项目管理产品。这是SaaSOvation公司的核心域。ProjectOvation采用基于Scrum的项目运行框架,用户可以创建项目管理资产,同时对项目资产进行分析和设计,还能跟踪项目进度。和CollabOvation一样,ProjectOvation将IdOvation作为一个通用子域来使用。该产品的一大创新是将CollabOvation引入了敏捷项目管理,这样用户可以围绕Scrum的产品、发布、冲刺和待定项展开讨论。

    这些限界上下文之间的关系如何,不同开发团队之间的关系又如何?让我们看下各种关系之间的定义:

    • 合作关系(partnership):如果两个限界上下文的团队要么一起成功,要么一起失败,此时他们需要建立起一种合作关系。他们需要协调开发计划和集成管理。

    • 共享内核(share kernel):对模型和代码的共享将产生一种紧密的依赖性,对于设计来说,这种依赖性可好可坏。我们需要为共享的部分模型指定一个显式的边界,并保持共享内核的小型化。共享内核具有特殊的状态,在没有与另一个团队协商的情况下,这种状态是不能改变的。我们应该引入一种持续集成过程来保证共享内核与通用语言的一致性。

    • 客户方——供应方开发(Customer-Supplier Development):当两个团队处于一种上游-下游关系时,上游团队可能独立于下游团队完成开发,此时下游团队开发可能会受到影响。因此,在上游团队的计划中,我们应该顾及到下游团队的需求。

    • 遵奉者(conformist):在存在上游-下游关系时,如果上游团队已经没有动力提供下游团队之所需,下游团队便孤军无助了。只能盲目地使用上游团队的模型。

    • 防腐层(Anticorruption layer):在集成两个良好的限界上下文时,翻译层可能很简单,甚至可以很优雅地实现。但是,当共享内核、合作关系或客户方-供应方关系无法顺利实现时,此时的翻译将变得复杂。对于下游客户来说,你需要根据自己的领域模型创建一个单独的层,该层作为上游系统的委派向你的系统提供功能。防腐层通过已有的接口与其他系统交互,而其他系统只需要做很小的修改,甚至无须修改。在防腐层内部,它在你自己的模型和他方模型之间进行翻译转化。

    • 开放主机服务(open host service):定义一种协议,让你的子系统通过该协议来访问你的服务。你需要将该协议公开,这样任何与你集成的人都可以使用该协议。在有新的集成需求时,你应该对协议进行改进或者扩展。对于一些特殊的需求,你可以采用一次性的翻译予以处理,这样可以保持协议的简单性和连贯性。

    • 发布语言(published language):在两个限界上下文之间翻译模型需要一种公用的语言。此时你应该使用一种发布出来的共享语言来完成集成交流。发布语言通常与开放主机一起使用。

    • 另谋他路(separateWay):在确定需求时,我们应该做到坚持到底。如果两套功能没有显著的关系,那么它们也可以被完全解耦的。声明两个限界上下文之间不存在任何关系,这样使得开发者去寻找简单的、专门的方法来解决问题。

    • 大泥球(Big Ball of mud):当我们检查已有系统时,经常会发现系统中存在混杂在一起的模型,它们之间的边界是非常模糊的。此时,你应该为整个系统绘制一个边界,然后将其归纳在大泥球范围之列。在这个边界之内,不要试图使用复杂的建模手段来化解问题。同时,这样的系统有可能会向其他系统蔓延,你应该对此保持警觉。

    在与身份与访问上下文集成时,协作上下文和敏捷项目管理上下文均没有采用另谋他路的手法。诚然,在上下文范围之内,另谋他路的手法可以应用在特殊的系统上,同时它也可以用于一些个例。比如,一个团队可能拒绝使用集中式的安全管理系统,但他们依然会与另外类型的安全管理系统集成。

    在集成时,他们将会用到开放主机服务和发布语言,有可能还会用到防腐层。虽然这两者都会在限界上下文之间创建开放的标准,但是它们并不矛盾。通过使用下游上下文中的基本原则,他们依然可以得到由独立翻译所带来的好处,并且不会像与大泥球集成那样复杂。翻译层将变得简单、优雅。

    在上下文映射图中,我们使用以下缩写来表示各种关系:

    • ACL 表示防腐层
    • OHS 表示开放主机服务
    • PL 表示发布语言

    3、映射3个示例限界上下文

    当CollabOvation团队意识到自己已经陷入僵局时,他们研究发现“上下文映射图”的工具非常实用。

    从团队设计的第一张映射图可以看出,他们已经知道应该创建一个名为“协作上下文”的限界上下文。从图中怪异的边界又可以看出,他们可能希望创建第二个限界上下文,但是却不知道如何将这个上下文从核心域中分离出来。
    在这里插入图片描述

    团队成员意识到安全、用户和权限并不属于协作上下文,需要将这些概念从核心域中分离出来,是这些概念只有在得到同意的时候才能进入核心域。

    在对子域进行了分析,或对问题空间进行了评估之后,团队所绘制的上下文映射图如图所示,从一个限界上下文中分离出了两个子域。由于子域和限界上下文最好保持一对一的关系,我们应该将原来的协作上下文分离成两个限界上下文。

    在这里插入图片描述

    对子域和边界的分析要求我们做出决定。当人们需要使用CollabOvation的功能时,他们扮演者时参与者、作者和主持者的身份。有了这样的角色分离,我们便可以绘制一个更高层次的上下文映射图,如图所示。团队使用了分离内核对系统进行重构。

    在这里插入图片描述

    当下一个ProjectOvation项目启动时,团队将使用这个新的核心域——敏捷项目管理上下文来增强已有的上下文映射图,如图所示。

    在这里插入图片描述

    SaaSOvation的开发团队已经对核心的模型分离有了很好的理解。与CollabOvation相似,当ProjectOvation的用户扮演的是产品负责人或团队成员的角色。身份与访问上下文已经从核心域中分离出去了。协作上下文对于ProjectOvation来说只是一个支撑子域。任何时候,这个新的模型都受到了上下文边界的保护,外部概念需要通过翻译才能进入核心域中。

    身份与访问上下文位于最上游,它对协作上下文和敏捷项目管理上下文均会产生影响。同时,协作上下文又是敏捷项目管理上下文的上游,因为后者的模型依赖于前者的模型和服务。

    在限界上下文中我们提到,ProjectOvation将自治地运行,而不会依赖于周边的环境。这并不是说自治服务就可以完全独立于上游模型,而是我们的设计应该尽可能地限制实时依赖性。虽然ProjectOvation是自治的,但是它依然属于其他系统的下游。

    上图中,上游系统的连接框,都标以OHS/PL,分别表示开放主机服务和发布语言。所有下游的连接框都标以ACL,即防腐层。简单地来说,这些集成模式采用以下技术:

    • 开放主机服务:该模式可以通过REST实现。通常来讲,我们可以将开放主机服务看成是远程过程调用(RPC)的API。同时,他也可以通过消息机制实现。

    • 发布语言:发布语言可以通过多种形式实现,但最常见的是使用XML Schema。在使用REST服务时,发布语言用来表示领域概念,此时可以使用XML和JSON。发布语言既可以使用标准的媒体类型进行发布,也可以使用自定义类型。同时,发布语言还可以用于事件驱动架构(Event-Driven Architecture),其中领域事件以消息的形式发送给订阅方。

    • 防腐层:在下游上下文中,我们可以为每个防腐层定义相应的领域服务(Domain Service)。同时,你也可以将防腐层用于资源接口。在使用REST时,客户端的领域服务将访问远程的开放主机服务,远程服务以发布语言的形式返回,下游的防腐层将返回内容翻译成本地上下文的领域对象。比如,协作上下文向身份与访问上下文请求“具有Moderator角色的用户”。所返回的数据可能是XML格式或JSON格式,然后防腐层将这些数据翻译成协作上下文中的Moderator对象,该对象是一个值对象。这个Moderator实例反映的是下游模型中的概念,而不是上游模型。

    由于协作上下文是第一个核心域,让我们把它放大来看看。首先我们将接触到一些简单的集成方式,然后再是更高级的。

    4、协作上下文

    协作上下文作为SaaSOvation公司的第一个核心域。开发团队已经对其有很好的理解了。这里他们使用的集成方式比较简单,但是在可靠性和自治性上还稍逊一筹。要将此上下文映射图进行放大还是相对容易的。

    身份与访问上下文通过REST的方式向外发布服务。作为该上下文的客户,协作上下文通过传统类似于RPC的方式来获取外部资源。协作上下文并不会永久性地记录下从身份与访问上下文中获取来的数据,而是在每次需要数据时重新向系统发出请求。显然,协作上下文高度依赖于远程服务,它不具有自治性。但目前SaaSOvation公司愿意采取这种方式集成,以满足交付计划。由于之后的ProjectOvation项目将使用自治性服务,CollabOvation到时可以借鉴ProjectOvation的做法。

    在这里插入图片描述

    上图是放大后的上下文映射图,下游系统的边界对象采用同步的方式向上游系统获取到资源。当获取到远程数据模型数据之后,边界对象取出所需数据,再将其翻译成适当的值对象实例。

    在这里插入图片描述

    在上图中,翻译图(Translation Map)将所获取数据转化成一个值对象。这里,身份与访问上下文中一个具有Moderator角色的User被翻译成了协作上下文中的Moderator值对象。

    不幸的是,如果由于远程系统不可用而导致同步请求失败,那么本地系统也将跟着失败。虽然REST并不是真正意义上的RPC,但它却具有与RPC相似的特征。彻底的系统失败并不多见,但它却是一个潜在的问题。CollabOvation团队急切地希望解决这个问题。

    5、敏捷项目管理上下文

    为了达到比RPC更高的自治性,敏捷项目管理上下文团队将尽量限制对RPC的使用,此时他们可以选择异步请求,或者事件处理等方式。

    如果系统所依赖的状态已经存在于本地,那么我们将获得更大自治性。有人可能认为这只是对所有依赖对象进行缓存,但这不是DDD的做法。DDD的做法是:在本地创建一些由外部模型翻译而成的领域对象,这些对象保留着本地模型所需的最小的状态集。为了初始化这些对象,我们要有限的RPC调用或REST请求。然而,要与远程模型保持同步,最好的方式是在远程系统中采用面向消息的通知机制。消息通知可以通过服务总线进行发布,也可以采用消息队列或者REST。

    被同步的状态应该是本地模型所需远程模型的最小属性集。这里并不只是限制我们的对数据的需求,还应该对概念进行恰当的建模。

    6、和身份与访问上下文集成

    在这里插入图片描述

    在图中我们看到,对于身份与访问上下文的领域事件,系统将以URI的方式向外发布事件通知。这种功能是通过NotificationResource提供的,它向外发布REST资源。这里的通知资源是一组被发布的领域事件。对于消费方来说,每个事件总是可用的。消费方应该避免对事件的重复消费。

    一个自定义的媒体类型表明客户可以请求两种资源:
    在这里插入图片描述

    通过第一个资源URI,客户可以(使用HTTPGET请求)获取当前的通知日志(一个固定大小的通知集合)。对于自定义的媒体类型:
    在这里插入图片描述

    可以看出,这里的URI是全新的,并且是稳定的,因此它不会改变。无论当前的通知日志中包含了什么样的内容,该URI都会将其发布。

    事实上,ProjectOvation团队并不打算全盘使用REST。比如,他们目前正与CollabOvation团队协商是否可以使用消息机制,例如rabbitMQ。但就目前而言,它们和身份与访问上下文的集成依然是基于REST的。

    现在,让我们忽略技术细节,看看映射图中各个交互对象所扮演的角色。如图表示集成过程的序列图:

    在这里插入图片描述

    • MemberService是一个领域服务,它向本地模型提供ProductOwner和TeamOwner对象,同时作为基本防腐层的接口。maintainService方法用于周期性地检查身份与访问上下文所发出的通知。该方法不由模型的正常用户调用,而是由通知组件周期性地调用,在上图中,MemberSynchronizer表示这样的同步组件,它会把请求委派给MemberService。
    • MemberService进一步把请求委派给IdentityAccessNotificationAdapter,该类在领域服务和远程开放主机服务之间扮演着适配器的角色。该适配器作为远程系统的客户端而存在。与远程系统NotificationResource交互并没有显示在图中。
    • 一旦适配器从远程的开放主机服务获取到了数据,它将调用Member
      Translator的toMember()方法将发布语言中的媒体数据翻译成本地系统中的领域对象Member。如果该对象在本地系统中已经存在,则更新该对象。MemberService的updateMember()方法用于更新一个Member
      对象,此时它把委托操作委派给了自己。Member的子类有ProductOwner和TeamMember,它们反映了本地系统中的上下文概念。

    我们不应该将重点放在技术实现和集成产品上,而应该放在限界上下文之间的分离上,这样我们可以保持每个上下文的纯洁性,同时将一个上下文中的数据用于另一个上下文的概念中。

    让我们看看敏捷管理上下文是如何与协作上下文集成的。同样,我们关注的是系统的自治性,但这给集成带来了更多的困难与挑战。

    ProjectOvation将使用CollabOvation所提供的附加功能,比如论坛和共享日历等。ProjectOvation用户并不直接与CollabOvation交互。对于某租户来说,ProjectOvation必须决定出哪些CollabOvation的功能时该租户可用的。然后,ProjectOvation将协调对CollabOvation资源的创建。

    比如,Forum和Discussion必须在协作上下文进行创建的。在身份与访问上下文中,对象是先前存在的。而对于敏捷项目管理上下文来说,对象是不会预先存在的,直到被请求为止。这对于实现系统自治性来说是一个潜在的障碍,因为我们依赖于协作上下文来远程地创建资源。

    在使用领域事件和事件驱动架构时,我们应该仔细思考最终一致性。本地系统产生的事件通知并不是只能由远程系统消费。在ProjectOvation中,当ProjectInitiated事件产生时,该事件将由本地系统进行处理。本地系统要求Forum和Discussion在远程完成创建。这可以通过RPC或消息机制完成。

    如果项目负责人是图使用一个不存在的Discussion会发生什么问题吗?有时是由于调用失败,有时是由于没有预先付款导致协作功能不可用,这不一定是一个技术原因。对于最终一致性的处理我们应该将其考虑在建模访问之内。

    处理资源不可用的一个好办法便是将其显现出来。考虑以下由标准类型实现的状态和模式。此时的状态是一个值对象。
    在这里插入图片描述
    在该设计中,由DiscussionAvailability定义的状态将对象Discussion其保护作用。当有人是图参加关于一个Product的讨论时,该设计将正确地处理Discussion的状态。如果状态不为READY,参与者将得到以下消息之一:
    (1)要使用团队协作功能,你需要购买附加功能。
    (2)产品负责人还没请求创建产品讨论。
    (3)讨论启动失败,请稍后再试。

    此时,ProjectOvation团队还不清楚采用哪种方式与CollabOvation进行集成。在讨论了客户方-供应方关系后,它们得到了下图:
    在这里插入图片描述

    敏捷项目管理上下文可以使用第二个防腐层来处理与协作上下文之间的集成。事实上CollaborationAdapter并不是单个,此处只是一个占位符,表示有多个适配器。

    敏捷项目上下文在本地有DiscussionService和SchedulingService,它们是领域服务,用于管理协作系统中的讨论和日历条目。

    以上的例子已经展示了上下文映射图的某些细节。

    对于一个非常详细的上下文映射图,我们很有可能无法对其进行实时更新。保持简单性和敏捷性,拒绝繁文缛节,这样我们创建的上下文映射图将对项目起推动作用,而不是阻碍作用。

    展开全文
  • tomcat设置上下文和配置多个应用

    千次阅读 2013-09-03 21:17:28
    Tomcat下为每个Web应用配置不同的访问端口 要完成这个目录必须对conf/Server.xml文件进行配置  设现在我们有两个应用app1和app2,客户端期望的访问方式是:  App1 ->  http://localhost:8081/  

    Tomcat下为每个Web应用配置不同的访问端口


    要完成这个目录必须对conf/Server.xml文件进行配置

                                设现在我们有两个应用app1和app2,客户端期望的访问方式是:

                                App1         ->      http://localhost:8081/

                                App2         ->      http://localhost:8082/

                                这样省去了在主机名后面添加ContextPath的麻烦,相信客户更愿意这样使用。

                                实现步骤:

    1.        找到conf/server.xml中的service配置节,复制这个service元素,紧跟在后面粘贴一次。如下:

    <Servicename="Catalina.app1">

        <Connector port="8081"protocol="HTTP/1.1"

                  connectionTimeout="20000"

                   redirectPort="8443"/>

        <Engine name="Catalina.app1" defaultHost="localhost">

          <RealmclassName="org.apache.catalina.realm.LockOutRealm">       

            <RealmclassName="org.apache.catalina.realm.UserDatabaseRealm"

                   resourceName="UserDatabase"/>

          </Realm>

          <Host name="localhost"  appBase="webapps"

                unpackWARs="true"autoDeploy="true">      

            <ValveclassName="org.apache.catalina.valves.AccessLogValve"directory="logs"

                   prefix="localhost_access_log."suffix=".txt"

                   pattern="%h %l %u %t&quot;%r&quot; %s %b" />

                       <Context path="/"docBase="app1" />

          </Host>       

        </Engine>

     </Service>

    说明:红色加粗是特别要注意的部分。

             1.1、<Servicename="Catalina.app1">,这里设置Service的名字为Catalina.app1,是随便取的名字不能和当前这个文件已有的Service元素同名。

             1.2、<Connectorport="8081"…/,这里设置当前服务的Http Connector监听的端口为8081,注意不能和已有的其它Service的Connector的监听端口相同。

             1.3、<Enginename="Catalina.app1"defaultHost="localhost">,这里设置Engine的名字为Catalina.app1也不是必须的,你可以换其它名字,但是还是不要和其它Engine重名就行了。defaultHost这个属性指出当前Engine根据主机头在它的子元素中找不到匹配名称的虚拟主机时所要访问的缺省虚拟主机。我们这儿Engine里面只有一个虚拟主机因此缺省主机也是它。当然defaultHost属性指定的主机名称在它的子元素里面是必须存在的。

             1.4、<Host name="localhost"  appBase="webapps" />,name属性指定虚拟主机的名字,一般是Internet域名,Engine会根据HTTP协议请求里面的主机头Host的值来匹配这里的虚拟主机名,如果匹配就交给该虚拟主机处理。比如,如果你的客户端访问地址是:http://qrkx.uten.cn:8090/index.jsp,那么这里虚拟主机名字就应该为qrkx.uten.cn,当然请求中的端口号是前面连接器最先使用的。appBase属性指出虚拟主机上的Web应用是部署在哪里的。一个虚拟主机上可以同时部署多个Web应用,那么appBase就是指出这些应用的存放位置,这里可以使带盘符的绝对路径,像d:/webapps.也可以是相对路径。这个相对路径的起点就是Tomcat的安装目录。这里appBase属性我们设置为webapps表示当前虚拟主机的Web应用存放目录为tomcat安装目录下的webapps目录里面。

             1.5、<Context path="/"docBase="app1" />,这个是最为关键的部分了。一个虚拟主机里面可以部署多个Web应用,而每个Web应用就是一个Context,因此这里可以配置多个Context元素,每个表示一个Web应用程序上下文。Path属性表示访问这个Web应用的路径,”/”表示这个Context是当前虚拟主机的缺省Web应用程序,也可以为空字符串“”,这样改Context可以用处理所有不匹配任何其它Context的 Context path请求。我们访问的时候就不用输入Web应用的名称了,可以如下访问http://localhost:80801/,如果你像这样配置:<Contextpath="/app1" docBase="app1" />,那么你就要这样访问:http://localhost:80801/app1/。总结一下意思就是在一个虚拟主机下只有一个Web应用是采用根路径的,其它必须要指定特别的访问路径【根路径只有一个】,比如path="/app1"、path="/app2"、path="/app3"等。

             docBase="app1"这个属性指出当前Web应用程序的存放路径,可以是相对路径也可以是绝对路径,绝对路径就是带盘符的路径,比如:d:/app1,相对路径就是以Host元素的appBase属性指定的路径为起点的路径。这里docBase="app1"表示我们的当前Web应用程序是在Tomcat安装目下的webapps目录下的app1目录。

    本篇文章来源于 Linux公社网站(www.linuxidc.com)  原文链接:http://www.linuxidc.com/Linux/2012-06/62032.htm

    展开全文
  • Spring各种上下文的关系详解

    千次阅读 2019-06-11 16:39:23
    要想很好理解这三个上下文的关系,可以Debug追踪源码加深自己的理解。... 首先,对于一个web应用,其部署在web容器中,web容器提供其一个全局的上下文环境,这个上下文就是ServletContext,其为后...
  • Spring父子上下文重叠

    千次阅读 2020-01-17 17:44:08
    如果使用传统的方式来开发Spring项目,要部署在Tomcat上面,一般会依赖Spring与Spring MVC,在Tomcat的web.xml中会配置一加载service的配置文件,这在Tomcat启动的时候会进行加载,会生成一Spring的容器。...
  • 复制Java Web项目,Tomcan报上下文错误

    千次阅读 2016-10-19 16:22:03
    Tomcat启动不起来,会报“无法为tomcat发布服务器配置 多个上下文有路径”这个错误。原因是复制的项目虽然项目名改了,但是在Tomcat中的访问路径没有改变。需要自己打开服务器项目,找到server.xml文件来进行配置。 ...
  • Web基础(三)Python Web

    千次阅读 多人点赞 2018-11-14 19:11:49
    文章目录Python Web基础1. WSGI1.1 概述1.2 实现原理1、WSGI Server/gateway2、WSGI Application3、WSGI MiddleWare1.3 测试 WSGI服务器代码简析1.4 实现WSGI服务器1.5 生产环境中的Web服务器[Gunicorn]...
  • ServletContext 获取上下文对象

    千次阅读 2017-10-26 21:32:03
    ServletContext 一个项目只有一个ServletContext 在多个servlet中传递参数在web.xml中写全局变量 1、获取上下文对象package com.zhiyou.servlet.demo02;import java.io.IOException;import javax.servlet....
  • 简单理解 context 在当前环境下你能拿到的参数都可以从...context就是“容器”,放的就是应用程序的所有资源,要用时候就访问它,所以context里面的东西,在同一应用程序里面是全局的。 是一包含各种cont...
  • 来源:...问题1 如何让web容器加载你的web MVC框架 对于基于servlet的web容器来说,遵循的是servlet规范,入口配置文件是web.xml。这类web容器会在启动的时候会而且仅会加载如下三
  • 最近在做web项目,需要写一些工具方法,涉及到通过Java代码来获取spring中配置的bean,并对该bean进行操作的情形。而最关键的一步就是获取ApplicationContext,过程中纠结和错误了很久,总结一下获取...
  • 前言: flask的轻便和强大的扩展性能会让web的初级开发者甚至是有经验的开发者神往。...但当中对应用上下文和请求上下文的讲解有点简单,本文对这两概念做一总结,方便自己以后的回顾。 预备知识:
  • 上下文对象

    千次阅读 2018-01-28 20:14:14
    一、上下文概念: 每一个Web Project,运行时都部署在Tomcat下,称为一个应用。 部署后,启动Tomcat时,Tomcat将为每一个应用创建一个对象,这个对象称...2.利用上下文对象,可以实现多个用户间的数据共享。 Servle
  • spring上下文

    万次阅读 2019-02-12 10:26:05
    应用上下文即是Spring容器抽象的一种实现;而我们常见的ApplicationContext本质上说就是一维护Bean定义以及对象之间协作关系的高级接口。额,听起来是不是很抽象拗口?那你再读一遍呢。。。这里,我们必须明确,...
  • springBoot设置上下文路径

    千次阅读 2019-01-15 21:11:26
    学习博客程序编写时 发现一问题 就是controller类中跳转jsp,SpringBoot没有编写上下文路径就可以自动找到jsp页面所在的文件夹,原因是 https://blog.csdn.net/z69183787/article/details/46520711 ...
  • 多个上下文的路径为“/Java1812SpringMVC”。 报错原文: Could not publish server configuration for Tomcat v8.0 Server at localhost.Multiple Contexts have a path of "/Java1812SpringMVC". 遇...
  • 如何在 Spring 异步调用中传递上下文

    千次阅读 2019-08-01 22:19:28
    异步调用是相对于同步调用而言的,同步调用是指程序按预定顺序一步步执行,每一步必须等到一步执行完后才能执行,异步调用则无需等待一步程序执行完即可执行。异步调用指,在程序在执行时,无需等待执行的返回值...
  • 真正理解线程上下文类加载器(案例分析)

    万次阅读 多人点赞 2016-09-25 13:31:36
    线程上下文类加载器破坏了“双亲委派模型”,可以在执行线程中抛弃双亲委派加载链模式,使上层代码可以逆向使用下层的系统类加载器。本文通过JDBC和Tomcat两案例分析,详细解释了其中的原理。
  • Spring IoC是一独立的模块,它并不是直接在Web容器中发挥作用的。...在这过程中,一方面处理Web容器的启动,另一方面通过设计特定的Web容器拦截器,将IoC容器载入到Web环境中来.并将其初始化。在这...
  • 当同一服务器上部署了多个不同的web应用时,可以使用Nginx进行管理配置。 举个例子:假如 www.aabbccdd.com ...访问这些应用的方式通过上下文(context)来进行区分:   www.aabbccdd.com/finance/ www.aabbccdd....
  • 严重: 异常将上下文初始化事件发送到类的侦听器实例.[org.springframework.web.context.ContextLoaderListener] java.lang.IllegalStateException: The server encountered an internal error () that prevented it...
  • 那么 ,当笔者想像其中注入监听器和上下文时,遇到了难题 – 如何注入 ? 在哪里注入 ? 既然出现了问题,那么接下了就是解决问题了,下面阐述笔者的解决方法 , 我就以最简单的项目根文件目录的监听来阐述 : 首先 注意...
  • springboot的应用上下文

    千次阅读 2020-06-21 19:33:12
    该类属于spring-boot-2.1.1Release.jar中,是自springboot诞生就衍生出来的,是spring框架的应用上下文Application的子类。 说无益,show me code 扩展的功能 首先让我们来看一下,这类到底做了什么,有什么...
  • 1 线程上下文类加载器 2 何时使用Thread.getContextClassLoader()? 3 类加载器与Web容器 4 类加载器与OSGi 总结 1 线程上下文类加载器  线程上下文类加载器(context class loader)是从 JDK 1.2 开始引入的...
  • 配置Spring应用上下文

    2018-06-26 21:14:12
    配置Spring应用上下文 Spring自带了多种类型的应用上下文,下面罗列几个最有可能遇到的 ...* AnnotationConfigWebApplicationContext:从一个或多个基于Java的配置类中加载Spring Web应用上下文。 * ...
  • “狗书”中有地方讲到应用上下文和请求上下文,博主初次看的时候很懵逼,其实我们要理解这两东西,最应该了解IT行业的“上下文”是什么意思,这样再去理解应用上下文和请求上下文就容易得了,只是对博主来说是...
  • Spring应用上下文配置:xml配置

    千次阅读 2016-09-02 18:03:19
    如同我们讲过的那样,启动Spring,实际上是启动一容器,创建一组应用上下文。既然需要创建应用上下文,就必须配置应用上下文,指导应用上下文如何工作。如同启动Spring一样,配置Spring应用上下文也有三种方式,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 244,776
精华内容 97,910
关键字:

多个web上下文