Skip to content
This repository has been archived by the owner on Jun 19, 2024. It is now read-only.

Allow deep configuration for enrichers #1375

Open
rhuss opened this issue Sep 11, 2018 · 3 comments
Open

Allow deep configuration for enrichers #1375

rhuss opened this issue Sep 11, 2018 · 3 comments
Labels
status/never-stale Pin this issue to get never marked as stale by stale-bot target/4.0 PR for targeted to 4.0.x
Milestone

Comments

@rhuss
Copy link
Contributor

rhuss commented Sep 11, 2018

Description

Currently only flat configuration is supported by default (i.e. a simple key-value map). However, there are already enrichers (e.g. the VertxHealthCheckEnricher) which examines the plugin configuration on is own by parsing the XML. However those enrichers are tightly coupled to maven and can't easily reused outside a Maven context.

This should not be required, but the enrichers should support nested configurations by default, which actually should be a plain map of maps with plain string values (could also contain lists).

@rhuss rhuss added the target/4.0 PR for targeted to 4.0.x label Sep 11, 2018
@rohanKanojia rohanKanojia added this to the Sprint 155 milestone Sep 12, 2018
@lordofthejars lordofthejars self-assigned this Sep 19, 2018
@lordofthejars
Copy link
Contributor

What I can see is that in VertxHealthCheckEnricher we need two things from Maven configuration,
the first one is the proeprties, and the second one the configuration.

So the problem is that VertxHealthCheckEnricher and any class that needs these parameters it uses EnricherContext
https://github.com/fabric8io/fabric8-maven-plugin/blob/master/enricher/api/src/main/java/io/fabric8/maven/enricher/api/EnricherContext.java.

The problem is that these parameters are not simply exposed by EnricherContext in a JDK types, but as Maven types, so the ones who needs them needs to deal with these Maven objects as well.
See for example:
https://github.com/fabric8io/fabric8-maven-plugin/blob/master/enricher/fabric8/src/main/java/io/fabric8/maven/enricher/fabric8/VertxHealthCheckEnricher.java#L318

So my idea would be that all these Maven types (Xpp3Dom) are just valid inside EnricherContext and we can create some methods in EnricherContext so any caller just calls them and receives JDK types.
In this way enrichers will have an easy way to query configuration information without have to deal with Maven types or parsing XMLs.

What do you think about this approach? Or you have other thing in mind?

lordofthejars added a commit to lordofthejars/fabric8-maven-plugin that referenced this issue Oct 10, 2018
@lordofthejars lordofthejars removed their assignment Nov 6, 2018
@lordofthejars
Copy link
Contributor

@rhuss You reopened this issue to improve how we can pass the custom configuration to an enricher. We didn't talk about but what could be this improvement. Do you have for example something in mind like an xpath for objects, so you say I want to attribute as string /a/b/c and the method takes the map and navigates through it, or you are thinking in using for example reflection to fill up a POJO?

lordofthejars added a commit to lordofthejars/fabric8-maven-plugin that referenced this issue Jan 17, 2019
@stale
Copy link

stale bot commented Feb 13, 2019

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

@stale stale bot added the status/stale Issue/PR considered to be stale label Feb 13, 2019
@stale stale bot closed this as completed Feb 20, 2019
@rohanKanojia rohanKanojia reopened this Feb 20, 2019
@stale stale bot removed the status/stale Issue/PR considered to be stale label Feb 20, 2019
@rohanKanojia rohanKanojia added the status/never-stale Pin this issue to get never marked as stale by stale-bot label Feb 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status/never-stale Pin this issue to get never marked as stale by stale-bot target/4.0 PR for targeted to 4.0.x
Projects
None yet
Development

No branches or pull requests

3 participants