@wyclif if you look in REST WS, using @Autowired is carefully avoided, for example all OpenMRS services are always gotten through a direct call to Context. This from EncounterResource would be an example among dozens.
@ningosi autowiring is only a best guess by Spring (unless you actually point to the exact bean with @Qualifier like here). A direct bean fetching can always be done through the context, for instance with ComplexObsSaver:
Yeah they seem to be good candidates for spring beans. I really don’t like doing Context.getService() because it is very difficult to unit test without having to make the test class application context aware (i.e. extending XContextSensitive classes) which in turn make the tests too slow due to long setup time!
Yes of course it would be better if REST resources could be Spring beans, but I would assume that if it isn’t the case then there must be a good reason. Does anyone recall why that is?
@mksd, I suppose it was because we did not have @OpenmrsProfile when they were originally written to load Spring beans conditionally based on OpenMRS version.
I wanted to make them Spring beans some time ago when I introduced @OpenmrsProfile, but it turned out to be a bigger task that I didn’t have enough time to complete it.
I’d be happy to see it happen though. It would improve module startup time (no need to scan through classpath for @Resource) and response time since Context.getService() is slow (especially in high concurrency scenario) due to synchronization. The ease of testing of Spring beans brought up by Willa would be another reason to do it.
Thanks @darius. I was just wondering if @raff faced an unexpected blocker while undertaking this.
The “Springification” of REST resources could perhaps become a story of the RESTWS project in JIRA? And turning each resource into a Spring bean could be a entry task for newcomers. It’s going to take a while, but who knows, maybe not.
@mksd does this apply for All Resource Beans in the web.rest.services module as well ? In other words can i use Context to pull a resource and utilise it in a Test Class ?
SimpleObject result = (SimpleObject) resource.doSearch(requestContext);
but i get a java.lang.ClassCastException: java.util.ArrayList cannot be cast to org.openmrs.module.webservices.rest.web.v1_0.resource.openmrs1_10.OrderResource1_10
@mksd is the "Springification " of The Resource Beans as @raff had imagined still on ?
I cannot also find the appropriate constant from the RestConstants.Class bean to act as String parameter to the ```
**OrderResource1_10 resource = Context.getRegisteredComponent("", OrderResource1_10.class);
** **** instance. Can i introduce it ? and which other classes would be affected ?
I don’t think it ever happened, it was just discussed here and didn’t move beyond that.
Therefore you won’t be able to fetch the bean as you did attempt to since no REST resources are registered as Spring beans (yet). However why exactly would you want to do that in a test? There’s a specific test framework for REST controllers, why can’t you use it? (Example on ConceptResourcehere).
@mksd Thanks alot for the response , i was not actually testing a Controller but rather OrderResource1_10Test because of a new method i introduced , but may be it was a wrong course.The method was to Mock an Http Request to the OrderResource1_10.doSearch() method
is it wrong that i skipped the controller ?
the method should return an Exception instead of a null result ,incase "status " only param is specified instead of “status” and "patient uuid " Parameters.
Thanks alot , had ignored that thinking the MainResourceControllerTest was for some select Resources.Let me try this out.Saved me a chunk of time Resource
And i checked ,it looks like ```
OrderController1_10Test