logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <rgo...@apache.org>
Subject Re: Registering converters
Date Mon, 02 Jun 2014 23:33:50 GMT
BTW, since we have our own annotation processor it should be able to inspect plugins and when
it sees

@PluginAttribute("foo") @intDefault(5) String foo

It should be able to generate an error, which would essentially happen at compile time.

Sent from my iPad

> On Jun 2, 2014, at 4:08 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> My alarm bells went off when I saw we had a custom XML processing framework instead of
using JAXB. Then we piled on JSON and YAML but we still have all of this in custom code instead
of having Jackson define all configs in one common model. I understand this was all started
a long time ago and that the value of redoing it is not obvious to all. But taking issue with
one aspect of this stack now seems silly since it is the natural progression of such a framework.

> My first question would be to ask if it is really necessary to provide JSON and YAML
configurations... It's a bit late for that it seems since "it's all working".
> So now what? 
> I really like having domain types in my factory method signatures. I certainly would
not want to go back to having calls to conversion methods as boiler plate code in all these
> I'm not sure about the builder system but I do like the simplicity of the factory methods
because everything is defined in one place. The tweak needed now is a clean defaulting system.

> Gary
> Gary
> -------- Original message --------
> From: Remko Popma
> Date:06/02/2014 18:13 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Registering converters
> Does anyone else also have little alarm bells going off when seeing conversations like
> Before you'd accomplish this by simply coding the conversion in the factory method. Duplicate
code would be factored out to utility classes like Strings etc and it was all pretty straightforward.

> Now we have a framework to do the same, with TypeConverters and Registries and Builders
and Visitors. 
> The gain is that we get the conversion from String to int "for free". (Except that it
is not free, the complexity just moved somewhere else, and arguably became bigger.)
> Also, the builders allow us to name parameters when construction plugin objects in tests.

> The trade-off is that we have a whole lot more infrastructure. Not only is this more
code and more complex than what we had before, but as with any framework, it makes assumptions
on how things are done and in what order, and if you need to do something differently then
the framework just gets in your way...
> So now we need to keep modifying the framework to handle these cases. 
> I need to spend more time looking at the code, I'm basing a lot of this on the impression
I have after reviewing the commit emails, but I'm really starting to think that the gains
don't justify the drawbacks. 
> Sent from my iPhone
>> On 2014/06/03, at 6:06, Matt Sicker <boards@gmail.com> wrote:
>> We need to change the type converter registry to use the existing plugin registry/manager.
That would make this a lot easier! I'll work on that sometime this week. I've been meaning
to get to that (I have a TODO about it somewhere).
>>> On 2 June 2014 11:15, Gary Gregory <garydgregory@gmail.com> wrote:
>>> If I want to register my own type converters with
>>> org.apache.logging.log4j.core.config.plugins.util.TypeConverters.registerTypeConverter(Class<?>,
>>> when do I call it to make sure the configuration parsing picks up my additions
before it is to late?
>>> Gary
>>> -- 
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> -- 
>> Matt Sicker <boards@gmail.com>

View raw message