CloudStack源码分析.docx

目录CloudStack源码分析31.用CloudStack的源码进行工作31.1.源码获得方式32.包与依赖32.1.包32.2.依赖42.3.未来53.异常与日志53.1.日志53.2.异常和异常捕获63.3.CloudStack异常84.代码联合工作94.1.组件94.2.组件加载105.CloudStack API开发115.1.如何编写API115.2.API注解165.2.1.API命令注解165.2.2.API响应注解176.CloudStack中使用Spring176.1.CloudStack组件186.2.如何声明一个CloudStack组件196.3.Auto-wiring196.4.CloudStack Spring组件的编码约定206.4.1.注意自动注入的时间206.4.2.公用构造器206.4.3.组件自主初始化206.4.4.运行时注入216.4.5.CloudStack定制化AOP（面向切面的编程）216.4.6.可插拔适配器246.4.7.模块和组件266.4.8.什么时候用或者不用@Inject286.5.组件生命周期287.数据访问层297.1.需要知道的297.2.在哪能找到例子297.3.DAO297.4.写一个新的VO和DAO307.5.使用347.5.1.使用DAO347.5.2.更新VOs347.5.3.搜索347.5.4.使用事务367.5.5.处理嵌套事务387.5.6.处理锁388.使用Junit和Spring进行单元测试38CloudStack源码分析用CloudStack的源码进行工作源码获得方式使用git将源码克隆到本地：git clone /repos/asf/cloudstack.git/repos/asf/cloudstack.git切换版本：git checkout 分支包与依赖包下面的表格列出了所有的包与其作用，如果你想为CloudStack添加代码，请阅读这个列表再决定将代码添加到哪个包里面项目包名作用说明utilscloud-util.jar可以在任何项目中使用此工具集apicloud-api.jarREST APIAgent APIJava APIcorecloud-core.jarServerResource实现servercloud-server.jar管理服务器agentcloud-agent.jar代理容器ovmcloud-ovm.jarOracle VM的ServerResource未来的ServerResource包agent-simulatorServerResource模拟与回归测试vmware-baseVMWare的ServerResource依赖包的依赖关系反应了CloudStack设计的重要性，因此不应该改变包的关系。ovm、vmware-base、agent-simulator和core是所有ServerResource基于cloud-api的实现，按照这种设计，这些包都不会访问数据库。cloud-agent是基于cloud-api的序列化和反序列化实现，但是理想情况下，cloud-agent仅仅作为容器并且应当基于cloud-util。未来CloudStack在未来会向上面这种结构进行转变，并且将API划分为以下三种：包作用格式cloud-api运行、管理、维护和配置(OAMP)、最终用户RESTcloud-plugin-api补充功能APIJavacloud-agent-api与ServerResource沟通APIJSON异常与日志CloudStack没有一个非常强大的异常与日志，不是我们只说不做，是因为我们并不擅长，不过我们一直努力在做好这些事情。日志CloudStack使用log4j进行日志记录，可以使用一些日志方案。虽然log4j很老，但是确实很好，并且真正重要的不是工具而是内容。CloudStack应当部署在INFO或者以上级别，并使用GMT标准时间。修改日志级别并不需要重启CloudStack，下面是推荐日志级别以供参考：级别何时使用FATAL服务宕机或者JVM宕机ERROR系统出现了不能修复的问题，但是不影响系统的运行，只会造成特定请求失败WARNING系统出现了问题，并且可以修复，管理员如果想了解，可以看看此类日志INFO管理员比较关注这些信息DEBUG此类信息有助于管理员调试问题，出现FATAL或ERROR信息时，可以打开DEBUG，以提供足够的信息调试问题TRACE重复并且讨厌的日志，不应该在正常调试中打开它，不过实在解决不了问题的时候可能有用异常和异常捕获下面是一些异常处理的示例：1、如果正在编写切入点代码，需要由你捕获所有异常（检查异常和非检查异常），并且妥善记录所有错误，你可以这样做：try {?c