2021SC@SDUSC

在之前的4篇文章中，我对openmeetings项目的core目录进行了分析，完成了converter、data、documents、ldap、notifier、rss、util目录的分析，还剩下mail、remote、service这三个目录没有分析。本篇文章将会结束core模块的分析，然后对整个项目中我负责的core、db两个模块进行总结。

目录

mail目录

目录结构

MailHandler.java

service目录

目录结构

RecordingService.java

MainService.java

remote目录

总结

mail目录

mail目录是关于邮件，或者通信，这方面的功能。

目录结构

mail目录下只有一个java文件，是MailHandler.java。

MailHandler.java

MailHandler的意思是对mail进行操作。看其引入的内容：

第一部分引入的内容比较多。首先引入了UTF_8，后面引入的都是util模块下的常量和方法。都已经见过很多次了，不再多说。

第二部分引入了java的io方面的类和工具类，例如ByteArrayInputStream、IOException、List等。

第三部分引入的是javax.mail下面的类，它们主要是用来发送邮件的。

---

关于mail，作以下简要说明（参考自博文使用javax.mail发送邮件详解_fsy9595887的博客-CSDN博客）：

1、

RFC882文档规定了如何编写一封简单的邮件(纯文本邮件)，一封简单的邮件包含邮件头和邮件体两个部分，邮件头和邮件体之间使用空行分隔。

　　邮件头包含的内容有：

1. from字段 　　--用于指明发件人
2. to字段 　　    --用于指明收件人
3. subject字段  --用于说明邮件主题
4. cc字段 　　   -- 抄送，将邮件发送给收件人的同时抄送给另一个收件人，收件人可以看到邮件抄送给了谁
5. bcc字段 　　 -- 密送，将邮件发送给收件人的同时将邮件秘密发送给另一个收件人，收件人无法看到邮件密送给了谁

　　邮件体指的就是邮件的具体内容。

2、

      在我们的实际开发当中，一封邮件既可能包含图片，又可能包含有附件，在这样的情况下，RFC882文档规定的邮件格式就无法满足要求了。

　　MIME协议是对RFC822文档的升级和补充，它描述了如何生产一封复杂的邮件。通常我们把MIME协议描述的邮件称之为MIME邮件。MIME协议描述的数据称之为MIME消息。
　　对于一封复杂邮件，如果包含了多个不同的数据，MIME协议规定了要使用分隔线对多段数据进行分隔，并使用Content-Type头字段对数据的类型、以及多个数据之间的关系进行描述。

3、

JavaMail创建的邮件是基于MIME协议的。因此可以使用JavaMail创建出包含图片，包含附件的复杂邮件。

4、

所以，在这里引入activation和mail的相关类是为了发送邮件。 

---

最后一部分引入的有db模块下的数据访问对象类和实体类，util模块下关于发送邮件的工具类，字符串处理的类，red5工厂类，日志类，以及spring相关的注解。

看类的定义：

定义的字段很多。前面的三个包括了log，以及定义的两个常量MAIL_SEND_TIMEOUT（发送邮件最长的时限，超过这个时限可能认为发送失败）、MAXIMUM_ERROR_COUNT（最大的错误次数）。然后定义了ConfigurationDao cfgDao、TaskExecutor taskExecutor、MailMessageDao mailMessageDao，是数据访问对象和任务执行对象。最后一部分定义的是邮件的基本信息，比如from是发送方等，不再细说。

下面定义了两个init方法。第一个init方法没有形参，直接通过包含了配置信息的cfgDao对各项信息进行初始化；第二个init方法传入了形参，则根据形参进行初始化。

然后重载了两个appendBody方法，第一个调用了第二个，先分析第二个。它们都是完成对邮件体的设置。

第二个appendBody方法的形参是MimeMessage msg、String body。在方法体内，首先通过msg.setDataHandler，对邮件的主题和正文文字的设置。然后设置了头部信息以及日期，最后返回msg。

第一个appendBody方法传入的形参是MimeMessage msg、MailMessage m，调用第二个方法的时候需要传入的是msg和m.getBody()，即通过MailMessage的邮件体来初始化msg的内容。

继续向下看：

然后定义了getBasicMimeMsssage方法，获取邮件的基本信息。返回值类型是MimeMessage。在方法体内，首先通过log输出了控制信息。然后判断，如果smtpServer为null，这意味着还没有初始化，因此调用init方法进行初始化。然后使用默认的初始化方式定义了Properties对象props。

在props中put了若干信息，包括mail.smtp.host、mail.smtp,port、mail.smtp.connectiontimeout等。下面为了身份验证，建立一个session，如果mailAuthUser和mailAuthPass都非空，则在props中put进mail.smtp.auth为true，且使用session保存props；否则，意味着不使用smtp身份验证，则在session中的props保存为null。最后建立MimeMessage，使用session初始化它，最终返回msg。

继续看：

定义了getMimeMessage方法，传入的参数是MailMessage m。它的作用是获取邮件消息的信息。在方法体内，首先调用了getBasicMimeMessage()，保存为msg，然后通过m给msg设定主题、回复方等基本信息。最后通过一系列验证，以及为m添加邮件体，最终返回。

