Same Origin Policy, Cross Origin Resource Sharing (CORS) and JSONP

Reading Material

1. From Mozilla Developer Network
2. The “Same Origin” security policy
3. Cross-window messaging with postMessage
4. JSONP
5. Guide to Secure Implementation of HTML5′s Cross Origin Requests

CORS and Libraries

1. Using CORS
2. Filter for JEE
3. Client side library: easyXDM

XmlBeans: removing namespace attributes from the generated xml

• If you just have one namespace then follow steps here http://jaysonlorenzen.wordpress.com/index.php?s=xmlbean
• If you have multiple namespaces then above doesnt help. use the below code. it also removes namespace prefixes from attributes

public static void removeNamespaces(XmlObject root)
{
 String s;
 XmlCursor cursor = root.newCursor();
 cursor.toNextToken();
 while (cursor.hasNextToken())
 {
 if (cursor.isNamespace())
 {
 cursor.removeXml();
 }
 else
 {
 if (cursor.isStart() || cursor.isAttr())
 {
 s = cursor.getName().getLocalPart();
 cursor.setName(new QName(s));
 }
 cursor.toNextToken();
 }
 }
 cursor.dispose();
}

 

JMock – Lessons learned

• Expectations are asserted after the run of each test method
• Expectations are additive, so remember to call mock.reset() if you are planning to set a new expectation in each test method
• If u r using JUnit 4 and above then you no need to extend from MockObjectTestCase. You can use @RunWith(JMock.class). But that means we can not use other JUnit 4 runners like @RunWith(Parameterized.class). You can look into XJ4 (extensions for JUnit 4) project @ http://code.google.com/p/peachjean/wiki/XJ4 to see how it can help

JMock – mocking the same interface multiple times

A subject can have multiple addresses which i wanted to mock. but the below attempt throws the fololwing error
java.lang.IllegalArgumentException: a mock with name tokenizedUnitedKingdomAddress already exists

UnitedKingdomConsumerSubject primarySubj = context.mock(UnitedKingdomConsumerSubject.class);
TokenizedUnitedKingdomAddress currAddr = context.mock(TokenizedUnitedKingdomAddress.class);
TokenizedUnitedKingdomAddress prevAddr = context.mock(TokenizedUnitedKingdomAddress.class);
TokenizedUnitedKingdomAddress prevAddr2 = context.mock(TokenizedUnitedKingdomAddress.class);
 
primarySubj.setAddress(CURRENT, currAddr);
primarySubj.setAddress(FORMER, prevAddr);
primarySubj.setAddress(SECOND_FORMER, prevAddr2);

Seems like we have to use the overloaded method public T mock(Class typeToMock, String name). So the below fixed the error

