Extension point configuration

Hi all,
I’m currently trying to check whether newly added extension point configuration in the stock management service works. Unfortunately, I encountered issues during testing and I’m not sure if something is configured incorrectly in stock management or in my example extension.

Firstly, I had to build and use local fat jar of stock management because this service’s jar is not available on the remote repo. Then, when I was finally able to run a ref-distro with the extensions, I noticed that my extension bean is not initialized while starting ref-distro. I’ve tried the same for fulfillment extension point with the same result.

I’ve pushed my changes to dev branches of example-extensions and example-extension.

Does anyone know what can be the root cause?

Best,
Klaudia

@joshzamor I’ve just pushed my changes to the ref-distro dev branch and stock management dev branch.

The steps that we execute to run ref-distro with extension point:

  1. Build an image of stock management service with tag 5.1.2-SNAPSHOT
  2. Build a fat jar using the gradle fatJar task
  3. Copy this fat jar to the example-extension /libs directory
  4. Run docker builder for example-extension and copy created source jar to the /libs directory in example-extensions
  5. Run docker builder and build an image of example-extensions with tag 0.0.1-SNAPSHOT
  6. Run ref-distro

I have logging.level.org.springframework.beans.factory=DEBUG set in my settings.env to check which beans are initialized.

Thanks in advance for your help,
Klaudia

Hi @joshzamor, I hope you are well.

Did you manage to look at this? Do you happen to know what can be misconfigured here?

Best,
Klaudia

Hi @Klaudia_Palkowska and @joshzamor,

I have tried to run openlmis-example repository with the extension but the way we’re trying to do it for Stock Management. It also didn’t work until I added the path to the extensions package in @ComponentScan annotation in the Application class, like this:

   @ComponentScan(
    basePackages = {"org.openlmis.example*", "extensions.org.openlmis.example*"}
    )

However, doing similar thing in Stock Management service still doesn’t work. The fact that Stock Management’s Spring Boot version was recently upgraded to version 2 may matter here.

I upgraded the Spring Boot version to version 2 in the openlmis-example and checked it. It occurred that with upgraded Spring Boot it stopped working. In Spring Boot 2 I used the following annotation:

@SpringBootApplication(
    scanBasePackages = {"org.openlmis.example", "extensions.org.openlmis.example.extension"}
    )

For now I am not aware of what could be the reason for this, but maybe one of you will have an idea.

Best,
Paulina.

Just a thought - given that we know the extension point injection breaks on Spring Boot update, maybe we can identify which version exactly introduces this problem? E.g. Does it still work if we update Spring Boot from 1.3 to 1.5? How about 1.4? 2.0? 2.1? 2.2? Once we know the exact version that introduced the problem we can review the Spring Boot release notes for this version and perhaps find the solution there.

Another thing to consider is to check whether it still works if you keep the same @ComponentScan annotation (I think it still exists in Spring Boot 2 - why change it?)

Best,
Sebastian

Thank you Sebastian for your suggestions. Verifying the Spring Boot’s version which introduced this problem looks like an interesting way to continue our investigations.

According to the annotation, I think it doesn’t matter. I have also tried it with the same @ComponentScan annotation, but without success.

Best,
Paulina.

Are we blocked on this or is progress still being made?

Hi @ibewes ,

Following Sebastian’s suggestion, the Spring boot version was changed between versions 1.3 and 2.2, but example extension point behaved correctly, so this excludes the version of Spring Boot as the source of the problem.

Currently, we are still looking for a way to solve this issue, but we do not make much progress except to exclude what does not work.

Best,
Adrian.