Example extension module repository

[Weronika Ciecierska]

Hello everyone,

As you probably know, proof of concept of work on extension points and modules was published to openlmis-example repository recently.
Today I created new repository that contains example extension module - https://github.com/weronika-ciecierska/openlmis-example-extension
That means that it is no longer needed to download JAR file from my previous mail to test an example extension point from openlmis-example. Now it is possible to test it using this repository.
It is also possible to add your own extension points and extensions to see how everything works. There is detailed description in README on how to do it.

I think that our next step should be moving this repository to OpenLMIS account.
I encourage everyone to take a look at this and write your opinion. If you have any questions I will be happy to answer them.

Best regards,
Weronika

[Darius Jazayeri]

Hi Weronika,

Thanks for sharing this! I just had a chance to look at it, and I have some thoughts to share.

The first key point is that we need a good set of requirements for the extension mechanism, based on our best idea of the ways people will want to extend the system, and speculating about how these will translate to code.

For example the current implementation is built around an extension point being exactly one interface, and each implementation is exactly one classname, but I assume we'll have use cases where this doesn't work, e.g. if we want a "list of classes", like an extension point that lets you apply multiple validations to a requisition. Does the original research done by the VR team on this provide guidance on the kinds of extensibility needed?

We should also choose deliberately whether we want to make extension points easier for the developer, or easier for the implementer. (The current implementation does not make things easy for the implementer, which may be fine, as long as that's the choice.)

More specifics:

About the configuration file

• If we want to make things easier for the implementer to configure, we could have some sort of plain text configuration file rather than serialized beans as xml. (If that's not a priority, fine.)
  
• the extension point IDs should be strings that we intentionally come up with, not the fully-qualified classnames. (I.e. something like "OrderQuantityCalculationAlgorithm" instead of "org.openlmis.example.extensionpoint.OrderQuantity")
• also, the extension value should be a string (like a bean ID) rather than a fully-qualified classname (for example we might have a utility class that we instantiate into multiple beans, like a LuhnModNCheckDigitIdGenerator)

ExtensionManager

• I would expect a test for this class, and that's where I'd look to see how it behaves. (Yes, I know this is example code, but the idea is that we're bringing this into the real codebase, right? TDD!)
• getImplementation method:
• As a consumer I'd expect a method like getExtensionByPointId(String)
• javadoc should say whether this returns null
• getExtendedImplementation method need better behavior in case the specified extension doesn't exist
• I would put this class under the "extension" package (and move the points to extension.point)

Extension

• extensions should be able to be more than just a classname. e.g. we might want a list of classes

DefaultImplementation annotation:

• My initial reaction (assuming we want to make things easier for the implementer) is that we're better off with a "default config" file (which is then overridden by the extensions config file), and thus this annotation is not needed.

Usage

• I would expect that the main service is built and published to a maven repository, and this becomes a plain dependency specified in build.gradle (instead of each dev having to specify mainProjectPath as a local path). Dev shouldn't even strictly need to check out the service code to be able to write an extension.
• we should spike on having an annotation that can be used in place of @Autowired, and automatically sets a property via ExtensionManager

-Darius

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/139e74ee-684c-4632-a14f-6b253b0137b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Darius JazayeriPrincipal Architect - Global Health

Email

djaz...@thoughtworks.com

Telephone

+1 617 383 9369

[Weronika Ciecierska]

Hello Darius,

Thank you for your opinion, I really appreciate it!

Regarding an extension point being exactly one interface, this approach is taken from documentation on Confluence (https://openlmis.atlassian.net/wiki/pages/viewpage.action?pageId=51019809), as it states: 

"These extension points will most likely be Java interfaces, where the Service will run a strategy. There will be a default strategy implemented, but can be overridden. (...) This Extension Module will have a Java class that implements the extension point interface with a new strategy."

I cannot see any use cases in documentation, that would need an extension point to be a list of classes, but please do correct me if I am missing something.

About configuration file: 

Current xml file does not contain serialized beans. It contains name of extension point and name of extended implementation. Then this file is deserialized by ExtensionManager to list of Extension objects. If there is an extension defined for given extension point on this list, ExtensionManager looks for bean of given class (that contains extended implementation).

 

Of course current xml configuration file can be easily changed for plain text configuration.

I agree that it would make things easier for implementer. Also adding ID instead of full classnames is a good idea.

ExtensionManager:

 

You are right, I will add some tests and refactor ExtensionManager code.

DefaultImplementation:

Yes, I guess that will be easier for implementer. I'll change that.

Usage:

Yes, eventually we want the main service published to maven repository. Current solution is temporary, I forgot to mention it. I am glad you noticed it.

To sum up, for now I can change format of the configuration file (+ create default configuration file), add tests and refactor ExtensionManager. I think that adding IDs, publishing to maven repository and creating custom annotation to set property can be pulled to another tickets. Does that sound OK to you? I think that the main goal of this ticket, which is design of extensions mechanism, is done and now we can create other tickets to improve existing example.

Best regards,

Weronika

[Darius Jazayeri]

I don't know the intended scope of this ticket.

If it were up to me I would want to include making the keys and values of a properties file be plain strings (and bean IDs) rather than full classnames.

Josh, do we have any prior research on what the extensions will be, e.g. "most likely...Java interfaces" means that the test are what?

-Darius (by phone)

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2ff9096d-a360-4dbe-804c-af03b069f9e9%40googlegroups.com.

[Weronika Ciecierska]

Hi Darius,
I updated  openlmis-example repository with changes that you mentioned:

1) I changed the format of configuration file, now it lives in openlmis-example repository and contains default configuration. It looks like that:
             ExtensionPointId=ExtensionId

2) I removed @DefaultImplementation annotation (so, as mentioned above, there will be a file with default configuration for each service).

3) I changed full classnames to IDs - in case of extension point this is just plain string and in case of extension it is bean ID.

4) I refactored ExtensionManager code (now it contains only two methods due to the fact that we just take configuration from config file, no need for checking whether the implementation is default or not).