TokenizedUnitedKingdomAddress currAddr = context.mock(TokenizedUnitedKingdomAddress.class, "current address");
TokenizedUnitedKingdomAddress prevAddr = context.mock(TokenizedUnitedKingdomAddress.class, "former address");
TokenizedUnitedKingdomAddress prevAddr2 = context.mock(TokenizedUnitedKingdomAddress.class, "2nd former address"

Handling Exceptions in Mule

Proper exception handling is a requirement of any integration application. Handling errors with Mule seems to be challenging for a beginner. So here i present various ways of dealing with exceptions to the best of my knowledge.

Note: check the hello example that comes bundled with mule. The below example is based upon that with little bit more explanation

Problem:

Send a friendly error message back to the user in case of any business exceptions

Solution:

In request-response MEP (Message Exchange Pattern), the service provider has to send a meaningful error message back to the service consumer when a business exception occurs. The suggested way of dealing with this scenario is to use Exception based filtering (payload-type-filter) in Mule.

MEP: Request-Response

Flow: Idea is to expose the existing BusinessService class over http so that it can receive requests through browser. I have written a NEW BusinessServiceUMO class that acts as a mediator between the requestor and BusinessService. If the BusinessService class throws an exception, BusinessServiceUMO catches it and returns the exception as the NEW payload. I have also configured a payload type filter on the outbound endpoint of BusinessServiceUMO to route the exceptions to UserErrorHandler service. UserErrorHandler service just returns a message contained in the exception and Mule sends this message as a response to the user using the response transformer. All this will be pretty clear if we go through the mule-config.

Usage:

• If invoked through http://localhost:9988/?name= URL, it throws a ValidationException
• If invoked through http://localhost:9988/?name=error URL, it throws a BusinessException
• If invoked through http://localhost:9988/?name=mule URL, it returns proper response

Important things to be noted w.r.t this example:

• BusinessServiceUMO returing exception itself as the payload
• synchronous=”true” on all the participating inbound endpoints enabling Request-Response MEP (so that the response is sent back to the caller)
• use of payload-type-filter
• use of responseTransformer-refs=”ExceptionToString” on the UserErrorHandler

Components:
BusinessService: Class implementing the business logic. This class can throw two kinds of exceptions: ValidationException and BusinessException. This class has no mule specific logic.

BusinessServiceUMO: receives input events from Mule and delegates the processing to

BusinessService.process(String req) method. This class has the logic specific to Mule. Look at how each of the exceptions are handled. For the payload-type-filter to work, the onEvent method should return the exception as the payload.

public Object onEvent(final Object req)
{
 Object payload = null;

 try
 {
  payload = service.process((String) req);
 }
 catch (BusinessException be)
 {
  payload = be;
 }
 catch (ValidationException ve)
 {
  payload = ve;
 }

 return payload;
}

UserErrorHandler: Important thing to note here is the responseTransformer-refs=”ExceptionToString”. All the transformer does is to return the message contained in the exception. Mule then takes this message and returns back to the browser as response

mule-config:

<spring:beans>
 <spring:bean id="businessService" class="com.aravind.mule.errorhandling.BusinessService" />
 <spring:bean id="businessUMO" class="com.aravind.mule.errorhandling.BusinessServiceUMO">
 <spring:property name="service" ref="businessService"></spring:property>
 </spring:bean>
</spring:beans>

<!-- Global Transformers -->
<custom-transformer name="HttpRequestToString" class="org.mule.example.hello.HttpRequestToNameString" />
<custom-transformer name="ExceptionToString" class="com.aravind.mule.errorhandling.ExceptionToString" />

<model name="my-service-model">
 <service name="BusinessService">
 <inbound>
 <http:inbound-endpoint address="http://localhost:9988"
 transformer-refs="HttpRequestToString" synchronous="true">
 <not-filter>
 <wildcard-filter pattern="/favicon.ico" />
 </not-filter>
 </http:inbound-endpoint>
 </inbound>
 <component>
 <spring-object bean="businessUMO" />
 </component>
 <outbound>
 <filtering-router>
 <vm:outbound-endpoint path="userErrorHandler" />
 <payload-type-filter expectedType="java.lang.Exception" />
 </filtering-router>
 </outbound>
 </service>

<!-- User error handling returns an error message to the end user -->
 <service name="UserErrorHandler">
 <inbound>
 <vm:inbound-endpoint path="userErrorHandler"
 responseTransformer-refs="ExceptionToString" synchronous="true" />
 </inbound>
 </service>
</model>

– My Country, My People

Installing cURL and SSL on Windows 7

Download and Install

1. Download and unzip 64-bit cURL with SSL.
2. Download the latest bundle of Certficate Authority Public Keys from mozilla.org.
3. Rename this file from cacert.pem to curl-ca-bundle.crt
4. Make sure both of them are in the PATH environment.

Test: curl -L https://www.google.com

Scientific reason on visiting Temples

I’m not into idol worship (and hence refrain from visiting temples as much as I can) and believe that the real essence of visiting a temple is different from the usual explanations (excuses) I hear. I’ve been searching over internet for a while and fortunately found the scientific explanation behind the Temple construction, Prasadam, Teertham etc. which I am copy/pasting verbatim. I fully disclose that the following material is research of someone else which I am (shamelessly) copy/pasting to my blog for my own future reference and for the benefit of others. If someone know the true authenticity of this material, kindly share it with me so that I can give full credit to them.

———————————————————————————————————————————-

There are thousands of temples all over India in different size, shape and locations but not all of them are considered to be built the Vedic way. Generally, a temple should be located at a place where earth’s magnetic wave path passes through densely. It can be in the outskirts of a town/village or city, or in middle of the dwelling place, or on a hilltop. The essence of visiting a temple is discussed here.

Now, these temples are located strategically at a place where the positive energy is abundantly available from the magnetic and electric wave distributions of north/south pole thrust. The main idol is placed in the core center of the temple, known as Garbhagriha or Moolasthanam. In fact, the temple structure is built after the idol has been placed. This Moolasthanam is where earth’s magnetic waves are found to be maximum. We know that there are some copper plates, inscribed with Vedic scripts, buried beneath the Main Idol. What are they really? No, they are not God’s / priests’ flash cards when they forget the shlokas. The copper plate absorbs earth’s magnetic waves and radiates it to the surroundings. Thus a person regularly visiting a temple and walking clockwise around the Main Idol receives the beamed magnetic waves and his body absorbs it. This is a very slow process and a regular visit will let him absorb more of this positive energy. Scientifically, it is the positive energy that we all require to have a healthy life.

Further, the Sanctum is closed on three sides. This increases the effect of all energies. The lamp that is lit radiates heat energy and also provides light inside the sanctum to the priests or poojaris performing the pooja. The ringing of the bells and the chanting of prayers takes a worshipper into trance, thus not letting his mind waver. When done in groups, this helps people forget personal problems for a while and relieve their stress. The fragrance from the flowers, the burning of camphor give out the chemical energy further aiding in a different good aura. The effect of all these energies is supplemented by the positive energy from the idol, the copper plates and utensils in the Moolasthanam / Garbagraham. Theertham, the “holy” water used during the pooja to wash the idol is not
plain water cleaning the dust off an idol. It is a concoction of Cardamom,Karpura (Benzoin), zaffron / saffron, Tulsi (Holy Basil), Clove, etc…Washing the idol is to charge the water with the magnetic radiations thus increasing its medicinal values. Three spoons of this holy water is distributed to devotees. Again, this water is mainly a source of magneto-therapy. Besides, the clove essence protects one from tooth decay, the saffron & *Tulsi* leafs protects one from common cold and cough, cardamom and Pachha Karpuram (benzoin), act as mouth fresheners. It is proved that Theertham is a very good blood purifier, as it is highly energized. Hence it is given as prasadam to the devotees. This way, one can claim to remain healthy by regularly visiting the Temples. This is why our elders used to suggest us to offer prayers at the temple so that you will be cured of many ailments. They were not always superstitious. Yes, in a few cases they did go overboard when due to ignorance they hoped many serious diseases could be cured at temples by deities. When people go to a temple for the Deepaaraadhana, and when the doors open up, the positive energy gushes out onto the persons who are there. The water that is sprinkled onto the assemblages passes on the energy to all. This also explains why men are not allowed to wear shirts at a few temples and women are requested to wear more ornaments during temple visits. It is through these jewels (metal) that positive energy is absorbed by the women. Also, it is a practice to leave newly purchased jewels at an idol’s feet and then wear them with the idol’s blessings. This act is now justified after reading this article. This act of “seeking divine blessings” before using any new article, like books or pens or automobiles may have stemmed from this through mere observation.

Energy lost in a day’s work is regained through a temple visit and one is refreshed slightly. The positive energy that is spread out in the entire temple and especially around where the main idol is placed, are simply absorbed by one’s body and mind. Did you know, every Vaishnava(Vishnu devotees), “must” visit a Vishnu temple twice every day in their location. Our practices are NOT some hard and fast rules framed by 1 man and his followers or God’s words in somebody’s dreams. All the rituals, all the practices are, in reality, well researched, studied and scientifically backed thesis which form the ways of nature to lead a good healthy life.

The scientific and research part of the practices are well camouflaged as “elder’s instructions” or “granny’s teaching’s” which should be obeyed as a mark of respect so as to once again, avoid stress to the mediocre brains.

———————————————————————————————————————————-

My Country, My People

Click this link to visit the 17th century paintings of Ramayana preserved by the British Library. On the opened window, select Ramayana and then select 2nd option of using Silverlight.

How Google Tests Software key points

I have pre-ordered the How Google Tests Software hoping that it would be as good as a read as How We Test Software at Microsoft. I have completed reading in a week and I didn’t see any common content. Both books talk about different things and How We Test Software at Microsoft is still my favorite. While How We Test Software at Microsoft identifies various formal techniques or approaches for testing, the How Google Tests Software is more about the Google perspective of quality assurance, how it is different and why they approached it that way. It has lots of interviews with the Google’s TD (Test Director), TM (Test Manager), TE’s (Test Engineer), SET’s (Software Engineer in Test) and SWE’s (Software Engineer). Anyways below are some of the key take aways

1. Quality is everyone’s responsibility.
2. Hiring practices should change so that resources with programming skills are hired.
3. Automate wherever possible so that most of the resource time can be spent testing usability etc.
4. Exploratory testing and crowd sourcing.
5. Software can never be bug free so release often to limited user base for better feedback.
6. Author tests in the language the application is written.
7. Do not enforce enterprise wide standards as that would limit innovation. (But I believe this is only true for companies whose hiring practices makes sure that skilled resources are hired).
8. Opportunity given to resources to work 20% of their time on the projects they are passionate about.
9. Open rotation policy. Resource is free to move to any project within Google after 18 months.
10. New hires encouraged to start with testing.
11. And of course continuous integration.

Programmer Fun

My Country, My People (Jhansi Fort in 1857)

JEE and Class loaders

This is my first attempt on technology blogging and I start with my favorite – the class loader. There is a lot of information out there on J2SE class loaders, their delegation model etc but there is very limited information on the JEE class loader delegation models like PARENT_LAST and PARENT_FRIST that you typically see in the application servers. Are these standardized by spec?

After going through the JEE spec and few articles on internet (It has been a while since I did this research and couldn’t remember the article names), below is the summarized answer.

EAR

The spec DOES NOT define or mandate how the class loaders should work within an EAR. It however defines that

• There SHOULD be a per thread context class loader for runtime loading of classes
• There MIGHT be a hierarchical class loading mechanism for resolving classes (app server vendors are free to implement whichever way they choose to)
• The top-level class loader (WAR/EAR) MAY delegate to the low-level class loaders (like Bootstrap, extension etc). This is in compliance with J2SE class loader delegation model (PARENT_FIRST in WAS)

WAR

• Servlet specification defines and mandates the support of a PARENT_LAST (i.e. WAR/web-inf/classes and WAR/web-inf/lib take precedence over the libraries that come with the app server) class loading model. But this is just for WAR modules.
• The Servlet spec diverges from the standard J2SE delegation model of PARENT_FIRST in this case.

App Server specific details

Interestingly, though, it appears most major app servers support some mechanism of turning off delegation to isolate the application from the app server if necessary (because of conflicts or otherwise):

• WebSphere – “parent-last”
• GlassFish – <class-loader delegate="false" /> in sun-web.xml
• JBoss – java2ParentDelegation=false
• Geronimo - <java2-delgation-model>false</java2-delegation-model>
• WebLogic – ???

Reference

1. Spec: Servlet 2.3, Section: 9.7.2 Web Application Classloader
2. Spec: JEE 5, Section: EE.6.2.4.7 Context Class Loader

Programmer Fun

• Google for “recursion” or click here. Did you mean: recursion
• Google for “ascii art” or click here. Check their logo.

Google is witty that way

My Country, My People