SpringParadigm

This time I will share my experience with AspectJ. Aspects evolve for the separation of cross cutting concerns from the business logic. The cross cutting concerns evolve Logging,Transaction Management,Security Concerns etc. i.e. anything that is not inherently related with Business Logic. For implementing aspects we need to know about AspectJ programming syntax, which are not exact replica of java files but almost similar and follows all oops concepts. The source files are with extension .aj and the source files are compiled to .class files(in exact bytecode format like normal java class files) by the AspectJ compiler so that any JVM can execute the compiled aspects. Whenever we talk about aspects one term always comes to our mind that is WEAVING . Aspects are woven into the source code at 1) Compile time (Compile Time Weaving) 2) Load Time (Load Time Weaving) 3) Run Time (Th...

Here, I will provide STAX parsing Outline. STAX is streaming parsing API. Now the question arises, that why should we use STAX, instead of DOM,SAX,JAXP (well known tools for working with the XML infosets) and other XML parsing API's, what extra benefit does STAX provides us, so here it is: 1) StAX is a streaming PULL-PUSH parsing java API for reading and writing XMLs. 2) StAX API is a set of interfaces providing a framework for bi-directional parser. It provides two sets of APIs, cursor and iterator based. 3) Unlike DOM it doesn't load the entire Document tree in the memory(i.e. In Memory Objects), but it uses the Streaming Architecture just like File Streaming and thus reducing memory footprint. 4) Like JDBC StAX is a standard, and there are different implementations confirming to those standards like stax.codehaus, sjsxp,woodstox etc. 5) The Streaming API provides us with advantage of reading and writing large XML documents sequentially, performing operat...

Service Ticket Validator is used by the Application(Spring here) for validating the ticket as provided by CAS to the application during login (Cross Verification). For my own understanding  and to implement Custom features as applicable I have implemented custom Ticket Validator. Every Ticket Validator must implement TicketValidator interface, which contains a single validate method and it returns a Assertion. In the validate() method, we contruct the validation URL from the ticket(to be validated by the application) as returned by the CAS server during login and the CASService properties. Now using the Valdation URL as constructed above and the ticket(to be validated by the application) as returned by the CAS server during login, response is retrieved from the server. The response is in XML format. The response is then parsed to create an object of type Assertion, which is returned from the validate() method. The custom attributes if configured through Attribute Re...

In this blog I will share my experience with Credential to Principal Resolver of CAS. After the user has been successfully authenticated by the Custom Authentication Handler (as provided in the previous blog), then there comes the Credential to Principal Resolver of CAS. Now before going into the architecture of Credential to Principal Resolver of CAS we have to get some idea regarding AuthenticationManager of CAS which corresponds to bean id "authenticationManager" and class "org.jasig.cas.authentication.AuthenticationManagerImpl" of the deployerConfigContext.xml of CAS war. This authenticationManager at first lopps through all the registered list Authentication Handlers configured in the deployerConfigContext.xml holding the property name "authenticationHandlers" of the bean "authenticationManager" to get the user authetication and then it loops through all the registered list of Credential to Principal Resolver configured in the d...