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 <[email protected]> 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 methods.
>
> 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 this?
>
> 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 <[email protected]> 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 <[email protected]> wrote:
>>> If I want to register my own type converters with
>>>
>>> org.apache.logging.log4j.core.config.plugins.util.TypeConverters.registerTypeConverter(Class<?>,
>>> TypeConverter<?>)
>>>
>>> when do I call it to make sure the configuration parsing picks up my
>>> additions before it is to late?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: [email protected] | [email protected]
>>> 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 <[email protected]>
