Github user dlaboss commented on a diff in the pull request:
https://github.com/apache/incubator-quarks/pull/86#discussion_r60499668
--- Diff: api/topology/src/main/java/quarks/topology/TStream.java ---
@@ -443,7 +443,7 @@ else if (WARNING.equals(lr.getLevel()))
Set<String> getTags();
/**
- * Add an alias for the stream.
+ * Set an alias for the stream.
* <p>
* The alias must be unique within the topology.
--- End diff --
I think it has to be that restrictive for things to remain sane. What you
say is true, but a TStream.alias() user has no idea or control over what
"types" may be registered by the runtime or others using an alias so they can't
predict or otherwise avoid collisions, right?
E.g., maybe some day poll() and map() register some mbean with the same
type, say, some logging mbean or such?
At a higher level I'm not really getting it wrt picking "type" or alias
names, or "ids" for that matter in order to generally avoid collisions since
the ControlService is documented as expecting to be used by application code as
well as the runtime. Seems like minimally more doc is needed in ControlService
for conventions for these. And right now the runtime uses unadorned values
like "job" and "periodic" for types - what's to prevent an ignorant user for
picking those to use for their own application specific controls?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
