标签归档:Webx

[ERROR] Undefined placeholders found in template:

[ERROR] Undefined placeholders found in template:
– Template: META-INF/autoconf/uris.xml.vm
– Descriptor: META-INF/autoconf/auto-config.xml
– Base URL: file:/D:/Project/Trunk/www-yneit-com/web/target/web-1.0.0/
—————————————————————
-> web_server

部署开发程序经常出现这个问题:解决步骤如下:
1、是查看META-INF/autoconf/uris.xml.vm中变量没有被定义${web_server},
2、没有的话在antx.properties、auto-config.xml添加.

经过这上面的处理一般可以解决问题了,但是还有例外,比如uris.xml.vm不需要这个变量,但是一直报这个错,这时候查看一下C:\Users\yneit\antx.properties,看看这个文件里面到底有没有,没有的话加上。

webx 学习笔记

Webx是建立在Java Servlet API基础上的的通用WEB框架。用Webx搭建的应用可以运行在任何一个标准的WEB应用服务器上面:Tomcat、Jetty、Jboss、Weblogic……。Webx是一个在阿里巴巴集团内部广泛使用的,层次化、模块化的一个Web框架。 Webx是基于经典MVC设计模式的WEB框架,推崇页面驱动和约定胜于配置的理念。 Webx是一个基于Spring的组件框架。组件是一个软件包,它可以被其它组件扩展,也可以扩展其它组件。利用这些特性,Webx不仅能够用来开发高度可定制的Web应用(这是它的主要功能),也能够用来帮助你开发高度可扩展的非WEB的应用。

三大层次
SpringExt
Webx是一套基于Java Servlet API的通用Web框架。Webx致力于提供一套极具扩展性的机制,来满足Web应用不断变化和发展的需求。SpringExt完全兼容Spring原来schema的概念和风格,但是却可以让schema像程序代码一样被扩展。Webx完全建立在SpringExt的基础上。而SpringExt正是这种扩展性的基石。其中提及:扩展点,Configuration Point、捐献,Contribution、组件和包。

Webx Framework
Webx Framework。事实上,这是第一个真正涉足WEB技术的层次。Webx Framework将负责创建一组级联的Spring容器结构。Webx所创建的Spring容器完全兼容于Spring MVC所创建的容器,可被所有使用Spring框架作为基础的WEB框架所使用。
当Webx Framework接收到一个来自WEB的请求以后,实际上它主要做了两件事:
首先,它会增强request、response、session的功能,并把它们打包成更易使用的RequestContext对象。
其次,它会调用相应子应用的pipeline,用它来做进一步的处理。
假如在上面的过程中出现异常,则会触发Webx Framework处理异常的过程。
此外,Webx Framework还提供了一组辅助开发的功能,例如查看环境变量,查看schema等。这些功能只在开发模式生效,生产模式下自动关闭。

Webx Turbine
Webx Turbine建立在Webx Framework的基础上,实现了页面渲染、布局、数据验证、数据提交等一系列工作。
Webx Turbine之所以叫这个名字,是因为Webx最早的版本,是从Apache Turbine项目上发展而来的。到现在,Turbine的代码已经荡然无存,然而Turbine中的一些风格和想法依赖保存在Webx框架中。
Webx Turbine所遵循下面的设计理念包括:
页面驱动
约定胜于配置
假设用户以URL:http://localhost:8081/来访问Webx应用。域名和端口不重要,取决于应用服务器的配置,这里假设为localhost:8081。Webx Framework的处理流程,从WebxFrameworkFilter接收请求,并且一路顺利到达pipeline。然后Pipeline开始依次执行它的valves。(下面的描述略过一些相对次要的步骤。)
– 分析URL
分析URL的目的是取得target。由于用户访问的URL中并没有提供path信息,通常被理解为:用户想要访问“主页”。AnalyzeURL valve提供了一个可选的参数“homepage”,即是在这种情况下起作用 —— http://localhost:8081/对应的target为“homepage”。需要注意的是,target不代表模板名,也不代表类名。Target只是一个抽象的概念 —— 当前页面需要达成的目标。Target可能被后续的valves解释成模板名、类名或者其它东西。
进入 – 多重分支
很明显,“homepage”满足了第一个所附带的条件:,意思是target的后缀不存在(null)或为“jsp”或为“vm”。
– 执行action
和其它框架中的action概念不同,在Webx Turbine中,action是用来处理用户提交的表单的。
因为本次请求未提供action参数,所以跳过该步骤。
– 查找并执行screen。
这里要用到一个规则:target映射成screen module类名的规则。
假设target为xxx/yyy/zzz,那么Webx Turbine会依次查找下面的screen模块:
screen.xxx.yyy.Zzz,
screen.xxx.yyy.Default,
screen.xxx.Default,
screen.Default。
本次请求的target为homepage,因此它会尝试查找screen.Homepage和screen.Default这两个类。
如果找到screen类,Webx Turbine就会执行它。Screen类的功能,通常是读取数据库,然后把模板所需要的对象放到context中。
如果找不到,也没关系 —— 这就是“页面优先”:像homepage这样的主页,通常没有业务逻辑,因此不需要screen类,只需要有模板就可以了。
– 渲染模板
这里用到两个规则:target映射成screen template,以及target映射成layout template。
假设target为xxx/yyy/zzz,那么Webx Turbine会查找下面的screen模板:/templates/screen/xxx/yyy/zzz。Screen模板如果未找到,就会报404 Not Found错误。 找到screen模板以后,Webx Turbine还会试着查找下面的layout模板:
/templates/layout/xxx/yyy/zzz
/templates/layout/xxx/yyy/default
/templates/layout/xxx/default
/templates/layout/default
Layout模板如果找不到,就直接渲染screen模板;如果存在,则把渲染screen模板后的结果,嵌入到layout模板中。
Layout模板和screen模板中,都可以调用control。每个页面只有一个screen,却可以有任意多个controls。
– 内部重定向
在screen和action中,可以进行“内部重定向”。内部重定向实质上就是由实施的 —— 如果没有重定向标记,就退出;否则循环到标签。
和外部重定向不同,外部重定向是向浏览器返回一个302或303 response,其中包含Location header,浏览器看到这样的response以后,就会发出第二个请求。而内部重定向发生在pipeline内部,浏览器并不了解内部重定向。

