--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to finatra-user...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to finatra-users+unsubscribe@googlegroups.com.
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.
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.