Re: [Hawkular-dev] Identification of WildFly in container in a Kube/Openshift env

Also, this feature of building a feed ID based on content within the app server is going to have drawbacks when you consider it won't work if the app server's deployments could ever change (add deployments, remove deployments, or even just patching existing deployments if the version string is part of the deployment filename [foobar-1.0.war -> foobar-2.0.war]) So this feature would be very restrictive in who should be using it and people should be very aware of it in case they turn that feature on when they shouldn't (because the consequences would be bad - the agent's feed ID would change underneath of it simply when a deployment changed).

That said, what might be possible (given the restrictions noted above), if we do want to support such a thing, we could allow a new pre-defined value for <storage-adapter>'s "feed-id" attribute. We already have one - "autogenerate". We could have something like "autogenerate-based-on-deployments". If the agent sees this, it could in theory add a DUP (DeploymentUnitProcessor) to the series of DUPs in the app server. This DUP of ours would pass through the deployments, but before it does it looks at the deployment name and keeps a running sha1 hash, building up the final hash when all deployments are passed through, put it somewhere the agent can access, and that will be the feed ID. (note if the "real" deployer that will handle that deployment actually rejects the deployment, we might have a problem because we'll have hashed on something that isn't really deployed - I don't know if our DUP can see when a deployment is rejected down the chain).