Shiro Realm Annotation Failure Problem resolution process

As a veteran of the. NET eight or nine years of oil, moved to Java time is not long, just started to do the project is based on C # knowledge to do, although encountered some problems, but the actual results show that C # language and Java still have a great similarity, and Microsoft's MVC and Spring MVC is also the same spirit, which is why I do not have a systematic study of Java is also able to do project reasons. Recently a little bit of free time, so decided to start from the basis of the system to learn Java, there is not much advanced technology to share, this article to share my problem-solving experience: comprehend by analogy or called extrapolate, on the other, for the existence of the parts can be optimized to give up.

Problems that haunt you for a long time:

The application of Shiro in the project to authenticate login rights, the annotation service in the realm implementation class is unsuccessful, the resulting instance is null. There are a lot of similar problems on the Internet, maybe everyone's project is different, I did not get the correct solution from it.

Private Isecurityservice Securityservice;

There are two ways to solve this:

• Obtaining instances dynamically through ApplicationContext

Private isecurityservice securityservice;     Private void Initsecurityservice () {        if (nullthis. Securityservice) {            = Applicationcontextutils.getapplicationcontext ();             this. Securityservice = Appctx.getbean (isecurityservice.  Class);        }    }

• With static attribute annotations, this method can be used to debug whether spring has commented on this property. Why are the variables in the following code static? When it is not a static type, the debugging process is indeed annotated, and the annotations are successful, but when the program executes, Shiro gets the instance null, not the previously annotated instance, which modifies the variable to be static and then runs successfully.

Private Static Isecurityservice Securityservice;    @Autowired    publicvoid  setsecurityservice (Isecurityservice securityservice) {        = securityservice;    }

The above two kinds of writing are more disgusting, but at that time for the Spring class scan do not understand, can only do. In the case of insufficient knowledge, if blindly go to drill may not necessarily have the perfect result, so I choose to give up temporarily.

The project encountered a situation where the use of a database transaction did not take effect, when the colleague's explanation was a spring scan problem, and the controller could not be scanned when the transaction configuration was loaded. Then there was time to study, because we used spring MVC, and the very classic application context +dispatcherservlet context structure was used in Web. Xml. And the interesting thing is we didn't give application context configuration information about resource scanning and bean loading, only one Shiro configuration file is loaded, The result is that all of the bean loads in the project are concentrated in Dispatherservlet, the MVC configuration file.

There is also said that if there is only one servlet, then you can choose to use only one context, which can also avoid the mistake of using the parent context of the problem, this practice I have not tried, have time to study.

What is application context?
It is a context of degree of application, and one of the important functions of this context is to provide access to database transactions, data layers, and other requirements that you want to access through the application (which may be described here as inaccurate, interested in the official website to see the document). For example, in the above method, the fetch bean is obtained dynamically through this context object.

What is Dispatcherservlet context?
An application can define multiple servlets, each of which has its own context, and there is only one servlet in our project.

Application context and Dispatcherservlet context relationship?
The parent of the Dispatcherservlet context is the application context, which inherits all the content defined by the application context. Two posts are recommended here, which is quite clear.

1. http://stackoverflow.com/questions/3652090/ Difference-between-applicationcontext-xml-and-spring-servlet-xml-in-spring-frame
2. http://stackoverflow.com/questions/18578143/about-multiple-containers-in-spring-framework/18580299#18580299

Why can't I scan the controller before loading the database transaction configuration? This I do not know the reason for the details, only probably know that is the spring design rule problem, Dispatherservlet if the database transaction configuration before the load scan the namespace containing the controller in the class, the result is that the transaction does not have the transaction capability. So we have two scan code in the Dispatherservlet configuration file:

• Scan only the controller first

 <  context:component-scan  base-package  = "Cn.wanmei.party"   = "false"  >  <  context:include-filter  Span style= "color: #ff0000;" >expression  = "Org.springframework.web.bind.annotation.Controller"  Span style= "color: #ff0000;" > type  = "annotation"  />  </ context:component-scan  > 

• 。。。。。 Scan Load Other configurations
• Load the database configuration, due to the existence of the transaction, here in the scan need to remove the service scan, to avoid the second repeat scan to produce unpredictable results.

<Context:component-scanBase-package= "Cn.wanmei.party">        <Context:exclude-filterexpression= "Org.springframework.web.bind.annotation.RestController"type= "Annotation"/>    </Context:component-scan>    <ImportResource= "Mybatis.xml"/>

The previous practice of writing almost all configurations in the Dispatherservlet configuration file has drawbacks:

• Overhead the Root-context configuration file that was originally configured for application context (only one Shiro configuration file, with no bean loading related content)
• Transferring the things that belonged to application context to Dispatherservlet will cause scanning problems.
• The configuration is complicated, and my personal opinion is that dispatherservlet as much as possible is related to the servlet itself, while the database configuration is best placed in the Root-context application level configuration

Most of the above is a description of the issue of the transaction does not take effect, and that I mentioned in the realm implementation class through the Autowired annotation service failure What is the connection? As mentioned earlier, one of the main functions of application context is to provide applications with access to transactions, data layers, and other class instances, so the annotation instances that provide classes in the realm implementation class are within the scope of responsibility, and for this we need to make changes to the configuration file:

• Root-context, add packet Scan, transfer database configuration to come in

 <Context:component-scanBase-package= "Cn.wanmei.party">    </Context:component-scan>     <ImportResource= "Mybatis.xml"/>     <ImportResource= "Redis-context.xml"/>    <ImportResource= "Spring-shiro-web.xml" /> 

• Dispatherservlet: Only the servlet-related configuration is loaded and the scan of the service needs to be removed on the scanning class configuration to avoid two scan problems.

 <  context:component-scan  base-package  = "Cn.wanmei.party"  >  <  context:exclude-filter  Span style= "color: #ff0000;" >expression  = "Org.springframework.stereotype.Service"   type  = "annotation"  />  </ context:component-scan  > 

After resolution:
1:root-context is full.
2:application Conext has a job, a business, something.
3:dispatherservlet's configuration is refreshing.

After testing, the transaction is normal, the annotations in realm are normal, and no longer need to use the two disgusting ways mentioned before the text. This article through the project does not take effect the question, Lenovo to the realm realization class annotation failure and the existence association, finally through the practice further confirms the speculation, also further understood the spring the context knowledge.

Shiro Realm Annotation Failure Problem resolution process