5) I added tests for ExtensionManager.

Best regards,
Weronika

[Paweł Gesek]

Hello,

is there any update on these extension point tickets? Can we move forward with transitioning them to done? They have been in review for a while now.

Regards,

Paweł

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8c5d59e8-27f0-4327-8985-4fc6568f7785%40googlegroups.com.

[Mary Jo Kochendorfer]

Folks,

In my opinion, I think we should finish up OLMIS-537<https://openlmis.atlassian.net/browse/OLMIS-537> and focus on the specific AMC example. Once we have more examples across services we can work on the design and plan for the larger solution OLMIS-783<https://openlmis.atlassian.net/browse/OLMIS-783>.

How does that sound?

From: openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Pawel Gesek
Sent: Wednesday, August 24, 2016 8:43 AM
To: openlm...@googlegroups.com
Subject: Re: [openlmis-dev] Example extension module repository


Hello,

is there any update on these extension point tickets? Can we move forward with transitioning them to done? They have been in review for a while now.

Regards,

Paweł

On 09.08.2016 17:36, Weronika Ciecierska wrote:
Hi Darius,
I updated openlmis-example repository with changes that you mentioned:

1) I changed the format of configuration file, now it lives in openlmis-example repository and contains default configuration. It looks like that:
ExtensionPointId=ExtensionId

2) I removed @DefaultImplementation annotation (so, as mentioned above, there will be a file with default configuration for each service).

3) I changed full classnames to IDs - in case of extension point this is just plain string and in case of extension it is bean ID.

4) I refactored ExtensionManager code (now it contains only two methods due to the fact that we just take configuration from config file, no need for checking whether the implementation is default or not).

5) I added tests for ExtensionManager.

Best regards,
Weronika


On Sunday, 7 August 2016 13:09:37 UTC+2, djazayer wrote:

I don't know the intended scope of this ticket.

If it were up to me I would want to include making the keys and values of a properties file be plain strings (and bean IDs) rather than full classnames.

Josh, do we have any prior research on what the extensions will be, e.g. "most likely...Java interfaces" means that the test are what?

-Darius (by phone)