下面重载了3个send方法，其中前两个都调用了第三个。那么先看第三个：

send方法的形参是MailMessage m和boolean send。方法体内，首先判断send。如果send为true，则判断m的id是不是null，如果不是null，则设置m的状态为Status.SENDING，并且使用mailMessageDao.update进行更新。然后就可以使用任务执行器执行发送任务了。其中用到的类有Transport，它是javax.mail提供的可以完成发送邮件的类。还设置了m的状态是Status.DONE。当然，这里仍然使用了try-catch结构。

如果send为false，则设置m的状态是Status.NONE。

至此，MailHandler.java已经分析完毕。它完成的是对邮件的信息设置、修改以及发送的过程。

service目录 目录结构

service目录下面只有两个java文件：MainService.java和RecordingService.java。

RecordingService.java

RecordingService的意思是记录服务，也就是对会议中的视频、音频等进行记录。看其引入的内容：

首先引入了之前分析过的baseConverter类中的printmetaInfo方法，还有getWebAppRootKey()。然后引入了Date、Map、UUID等工具类。

下面又引入了converter、listener类的一些方法，还有db模块、util模块下的类和方法。最后导入的就是red5相关的类和方法了。

看类的定义：

首先定义了log。然后下面定义了一个Map类对象streamListeners。注释说明，它的作用是存储所有我们需要的监听器的引用，防止用户关闭浏览器时使red5数据流对象丢失。

下面就是用@Autowired注解定义了一系列字段，像IStreamClientManager streamClientManager、IClientManager clientManager、UserDao userDao等，都是之前分析过的数据类型。

继续看：

下面出现了static方法generateFileName(Long recordingId,String streamid)，通过它来产生一个字符串，这个字符串包含了recordingId、streamid以及日期信息。

下面是startRecording方法，也就是开始记录。在里面，首先新建Recording对象recording，并且设置recording的相关信息，包括其名称、类型、roomId等。

然后就是继续设置recording的相关信息，并且获取客户产生的所有数据流，并且对它们开启记录。

最后就是通知所有的用户，记录已经开始了。方法仍然采用了try-catch语句，在catch中捕获了异常。

再下面的stopRecording方法，则与startRecording方法正好相反，最终停止记录。其中的逻辑都是相似的，因此不再多提。

下面又提供了两个方法addListener和removeListener，分别是对特定的连接添加和移除监听器。以addListener为例：

在方法体内，对当前的广播数据流进行了获取，并且保存为一个引用stream。如果stream为空，则直接返回。否则，则保存这个数据流到硬盘，并且为stream添加一个StreamListener。逻辑并不复杂，所以就不再分析removeListener。

MainService.java

MainService的意思是主要的服务。看其引入的内容：

导入的内容都比较熟悉了，包括db模块下的AppointmentDao、Appointment、MeetingMember类等。最后还有red5的工厂类、日志类、spring的注解等。

看类的定义：

定义了log，还有AppointmentDao appointmentDao。最后是一个字符串常量EXTERNAL_USER_TYPE_LDAP="LDAP"，注释告诉我们这是外部用户的类型。

然后是checkAppointment方法，传入的形参是Appintment a、User u。如果a不存在或者已经被删除了，那么返回false。如果a的owner的id与u的id是一样的，这意味着u就是owner，则返回true。如果a的会议成员中有人的id与u的id相等，则返回true。否则，返回false。它的作用就是检查User u是否参与了Appointment a。

下面的两个方法是checkGroups和isRoomAllowedToUser。思路与checkAppintment相同，都是监测用户u是否参与了，不再多说。

至此，service目录分析结束。它通过MainService和RecordingService两个java文件，完成了会议的记录以及对用户是否参与某个事务的检查。

remote目录

remote是远程，它的作用应该是进行远程操作的控制。

remote目录下只有两个java文件：

 

观察其代码发现，它的实现逻辑包含了对连接到服务器的客户端的检查配置、添加用户、监测状态、获取房间、发送消息等，在之前分析core模块下代码时都走过了这个流程，例如刚才的RecordingService中的相关逻辑。因此关于remote目录的内容就不再详细分析了。

总结

到现在，已经结束了core模块的全部源码分析。在core模块中，完成了数据格式的转换、文件处理、LDAP、邮件、消息、系统服务流程等的处理，这些功能都是比较核心的，因此叫core目录。通过core目录的分析，我了解到了LDAP、java操作邮件发送、java操作websocket等相关的知识，也进一步理清楚了系统的结构框架，收获满满。

同时，到这里，我也已经完成了openmeetings项目中我负责的db模块和core模块的全部源码分析。回忆一下，db模块主要是对数据模型的处理及其与系统的交互。在整个队内，我负责的源码量相对来说是比较多的，难点同时也比较多，但在这个过程中我学习到了许多java、maven相关的知识。由于项目在网络上的资料很少，许多问题以自己的能力和时间状况还是很难解决的，所以在分析的历程中也留下了不少的坑。

回看13篇博客，记录了我分析源码的一些心得体会，也记录了几个月以来的努力。希望在软件工程应用与实践这门课程中的分析源码经历，能够对我以后阅读优秀项目代码的能力有所提升，也能够运用从中见到的技术，让自己的项目得开发更加优秀。