Request contexts、Pipeline服务
Filter是Servlet规范2.3版及更新版所支持的一种机制。和Servlet/JSP不同,Filter自己往往不会直接产生response,相反,它提供了一种“符加”的功能,可以作用在任何一个servlet、JSP以及其它filter之上。然而,在实际的应用中,我们发现filter有很多不足之处。
Webx框架提供了两种机制(Request Contexts和Pipeline)来作为filter机制的补充。在大多数情况下,它们都可以实现类似filter的功能,但比filter更容易扩展、更容易配置、也更轻量。Webx并没有打算完全替代filter,相反它还是可以和任何filter搭配使用。
Filter可以访问和修改数据。但它只能访问和修改HttpServletRequest、HttpServletResponse、ServletContext等容器级的对象,而不能(或很难)访问应用程序中的状态。所以filter无法实现和应用逻辑密切相关的功能。
Filter可以影响执行流程。但它不能改变filter chain的结构和顺序。Filter chain的结构和顺序是由web.xml中定义的。当filter得到控制权以后,它只能选择继续下去,或者立即结束,而没法进行循环、分支、条件判断等更复杂的控制。因此,filter只能用来实现粗粒度的流程控制功能(例如,当用户未获授权时,停止执行filter chain),难以应付更细致的应用程序内的控制需求。
Filter与其它filter和servlet之间,除了request和response对象以外,无法共享其它的状态。这既是优点又是缺点。优点是使filter更独立、更通用;缺点是filter与其它filter、servlet之间难以协作,有时甚至会引起无谓的性能损失。
和Filter不同,Request Contexts和Pipeline服务可以访问应用内部的状态和资源,效率更高,功能更强。
和Filter不同,Pipeline服务可以定义灵活(但仍然简单)地控制应用的流程 。Pipeline不仅可以控制流程的中断或继续,还可以实现子流程、循环、条件转移、异常处理等更精细的流程控制。Pipeline服务甚至可以运用在非WEB的环境中。Pipeline可以说是Webx框架的核心功能之一。
和Filter不同,Request Contexts服务中的每一个环节(Request Context)之间并非完全独立、互不干涉的。每个request context可以访问它所依赖的其它request context中的状态。

参考:
Webx petstore:https://github.com/webx/citrus-sample.git
Webx:http://www.openwebx.org/

Eclipse 乱码解决方法

如果要使插件开发应用能有更好的国际化支持,能够最大程度的支持中文输出,则最好使 Java文件使用UTF-8编码。然而,Eclipse工作空间(workspace)的缺省字符编码是操作系统缺省的编码,简体中文操作系统 (Win8 win8.1简体中文)的缺省编码是GB18030,在此工作空间中建立的工程编码是GB18030,工程中建立的java文件也是GB18030。如果要使 新建立工程、java文件直接使UTF-8则需要做以下工作:
1、windows->Preferences…打开”首选项”对话框,左侧导航树,导航到general->Workspace,右 侧Text file encoding,选择Other,改变为UTF-8,以后新建立工程其属性对话框中的Text file encoding即为UTF-8。

2、windows->Preferences…打开”首选项”对话框,左侧导航树,导航到general->Content Types,右侧Context Types树,点开Text,选择Java Source File,在下面的Default encoding输入框中输入UTF-8,点Update,则设置Java文件编码为UTF-8。其他java应用开发相关的文件 如:properties、XML等已经由Eclipse缺省指定,分别为ISO8859-1,UTF-8,如开发中确需改变编码格式则可以在此指定。

3、经过上述两步,新建java文件即为UTF-8编码,Eclipse编译、运行、调试都没问题,但是做RCP应用的Product输出时、或者插件 输出时,则总是出错,要么不能编译通过(输出时要重新compile)、要么输出的插件运行时中文显示乱码。此时需要再RCP应用、或插件Plugin工 程的build.properties中增加一行,javacDefaultEncoding.. = UTF-8。让输出时编译知道java源文件时UTF-8编码。这个设置需要保证所有的java源文件时UTF-8编码格式,如果不全是,可以参考 Eclipse帮中(Plug-in Development Environment Guide > Reference > Feature and Plug-in Build configuration),建议全部java源文件是UTF-8编码。

如果插件开发、RCP应用开发原来基于其他编码,如GB18030,想转换为UTF-8,则首先,做以上工作;然后通过查找编码转换工具,如基于 iconv的批量转换工具,将原编码转换为UTF-8编码,注意只转换java源文件,其他类型文件可能已经是比较合适的编码了;将原工程属性中的 Text file encoding,从原编码改为UTF-8即可。

4、本次在Eclipse中导入Webx3的项目,结果也出现*.vm文件乱码的问题,如果是单个问题出现乱码,可以执行以下操作:File->Properties->Resource 选项中Text file encoding 设置为UTF-8即可。

PS:以上方法同样适用于webx导入eclipse出现乱码问题