* If we want to make things easier for the implementer to configure, we could have some sort of plain text configuration file rather than serialized beans as xml. (If that's not a priority, fine.)
* the extension point IDs should be strings that we intentionally come up with, not the fully-qualified classnames. (I.e. something like "OrderQuantityCalculationAlgorithm" instead of "org.openlmis.example.extensionpoint.OrderQuantity")
* also, the extension value should be a string (like a bean ID) rather than a fully-qualified classname (for example we might have a utility class that we instantiate into multiple beans, like a LuhnModNCheckDigitIdGenerator)
ExtensionManager

* I would expect a test for this class, and that's where I'd look to see how it behaves. (Yes, I know this is example code, but the idea is that we're bringing this into the real codebase, right? TDD!)
* getImplementation method:

* As a consumer I'd expect a method like getExtensionByPointId(String)
* javadoc should say whether this returns null

* getExtendedImplementation method need better behavior in case the specified extension doesn't exist
* I would put this class under the "extension" package (and move the points to extension.point)
Extension

* extensions should be able to be more than just a classname. e.g. we might want a list of classes
DefaultImplementation annotation:

* My initial reaction (assuming we want to make things easier for the implementer) is that we're better off with a "default config" file (which is then overridden by the extensions config file), and thus this annotation is not needed.
Usage

* I would expect that the main service is built and published to a maven repository, and this becomes a plain dependency specified in build.gradle (instead of each dev having to specify mainProjectPath as a local path). Dev shouldn't even strictly need to check out the service code to be able to write an extension.
* we should spike on having an annotation that can be used in place of @Autowired, and automatically sets a property via ExtensionManager
-Darius

On Thu, Jul 28, 2016 at 9:04 AM, Weronika Ciecierska <wciec...@soldevelo.com<mailto:wciec...@soldevelo.com>> wrote:
Hello everyone,

As you probably know, proof of concept of work on extension points and modules was published to openlmis-example repository recently.
Today I created new repository that contains example extension module - https://github.com/weronika-ciecierska/openlmis-example-extension
That means that it is no longer needed to download JAR file from my previous mail to test an example extension point from openlmis-example. Now it is possible to test it using this repository.
It is also possible to add your own extension points and extensions to see how everything works. There is detailed description in README on how to do it.

I think that our next step should be moving this repository to OpenLMIS account.
I encourage everyone to take a look at this and write your opinion. If you have any questions I will be happy to answer them.

Best regards,
Weronika
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com<mailto:openlmis-dev...@googlegroups.com>.
To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@googlegroups.com>.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/139e74ee-684c-4632-a14f-6b253b0137b1%40googlegroups.com<https://groups.google.com/d/msgid/openlmis-dev/139e74ee-684c-4632-a14f-6b253b0137b1%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.



--

Darius JazayeriPrincipal Architect - Global Health
Email

djaz...@thoughtworks.com<mailto:djaz...@thoughtworks.com>

Telephone
+1 617 383 9369

[ThoughtWorks]<http://www.thoughtworks.com/?utm_campaign=darius-jazayeri-signature&utm_medium=email&utm_source=thoughtworks-email-signature-generator>

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com<javascript:>.
To post to this group, send email to openlm...@googlegroups.com<javascript:>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2ff9096d-a360-4dbe-804c-af03b069f9e9%40googlegroups.com<https://groups.google.com/d/msgid/openlmis-dev/2ff9096d-a360-4dbe-804c-af03b069f9e9%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com<mailto:openlmis-dev...@googlegroups.com>.
To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8c5d59e8-27f0-4327-8985-4fc6568f7785%40googlegroups.com<https://groups.google.com/d/msgid/openlmis-dev/8c5d59e8-27f0-4327-8985-4fc6568f7785%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com<mailto:openlmis-dev...@googlegroups.com>.
To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/687758f4-cdad-d92f-e6e2-9b2f62013a64%40soldevelo.com<https://groups.google.com/d/msgid/openlmis-dev/687758f4-cdad-d92f-e6e2-9b2f62013a64%40soldevelo.com?utm_medium=email&utm_source=footer>.

[Mary Jo Kochendorfer]

After discussing with the team, we want to wait for Darius to get back and review.  Apologies for the confusion.

 

From: openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Mary Jo Kochendorfer
Sent: Wednesday, August 24, 2016 9:19 AM
To: Paweł Gesek <pge...@soldevelo.com>
Cc: OpenLMIS Dev (openlm...@googlegroups.com) <openlm...@googlegroups.com>
Subject: RE: [openlmis-dev] Example extension module repository

 

Folks,

 

In my opinion, I think we should finish up OLMIS-537 and focus on the specific AMC example.  Once we have more examples across services we can work on the design and plan for the larger solution OLMIS-783.

• If we want to make things easier for the implementer to configure, we could have some sort of plain text configuration file rather than serialized beans as xml. (If that's not a priority, fine.)

• the extension point IDs should be strings that we intentionally come up with, not the fully-qualified classnames. (I.e. something like "OrderQuantityCalculationAlgorithm" instead of "org.openlmis.example.extensionpoint.OrderQuantity")

• also, the extension value should be a string (like a bean ID) rather than a fully-qualified classname (for example we might have a utility class that we instantiate into multiple beans, like a LuhnModNCheckDigitIdGenerator)

ExtensionManager

• I would expect a test for this class, and that's where I'd look to see how it behaves. (Yes, I know this is example code, but the idea is that we're bringing this into the real codebase, right? TDD!)
• getImplementation method:

• As a consumer I'd expect a method like getExtensionByPointId(String)

• javadoc should say whether this returns null

• getExtendedImplementation method need better behavior in case the specified extension doesn't exist

• I would put this class under the "extension" package (and move the points to extension.point)

Extension

• extensions should be able to be more than just a classname. e.g. we might want a list of classes

DefaultImplementation annotation:

• My initial reaction (assuming we want to make things easier for the implementer) is that we're better off with a "default config" file (which is then overridden by the extensions config file), and thus this annotation is not needed.

Usage

• I would expect that the main service is built and published to a maven repository, and this becomes a plain dependency specified in build.gradle (instead of each dev having to specify mainProjectPath as a local path). Dev shouldn't even strictly need to check out the service code to be able to write an extension.

• we should spike on having an annotation that can be used in place of @Autowired, and automatically sets a property via ExtensionManager

-Darius

 

 

On Thu, Jul 28, 2016 at 9:04 AM, Weronika Ciecierska <wciec...@soldevelo.com> wrote:

Hello everyone,

As you probably know, proof of concept of work on extension points and modules was published to openlmis-example repository recently.
Today I created new repository that contains example extension module - https://github.com/weronika-ciecierska/openlmis-example-extension
That means that it is no longer needed to download JAR file from my previous mail to test an example extension point from openlmis-example. Now it is possible to test it using this repository.
It is also possible to add your own extension points and extensions to see how everything works. There is detailed description in README on how to do it.

I think that our next step should be moving this repository to OpenLMIS account.
I encourage everyone to take a look at this and write your opinion. If you have any questions I will be happy to answer them.

Best regards,
Weronika

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/139e74ee-684c-4632-a14f-6b253b0137b1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

 

Darius JazayeriPrincipal Architect - Global Health

Email

djaz...@thoughtworks.com

Telephone

+1 617 383 9369

--

You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2ff9096d-a360-4dbe-804c-af03b069f9e9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8c5d59e8-27f0-4327-8985-4fc6568f7785%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/687758f4-cdad-d92f-e6e2-9b2f62013a64%40soldevelo.com.

[Darius Jazayeri]

Back from vacation, and I made comments on the crucible review.

Summary: this seems broadly correct to me. The one change I'd make is that I think we should also support extension points that are configured with a list of beans, instead of just a single bean. This feels like it will be an important future use case.

-Darius

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8c5d59e8-27f0-4327-8985-4fc6568f7785%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/687758f4-cdad-d92f-e6e2-9b2f62013a64%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/DM5PR02MB23455FD5A4BE46EFF7B87DF98FEA0%40DM5PR02MB2345.namprd02.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.