-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal to add ExtraProps to the configuration #1990
Comments
Duplicate of #738 |
Hi Miňo!
No, thanks! See #1843❗ |
Hi @raman-m, thanks for linking. M. |
Reopen for official closing |
* feat(configuration): adding route metadata * feat(configuration): update docs * feat(configuration): replace Dictionary<> by IDictionary<>, code cleaning * feat(configuration): replace Dictionary<> by IDictionary<> * feat(configuration): replace Dictionary<> by IDictionary<> * feat(configuration): update the data type of FileDynamicRoute Metadata * formatting * feat(configuration): fix integration tests * feat !1843 add extension methods for DownstreamRoute to get metadata * feat !1843 add extension methods for DownstreamRoute * feat !1843 update docs * feat !1843 update docs * feat !1843 cleanup split string logic * SA1505: An opening brace should not be followed by a blank line * IDE1006: Naming rule violation: These words must begin with upper case characters: should_xxx * Fix compile errors after rebasing * Fix unit tests + AAA pattern * First Version, providing a generic extension method GetMetadata<T> with global configuration * Adding ConvertToNumericType method to be able to use the NumberStyles enum * adding first acceptance tests * The tests are now passing again... * adding latest test cases. That should be enough (includes global configuration changes too) * Update metadata.rst * adding the xml docs for IMetadataCreator and MetadataCreator * renaming MetadataCreator to DefaultMetadataCreator * number tests for .net 6 too * Moving Metadata specific downstream route extensions to the Metadata folder * cleanup * applying some of the requested changes * Final code review by @raman-m * Add traits * Fix docs build error --------- Co-authored-by: Raman Maksimchuk <[email protected]> Co-authored-by: Guillaume Gnaegi <[email protected]>
Closed by #1843 |
* feat(configuration): adding route metadata * feat(configuration): update docs * feat(configuration): replace Dictionary<> by IDictionary<>, code cleaning * feat(configuration): replace Dictionary<> by IDictionary<> * feat(configuration): replace Dictionary<> by IDictionary<> * feat(configuration): update the data type of FileDynamicRoute Metadata * formatting * feat(configuration): fix integration tests * feat !1843 add extension methods for DownstreamRoute to get metadata * feat !1843 add extension methods for DownstreamRoute * feat !1843 update docs * feat !1843 update docs * feat !1843 cleanup split string logic * SA1505: An opening brace should not be followed by a blank line * IDE1006: Naming rule violation: These words must begin with upper case characters: should_xxx * Fix compile errors after rebasing * Fix unit tests + AAA pattern * First Version, providing a generic extension method GetMetadata<T> with global configuration * Adding ConvertToNumericType method to be able to use the NumberStyles enum * adding first acceptance tests * The tests are now passing again... * adding latest test cases. That should be enough (includes global configuration changes too) * Update metadata.rst * adding the xml docs for IMetadataCreator and MetadataCreator * renaming MetadataCreator to DefaultMetadataCreator * number tests for .net 6 too * Moving Metadata specific downstream route extensions to the Metadata folder * cleanup * applying some of the requested changes * Final code review by @raman-m * Add traits * Fix docs build error --------- Co-authored-by: Raman Maksimchuk <[email protected]> Co-authored-by: Guillaume Gnaegi <[email protected]>
If the need arises on the Ocelot usage side for an extension, we usually have to work with some custom settings in the Ocelot downstream route configuration as well.
The current options are that we put the custom settings into a custom setup and use the downstream key as a reference to it, or we can add them to the original JSON setup and read them ourselves (duplicate read).
From an extensibility point of view, it would be nice if we could add additional properties that the programmer could then read.
Proposal
Whole usage
Usage in middleware:
I can prepare PR for this change. I just want to check if this is a change that fits the direction of the project.
Thank you in advance for your reply.
The text was updated successfully, but these errors were encountered: