On Thu, Apr 18, 2019 at 1:20 PM James Perkins <jperkins(a)redhat.com> wrote:
Hello All,
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 %h
%l %u %t %r %s %b %{i,Referer} %{i,User-Agent}. 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 ExchangeAttributeBuilder.getName() as the
key. However if the value of getName() changes at some point the data
would end up with a different key. This approach doesn't seem ideal.
One option would be to switch to some kind of property format type of
thing like:
attributes={"remoteHost"="%h",
"identityUsername"="%l"}
I'm not sure how user friendly that is though.
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.
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.
That pattern string also provides order. I suppose that's not as important
with structured data though.
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
ExchangeAttributeBuilder.) If you want other key names or other values you
have to use the complex attribute.
That's kind of kludgy but it makes the hopefully common case simple.
On Mon, Feb 18, 2019 at 8:10 AM James Perkins
<jperkins(a)redhat.com> wrote:
> Hello All,
> I've created a proposal [1] for JSON access logging. Any feedback is
> welcome.
>
> [1]:
https://github.com/wildfly/wildfly-proposals/pull/176
>
> --
> James R. Perkins
> JBoss by Red Hat
>
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat