Week 11 – Back to Controller

Week 11 – Back to Controller

So last week, I was having some troubles with integrating the Client Management REST controller into the module. The troubles were about managing the entry point for the URL mapping. Finally, me and my mentor Mayank decided to do it the way IETF (Internet Engineering Task Force) describes. Like the document here and also manage the client dynamically using protocols defined here.

So I’ve implemented the process using the standards defined by IETF.

Next Problem ? (Because there’s always one  😛 )

 org.codehaus.jackson.map.JsonMappingException: Direct self-reference leading to cycle (through reference chain: java.util.ArrayList[0]->org.openmrs.module.oauth2.Client["creator"]->org.openmrs.User["creator"])

The client class inherits fields like “creator” and “voided” from the BaseOpenMRSData which in turn inherits org.openmrs.User. This leads to a recursive cycle and causes a Jackson JsonMappingException.

Meaning? We simply can’t return OAuth client objects and expect Jackson to convert them into JSON (like it’s supposed to)

Fix? Convert your objects into JSONObjects manually using JSON classes and then send them with the appropriate Http Message.

Progress on SMART ?

As mentioned in the last week’s blog post, the next piece of business was supposed to be SMART. I worked and researched a lot on SMART. SMART on FHIR is a use-case for the module and it’s highly necessary that it is completed in this year’s GSoC.

My initial plan was to use the SMART on FHIR sample JS application and modify it to our needs. However after spending lots of time on 17000 and so lines of code on the fhir-client.js it turns out the app was designed only to be run against their own sandbox server 🙁

So the work on SMART is put on hold for now and further work will be done after a call with my mentor (The call is scheduled for 15th Aug 9:30 pm IST).

 

Leave a Reply

Your email address will not be published. Required fields are marked *