<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 12:41 PM Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:"trebuchet ms",sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 1:20 PM James Perkins <<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello All,<br><div>It's been longer than I'd want to really get into this, but now that I've got a start on it I'd like some feedback on the best way to deal with the pattern attribute. For the file it currently just uses a pattern like <font face="monospace, monospace">%h %l %u %t %r %s %b %{i,Referer} %{i,User-Agent}</font>. The problem is that doesn't really provide a key for the value. What I'm currently using is that same pattern and using the <font face="monospace, monospace">ExchangeAttributeBuilder.getName()</font> as the key. However if the value of <font face="monospace, monospace">getName()</font> changes at some point the data would end up with a different key. This approach doesn't seem ideal.</div><div><br></div><div>One option would be to switch to some kind of property format type of thing like:</div><div><br></div><div><font face="monospace, monospace">attributes={"remoteHost"="%h", "identityUsername"="%l"}</font></div><div><br></div><div>I'm not sure how user friendly that is though.</div><div><br></div><div>The other option would be to limit it to known exchange attributes, but that would require a change every time a new attribute is added to Undertow itself or we'd have to allow for some kind of custom attribute.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>Any opinions are welcome. Ideally we want something user friendly that's going to produce consistent keys as that would be part of the structured data contract.</div></div></div></blockquote><div><br></div><div style="font-family:"trebuchet ms",sans-serif">That pattern string also provides order. I suppose that's not as important with structured data though.</div></div></div></blockquote><div><br></div><div>Yeah order doesn't seem all that important, however I do my best to keep it in the order defined.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">Perhaps two alternative attributes, one that's a pattern String and then one that's complex like your example? The pattern string is documented with the values it supports and the names of the keys it will use for those values. (Those keys are set in the WF code, not pulled from <span style="font-family:monospace,monospace">ExchangeAttributeBuilder</span>.) If you want other key names or other values you have to use the complex attribute.</div></div></div></blockquote><div><br></div><div>My main concern there is just that there are currently 38 possible attribute builders in Undertow. I'm not sure if it's possible or not for a user to provide there own attributes, but if it is we'd have to find a way to allow for that as well. Having a limit may not necessarily be a bad thing though.</div><div><br></div><div>Another kind of oddity in the pattern I forgot to mention is it allows for constants which seems a bit weird to support in JSON. I was thinking of just add a "constants" array or some similar name.</div><div><br></div><div>I suppose another benefit to not using a pattern would be the parser wouldn't need to be copied from Undertow. However the <span style="font-family:monospace,monospace">ExchangeAttributeBuilder</span> does include a priority that wouldn't be respected.</div><div><br></div><div>For one more kludgy option we could just use the pattern and allow for something like "remoteUser=%u" where remoteUser would be a key override and we just have a defined set of default keys. If it's an unknown attribute to WildFly, then a key is required. Again a bit kludgy I guess.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div style="font-family:"trebuchet ms",sans-serif"><br></div><div style="font-family:"trebuchet ms",sans-serif">That's kind of kludgy but it makes the hopefully common case simple.</div><div style="font-family:"trebuchet ms",sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 8:10 AM James Perkins <<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello All,<div>I've created a proposal [1] for JSON access logging. Any feedback is welcome.</div><div><br></div><div>[1]: <a href="https://github.com/wildfly/wildfly-proposals/pull/176" target="_blank">https://github.com/wildfly/wildfly-proposals/pull/176</a><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_652905092474528963gmail-m_-330480333507350851gmail-m_1263520789966298393gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_652905092474528963gmail-m_-330480333507350851gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_652905092474528963gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div></div>