Liferay Code Analysis and extension--User Service

Liferay Code Analysis and extension--User Service

Reprint please retain the author information:

Author: 88250

blog:http:/blog.csdn.net/dl88250

MSN & Gmail & qq:dl88250@gmail.com

Directory

Summary 1

Environment 1

Import Project 1

User Service Analysis 3

User Service Extension 3

Problem Description 4

Solution Analysis 4

Solution 1 4

Solution 2 4

Final Scenario 4

Step 4

Summary 8

Summary

See a few days liferay, because to and other systems integration, so analyzed the Liferay User Service code. The main design ideas of some liferay can be seen from their user Service code, which will prepare for the future analysis of his architecture design. Environment

Click here to download Liferay5.1.1 source code

NetBeans IDE 6.1

Import Project

Liferay5.1.1 is an ant project built in NetBeans, which can be opened directly in NetBeans after the source code is unpacked. Its engineering view is as follows:

Let's briefly describe the source code directory (without the test directory).

Portal-impl

Contains all the service implementation code, such as basic user management, mail Service, Content management (cms,jsr170)

Portal-service

Includes all service interfaces for Portal-impl

Portal-kernel

Includes the Portal/portlet specification implementation (JSR 168/268), as well as basic framework management (Struts, Spring), and basic implementations of deployment, configuration, Search, WebService, and persistence

Support-glassfish/tomcat

Support implementation for GSF/TOMCAT container

Util-bridges

Support for some framework/language authoring portlets. Currently we can write portlets using the following language/framework:

Bean Scripting Framework (BSF)

Groovy

Javascript

Jsf

Jsp

Php

Python

Ruby

Struts

Web Accessibility Initiative (WAI)

Util-java/taglib

Liferay use of basic utilities and tag library to implement User Service analysis

Currently, the Liferay project is written with struts1.2.x + Spring 2.0 as the basic framework. Its architectural design is clear, it is a rare example of learning design. Below, enter the topic of this article--User Service analysis.

In the directory Portal-service expand the source package Com.liferay.portal.service, you can see a series of ****service interfaces. We identify the user-related, and we can derive the following class dependency graphs:

From the top two interfaces, Liferay in the User Service design and ejb3.x ideas are consistent, divided into the local interface and remote interface, from the code annotation can also get this. In the current version of Liferay (5.1.1), the service is properly processed in the remote interface to the right of the diagram and delegated to the local implementation on the left side of the diagram. Other key areas please refer to the Description section of the diagram.

User Service Extensions

This is not so much an "extension" as a "modification".

When the portal integrates with other systems, the first difficult problem is user management. Here said the user management can be simply divided into two types of management: Identity authentication, account management. Questions about identity authentication you can use the CAS (the authentication Service) to implement SSO (single sign-on/out) between systems, which you can refer to here and here. Account management is currently the most headaches, the specific problem described below: problem description

For example: If admin in the portal Liferay set up an account number, the rest of the system should also establish a user account, if the user changed the password in the portal, the user in the rest of the system account password should also be modified, on the contrary is not true. Solution Analysis

Combined with the previous User Service analysis class diagram, you can draw the following two scenarios: Solution 1

Inherit the Userlocalserviceimpl class and add the functionality we need.

Advantages: Later Liferay updated the code, the functionality we need does not affect, there is basically no cost of code consolidation.

Disadvantage: To modify the spring configuration file, change the reference to the Userlocalserviceimpl bean to our implementation bean configuration. Solution 2

Directly modify the Userlocalserviceimpl class code to delegate the required functionality to our implementation.

Benefits: You do not need to modify the spring configuration file.

Disadvantage: Later Liferay updated the code, there is a certain combination of code costs. Final Solution

To sum up, weigh down. I think the use of solution 2. Because I think the cost of modifying the code for subsequent upgrades is less than the cost of modifying the configuration file. So, rather than being "extended", it is "modification":

Steps

To add a user as an example:

Open the Com.liferay.portal.service.impl.UserLocalServiceImpl class, find the AddUser method, and at the end of this method join our implementation delegate:

Unusing Spring DI, now, just to simple. by 88250, Aug, 2008 New Subsystemuserserviceimpl (). RegisterUser (FirstName, LastName, EmailAddress, screenname, pass WORD1);

Spring's di is not used here, just for simplicity, without modifying the configuration file. Spring DI may be used later.

The following is the implementation of our required services:/*  * To change this template, choose Tools |  Templates  * and open the template in the editor.  */package com.jinfonet.developer.portal.service.impl; import com.liferay.portal.portalexception; import com.liferay.portal.security.pwd.pwdencryptor; import java.io.ioexception; import java.sql.connection; import java.sql.drivermanager; import java.sql.resultset; import java.sql.sqlexception; import java.sql.statement; import java.util.logging.level; import java.util.logging.logger; import org.apache.commons.httpclient.httpclient; import org.apache.commons.httpclient.httpexception; import org.apache.commons.httpclient.namevaluepair; import org.apache.commons.httpclient.methods.postmethod; import org.apache.commons.logging.log; import org.apache.commons.logging.logfactory; /**  * subsystem  User service utility. currently, this class is mainly for  *  update coherence of user accounts existed in some subsystems ( SCARAB,&NBSP;SVN,  * etc.).  *  @author  88250 <DL88250@gmail.com>  *  @version  1.0.0.2, sep  2, 2008  */public class subsystemuserserviceimpl {    //  TODO places all properties in a configuration file, no  Hard-coding     private final String driver =  " Com.mysql.jdbc.Driver ";     private final String dbURL =  "jdbc:mysql:// 192.168.128.122:3306/scarab ";     private final String dbUserName =  "Root";     private final String dbUserPwd =  "SA";     private connection con = null;     private static log log = logfactory.getlog ( Subsystemuserserviceimpl.class);     private final String REGISTER_URL =  "Http://daniel-desktop : 9090/scarab/issues/template/autoregister ";     /**      * default constructor.      *  @throws  com.liferay.portal.portalexception       */    public subsystemuserserviceimpl ()  throws portalexception {         try {             class.forname (driver);         } catch  (Classnotfoundexception ex)  {             log.error (ex);            throw new portalexception (ex );              }     /**       * changes user ' S password in all subsystems.      *  @param  userName user name        *  @param  newpwd the new password (clear text)       *  @throws  PortalException       */    public  Void changepassword (STRING&NBSP;USERNAME,&NBSP;STRING&NBSP;NEWPWD)  throws PortalException  {        updatepassword (username, newpwd);     &NBSP}     /**      * registers a new user  in all Subsystems.      *  @param  firstname first name      *   @param  lastname last name      *  @param  emailaddress  email adress      *  @param  screenname user name       *  @param  password user password      *   @throws  PortalException       */    public  Void registeruser (string firstname, string lastname, string emailaddress,              String screenName, String  Password)  throws portalexception {        adduser ( Firstname, lastname, emailaddress, screenname, password);     }   &nbSp; private void adduser (string firstname, string lastname, string  EmailAddress,             string screenname,  string password)  throws portalexception {         httpclient httpclient = new httpclient ();         postmethod registermethod = new postmethod (Register_url);         namevaluepair[] data = {             new namevaluepair ("FirstName",  firstName),             new namevaluepair ("LastName",  lastname),             new namevaluepair ("email",  emailaddress), &NBSP;&NBSP;&NBSP;&NBsp;        new namevaluepair ("UserName",  screenname),              new namevaluepair ("Password",  Password),         };   &