It seems you have no tags attached to pages. To attach a tag simply click on the tags button at the bottom of any page.
smullins 1217533553|%e %b %Y, %H:%M %Z|agohover
Here is the list Greg and I are proposing:
These classes rely heavily on specific attributes that Orbitz uses.
dougbarth 1217534074|%e %b %Y, %H:%M %Z|agohover
Am I missing something? These classes seem pretty generic to me.
Matthew Kemp 1217537418|%e %b %Y, %H:%M %Z|agohover
Relying on attributes like vmid and hostname is not very generic. The mandatory use of these is being removed from the MonitoringEngine.
mokeefe 1217552935|%e %b %Y, %H:%M %Z|agohover
The "vmid" attribute is simply a name for the application, and "hostname" is the name of the machine that it is running on. How are those not generic? In the case where you are monitoring a distributed system, it is certainly always the case where you'd want to record those attributes in your events.
smullins 1217600771|%e %b %Y, %H:%M %Z|agohover
but should those be mandatory? I removed setting those attributes from the MonitoringEngine, so can we guarantee that everyone who uses erma would always use those attributes?
dougbarth 1217605785|%e %b %Y, %H:%M %Z|agohover
Assuming those two attributes are always there is fine IMO. However, what they are initialized to, should change.
hostname can be initialized correctly in the MonitoringEngine so we might as well keep it. vmid should be defaulted to something sensical like "not set" and we should drop the initialization from Orbitz specific environment properties. That code initialization code can live in your codebase.
I don't see any harm in keeping those attributes. The only case were they wouldn't be applicable would be in a non-distributed environment. But then, there's a lot of stuff in ERMA that could go away if we assumed we aren't distributed.
gopaczewski 1217618248|%e %b %Y, %H:%M %Z|agohover
OK, can we compromise here by removing just the EventPatternMonitorProcessor? Even if we were to refactor this I don't see anyone else getting much value out of a processor that renders a monitor to xml and sticks it in a separate attribute of the same monitor. Orbitz can then extend the XmlMonitorRenderer internally with EPM app specific stuff.
I think the general issue here isn't just whether code is "generic" enough, but whether we expect others to perceive value in something vs. it just having the appearance of cruft.
dougbarth 1217947935|%e %b %Y, %H:%M %Z|agohover
I can buy that argument. Obviously, this MP would be a lot more useful if we had an open source EPM system. Since we don't, we might as well remove it.
smullins 1218038066|%e %b %Y, %H:%M %Z|agohover
Ok, I'm going to remove the EventPatternMonitorProcessor only. I'll refactor the xmlMonitorRenderer to not have hardcoded attribute names so its more flexible. Once that's done, I think we're good to release the first binary.
