Hmm, I kind of think it is a very biased statement Matt - not blaming, let me explain:
> @Romain- I think heterogenous is a great goal— however, with complex hierarchal configurations, the “simplicity” of properties is lost in the structure. Default Log4j2 as properties is illegible by any UX/DX standard. As with features, having structured format (ie xml) for complex data is more manageable. On my window I just check how many properties/cfg (I merge both formats since they are close enough) files used by dev and ops and how many XML, no real war there, cfg always wins. That said you are right, features should be more compatible with config admin and have in its etc/cfg file the ability to define the equivalent of features.xml. Since features are backed by POJO it is not crazy to do IMHO. > The Developer Experience (DX) gap here is dev-on-laptop writing a simple REST service/camel route, etc and then deploying to karaf has a very different experience with logging. This is especially true for developers without a lot of experience and/or are new to karaf. You assume dev use xml with log4j2 but it is not that straight forward, properties are still used but json won a lot of traction too but the key point here is not the format but the dev env. If you mean that testing a camel route in an environment fully unrelated to the target has a different shape then you are right but it is true for everything, even deploying a war in tomcat or wildfly is different, you see my point? I'd really like to emphasis the fact that homogeneous is always the goal if you intend to go to prod - while you can do whatever you like with some more advanced/not default setup. The dev is a small part of a software and the cheapest one so if you want dev to spend 5 more minutes to convert a xml in proprties i'm tempted to say be it but if you force the full pipeline to use multiple tooling (xml and properties) to handle/generate/validate/check the configuration files then you also need to add the cost to manage these automotion dependencies and the related knowledge of the people working with it. It is a tree so a cost of 1 in dev area becomes a cost of 10 very quickly on the full chain...and when it does not hit the prod as expected and you don't notice you deployed something wrong it can be way more expensive. This is one of the reason log4j2 was not adopted before v2.4 which added back properties syntax. Hope my thinking and why I hope Karaf sticks to plain properties is clearer. Now there is one note about that: it is trivia to write a maven plugin dropping the log4j2.xml and moving it to a log4j2.properties at build time which should give you the best of the two world when dev are writing the prod files directly in the project itself so think are good and already cover that, it is just not a karaf native thing IMHO but more a build helper which would sit in log4j2 project (thinking out loud). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 28 déc. 2021 à 17:42, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > Hi > > You mean org.ops4j.pax.logging config PID right (so today > etc/org.ops4j.pax.logging.cfg). > > It’s already possible to refresh a log4j XML in org.ops4j.pax.logging. So > basically, etc/org.ops4j.pax.logging.cfg just contain the location of the > log4j.xml. > > I think it’s good enough. > > My point is that, if you proposal is to have etc/org.ops4j.pax.logging.xml > instead of etc/org.ops4j.pax.logging.cfg, that should be optional, and I > think it’s not a good idea. > I still prefer to have an indirection where etc/org.ops4j.pax.logging.cfg > points to log4j XML or JSON file. > > Regards > JB > > > Le 28 déc. 2021 à 17:32, Matt Pavlovich <mattr...@gmail.com> a écrit : > > > > @JB- To be clear, the request is for the log4j2 config file to be in xml > or json, not supporting json or xml log formats > > > > @Romain- I think heterogenous is a great goal— however, with complex > hierarchal configurations, the “simplicity” of properties is lost in the > structure. Default Log4j2 as properties is illegible by any UX/DX standard. > As with features, having structured format (ie xml) for complex data is > more manageable. > > > > The Developer Experience (DX) gap here is dev-on-laptop writing a simple > REST service/camel route, etc and then deploying to karaf has a very > different experience with logging. This is especially true for developers > without a lot of experience and/or are new to karaf. > > > > My suggestion is about trying to unify the log4j2 property file so dev > laptop to running karaf has the same default and therefore the same DX. > > > > -Matt > > > >> On Dec 28, 2021, at 1:55 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> > >> My 2cts would be that log4j2 or any configuration in karaf should be > >> homogeneous with other config files. Since OSGi is .cfg (enriched > >> properties) by design, I think it is better to stick to this or > something > >> very close *by default*. > >> Making the config formats heterogeneous will make your tooling > >> heterogeneous too or more complex at least which is not worth it in > almost > >> all cases. > >> > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <https://rmannibucau.metawerx.net/> | Old Blog > >> <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >> < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > >> > >> > >> Le mar. 28 déc. 2021 à 05:41, Jean-Baptiste Onofre <j...@nanthrax.net> a > >> écrit : > >> > >>> By the way, just a reminder: a good point about properties format in > >>> pax-logging-log4j2 service is that it doesn’t require extra dependency. > >>> Using xml/json format needs additional dependency/packages/bundles in > the > >>> Karaf distribution. > >>> Just a side note. > >>> > >>> Regards > >>> JB > >>> > >>>> Le 27 déc. 2021 à 19:33, Matt Pavlovich <mattr...@gmail.com> a écrit > : > >>>> > >>>> I’ve created a proposal JIRA KARAF-7307 ( > >>> https://issues.apache.org/jira/browse/KARAF-7307 < > >>> https://issues.apache.org/jira/browse/KARAF-7307>) to track any > specifics. > >>>> > >>>> As the subject mentions— I think it would be beneficial to users to > >>> change the default configuration for log4j2 to XML (or maybe JSON). > >>>> > >>>> Notes: > >>>> > >>>> 1. Documentation for the properties format is fragmented and > incomplete— > >>> especially for advanced features such as routing, etc > >>>> 2. XML format is the more natural format for log4j2 > >>>> 3. Allow for developers targeting karaf runtime to use the same > >>> log4j2.xml config file in their dev projects that is used in karaf > runtime > >>> (using a org.ops4j.pax.logging.cfg requires developers to add add’l > >>> configuration to their code projects) > >>>> > >>>> Thoughts? > >>>> > >>>> Thanks, > >>>> Matt > >>>> > >>>> > >>> > >>> > > > >
