I would say first we should not expect people to be happy to have install a _second_
subsystem extension to just to support Hawkular (having a separate feature pack,
installer, separate <subsystem> in standalone.xml, etc. etc). But we could add more
extension *services* or DUPs (see below) to the Hawkular WildFly Agent subsystem itself
and it just comes with the agent with no additional installation or configs necessary.
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).
We already do this kind of thing in RHQ. We add a DUP [1] and in the DUP (in RHQ anyway)
we look at the name of the deployment and if it isn't rhq.war, the deployment is
rejected [2]. For Hawkular, we just let it pass through and deploy but we'd create the
hash based on the name.
[1]
https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/...
[2]
https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/...
----- Original Message -----
On 27.07.2016 19:06, Juraci Paixão Kröhling wrote:
> On 27.07.2016 18:51, John Mazzitelli wrote:
>>> - feed-id: sha1sum(sha1sum(foobar.war) + sha1sum(foobar-ds.xml))
>>> result: a4f36be49f641967e51e2707c1fe6d0a29c2f682
>>
>> Calculating the feed ID based on discovered resources is going to be very
>> difficult if not impossible with the current implementation - the agent
>> needs the feed ID upfront during startup before it even runs discovery
>> (i.e. before it even knows about any resources - let along child
>> resources like deployments) - it requires the feed ID internally to start
>> many components, it can't talk to hawkular-inventory without it, and it
>> needs the feed ID to connect to the hawkular cmdgw server.
>
> I considered this, but I thought it wouldn't be a problem to implement a
> separate Wildfly extension that would calculate this during the boot and
> put the resulting value in a system property for later use by the agent
> itself. Would that work?
By the way: I don't think this extension needs to wait for the deployers
either: all it would need to do is to get a VirtualJarInputStream for
each of the deployments, and calculate the sha1sum based on that.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev