Override module based on flag value

40 views
Skip to first unread message

Victor Tatai

unread,
Jul 13, 2017, 1:21:25 PM7/13/17
to finatra-users
Hello!

I have a Finatra service which needs to load different modules depending on a flag. I know I can use override modules to override the default modules, but the problem I'm seeing is that by the time the module is loaded the flag has not been parsed yet, resulting in:

java.lang.IllegalStateException: Flag environment read before parse.

Is there a way to insert override modules *after* the flags have been parsed?

Thanks,

Victor


Christopher Coco

unread,
Jul 13, 2017, 3:04:16 PM7/13/17
to Victor Tatai, finatra-users
Hi Victor,

As stated in the documentation (and code comments), you should not rely on override modules in production code (as they are for use in testing purposes only). To answer your question specifically, the lifecycle is such that you cannot rely on a flag to determine which modules to "load" in a server as modules are meant to be defined statically in a server definition.

If you are trying to load different modules based on the value of a flag, you should work to re-scope the problem such that the flag's value is all that needs to change (not the composition of modules) as flags are meant to be a way of parameterizing configuration (not necessarily logic).

I would highly suggest taking a look at the documentation for more details on modules and flags and the combination in Finatra.

Thanks!
-c

--
You received this message because you are subscribed to the Google Groups "finatra-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to finatra-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Victor Tatai

unread,
Jul 13, 2017, 4:23:40 PM7/13/17
to finatra-users, vta...@gmail.com
Hi Christopher,

Thanks for the prompt response - so perhaps let me explain my problem. We have a set of "services" (ie java interface implementations) which are based off external libraries, and these external libraries upon initialization need a lot of configuration, connect to AWS, etc. So in order to avoid that during local manual / automated testing we were thinking about just passing in a flag which could just "switch out" those implementations by simpler ones which we provide (for instance using disk instead of S3, etc).

We could do that by implementing a proxy for those interfaces, which doesn't seem ideal. The other approach would be just to use a system property instead of a flag. Or we just extend our server, and use that new server just for tests. Would you recommend any particular one?

Thanks again!

Victor
To unsubscribe from this group and stop receiving emails from it, send an email to finatra-user...@googlegroups.com.

Christopher Coco

unread,
Jul 13, 2017, 6:42:38 PM7/13/17
to Victor Tatai, finatra-users
Hi Victor,

Ideally, the need to set a lot of flag values would not bleed into how you write your production code in order to make testing simpler.

A common approach is to indeed extend your production server with a specific "test" server or servers that aggregate specific sets of modules for testing. In this manner these servers can be kept in a different code path from production code (e.g., src/test/scala), where their intended use can be made clear, (e.g. "LocalTestServer", "IntegrationSubsetTestServer"), you can better reason about your production server as it's module composition does not change based on the presence/value of a flag, and your testing is done in repeatable tests that effectively become a regression suite for your server.

Finatra's testing utilities try to help with this scenario, specifically FeatureTests (which should mostly obliviate the need for a "locally run" test server).

Thanks,
-c

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

Victor Tatai

unread,
Jul 13, 2017, 6:52:35 PM7/13/17
to Christopher Coco, finatra-users
Hi Christopher,

That makes sense - we will be looking at implementing it that way.

Thanks a lot!

V.

July 13, 2017 at 3:42 PM
Hi Victor,

Ideally, the need to set a lot of flag values would not bleed into how you write your production code in order to make testing simpler.

A common approach is to indeed extend your production server with a specific "test" server or servers that aggregate specific sets of modules for testing. In this manner these servers can be kept in a different code path from production code (e.g., src/test/scala), where their intended use can be made clear, (e.g. "LocalTestServer", "IntegrationSubsetTestServer"), you can better reason about your production server as it's module composition does not change based on the presence/value of a flag, and your testing is done in repeatable tests that effectively become a regression suite for your server.

Finatra's testing utilities try to help with this scenario, specifically FeatureTests (which should mostly obliviate the need for a "locally run" test server).

Thanks,
-c


July 13, 2017 at 1:23 PM
Hi Christopher,

Thanks for the prompt response - so perhaps let me explain my problem. We have a set of "services" (ie java interface implementations) which are based off external libraries, and these external libraries upon initialization need a lot of configuration, connect to AWS, etc. So in order to avoid that during local manual / automated testing we were thinking about just passing in a flag which could just "switch out" those implementations by simpler ones which we provide (for instance using disk instead of S3, etc).

We could do that by implementing a proxy for those interfaces, which doesn't seem ideal. The other approach would be just to use a system property instead of a flag. Or we just extend our server, and use that new server just for tests. Would you recommend any particular one?

Thanks again!

Victor



On Thursday, July 13, 2017 at 12:04:16 PM UTC-7, Christopher Coco wrote:
July 13, 2017 at 12:04 PM
Hi Victor,

As stated in the documentation (and code comments), you should not rely on override modules in production code (as they are for use in testing purposes only). To answer your question specifically, the lifecycle is such that you cannot rely on a flag to determine which modules to "load" in a server as modules are meant to be defined statically in a server definition.

If you are trying to load different modules based on the value of a flag, you should work to re-scope the problem such that the flag's value is all that needs to change (not the composition of modules) as flags are meant to be a way of parameterizing configuration (not necessarily logic).

I would highly suggest taking a look at the documentation for more details on modules and flags and the combination in Finatra.

Thanks!
-c


--
You received this message because you are subscribed to a topic in the Google Groups "finatra-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/finatra-users/Vk-uuA4dyfI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to finatra-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
July 13, 2017 at 10:21 AM
Hello!

I have a Finatra service which needs to load different modules depending on a flag. I know I can use override modules to override the default modules, but the problem I'm seeing is that by the time the module is loaded the flag has not been parsed yet, resulting in:

java.lang.IllegalStateException: Flag environment read before parse.

Is there a way to insert override modules *after* the flags have been parsed?

Thanks,

Victor


--
You received this message because you are subscribed to a topic in the Google Groups "finatra-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/finatra-users/Vk-uuA4dyfI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to finatra-user...@googlegroups.com.

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

--
Sent from Postbox
Reply all
Reply to author
Forward
0 new messages