AttachmentsService ahead of REST API work (ATT-24)

Software Add-on Modules
, , ,
61

I am not getting the same error as you:

java.lang.ClassNotFoundException:
  org.openmrs.reporting.AbstractReportObject

Are you sure that you have pushed your latest changes?

The above would be solved by adding a missing test dependency.

62

I rechecked again. I have pushed all the changes. I ran a mvn clean install again and got the same set of errors. I will check my work again though.

63

I also checked again and stumbled on the same error as above.

To win some time during development you might want to build once the project without tests:

mvn clean install -Dmaven.test.skip=true

This will ensure that all necessary .class files are generated in /target.

Then you can run the one test you are working on like this:

mvn test -Dtest=AttachmentsServiceTest -pl api-2.0/
1 Like
64

@mksd Thank you very much for the two commands. They are quite useful. I ran both the commands.

mvn clean install -Dmaven.test.skip=true

the above command ran successfully.

The other produced the same set of errors. I modified the project structure settings to java 1.8 in intelj. I guess that could be the only difference between us. I will undo all the changes and keep you updated.

65

Btw when I specify something about Maven builds, I always mean that I have run them from the command line (never within my IDE.)

1 Like
66

@mksd I was using the terminal too. I will push the changes to the current PR so travis build will point me the real error.

67

@mksd I pushed the yesterday’s code to the PR , surprisingly all the tests have passed. I will complete the requested changes. thanks

68

@mksd I made the requested changes and pushed the code. But now the travis build fails with the error that I was mentioning yesterday. Here is the travis build failure

69

Okay
 that wasn’t easy.

First of all you can remove the bean for EncounterTransactionMapper in TestingApplicationContext.xml. I didn’t have the full view of the errors when I gave you this info.

Below is what I had to do step by step, to fix the current api-2.0 setup for Spring Tests. Note that all the changes are made to api-2.0/pom.xml, specific versions are upped through introducing overriding properties in that file (so here, not in the root pom.xml).

  1. Adding a test dependency on reportingcompatibility-api 2.0.1.
    This fixes the ClassNotFoundException: AbstractReportObject. Digging around the repos shows that this guy lives in the Reporting Compatibility module and that the first release to carry it is version 2.0.1.

  2. Adding a test dependency on emrapi-api-1.12.
    This clears the NoSuchBeanDefinitionException: No bean named 'drugMapper' is defined error. If you look at the EMR API module, you will see that DrugMapper is an interface and that you need at least the 1.12 subproject to get a 2.x friendly implementations of it to be found by Spring (see here).

  3. Upping EMR API to 1.16.
    It is the first version of the module that contains the above subproject and that does not carry anymore the snapshot dependency on the Ref App distro project.

  4. Adding a test dependency on serialization.xstream-api-2.0.
    This resolves the error: NoClassDefFoundError: org/hibernate/collection/PersistentCollection. Looking in the details of the stack trace for this class definition that is not found shows hints that it’s through the Serialization Xstream module that the problem arises.

  5. Upping serialization.xstreamVersionto 0.2.11.
    This is the first version of the module that brings the needed 2.0 subproject.

  6. Upping reportingVersion to 1.15.0 to make go away the references to PatientSetService. See TRUNK-4874.
    More specifically I was getting this error: ClassNotFoundException: PatientSetService$TimeModifier.

You should really try to go through all this on your side, to get a sense of how each of those problems is solved. They are quite typical of OpenMRS and its modules, so that might be useful again in other contexts.

1 Like
70

@mksd Thank you for all the tips. They mean a lot. I will go through all this on my side to get a better understanding that is required.

71

@mksd Could you please check weather changes in my pom is right.

72

On 1 you have used the wrong scope, it should be test (not provided).
You have missed points 2 and 4.

And all versions should be stated in the <properties/> section.

73

Thank you very much. I modified the file accordingly . But I am getting an error due to 4 th step.

Failure to find org.openmrs.module:serialization.xstream-api:jar:2.0

74

Point 4 was implemented incorrectly. What you want is a test dependency on the subproject api-2.0 of Serialization Xstream, see below.

Change

<dependency>
  <groupId>org.openmrs.module</groupId>
  <artifactId>serialization.xstream-api</artifactId>
  <version>2.0</version>
  <scope>test</scope>
</dependency>

to

<dependency>
  <groupId>org.openmrs.module</groupId>
  <artifactId>serialization.xstream-api-2.0</artifactId>
  <version>${serialization.xstreamVersion}</version>
  <scope>test</scope>
</dependency>
1 Like
75

@mksd Thanks. I submitted the required changes.

76

@mksd thanks for the reviews. I added non-complex obs to the same test method and submitted the changes.

77

AttachmentService provides attachments based on the underlying complex obs saved for a patient (at least this one new method that you are working on.)

However of course it is clear that multiple other obs (that are not complex) are also saved for any patient. So this is where the implementation that you have submitted needs to be enhanced. Because as of now it does not filter the obs that it queries for based on the fact that they are complex or not.

I think at this juncture we want getAttachments(..) to return only the obs that are coded with one of the concepts configured through the module itself see here.

1 Like
78

@mksd Thank you very much. Please correct me if I am wrong.

What I understand now is that AttachmentService returns attachments for all the obs without checking that they are complex or not. What I should be doing is that I should modify AtttachmentServiceImpl to check for obs which are complex and return attachments consisting of complex obs only.

I used isComplex() method in Obs to check for a complex Obs and added a test case to test non-complex Obs.

79

Note that I’m answering without having looked at the latest commit.

Having the service implementation checking that the returned obs are complex is necessary but not sufficient. At this point we also want the service method to fetch only the obs coded by the concepts configured through the module. See above on this thread for the pointer to the existing API that gives you the list of those configured concepts.

1 Like
80

@mksd Thanks. I checked out that method which returns the list of configured concepts. When I checked, the concepts of the Obs that I am searching for are different to those of configured concepts.Probably I might have used wrong methods to get the complexConcepts of the Obs.