Exactly, an enum would help know what is legal. It could just be used for documentation for all I know. A set of constants would be better if we need something extensible.
Gary <div>-------- Original message --------</div><div>From: Matt Sicker <[email protected]> </div><div>Date:06/03/2014 02:48 (GMT-05:00) </div><div>To: Log4J Developers List <[email protected]> </div><div>Subject: Re: Registering converters </div><div> </div>Well, what categories are we supposed to use? Is there a set list, or can we just use whatever? It's not that clear other than looking at current usage (most things are in the Core category). On 3 June 2014 01:31, Ralph Goers <[email protected]> wrote: A new annotation to do what? To specify which category the plugin belongs to? What is wrong with the way it is now? What problem are we trying to solve? Sent from my iPad On Jun 2, 2014, at 8:30 PM, Gary Gregory <[email protected]> wrote: A new annotation seems simpler to me but that might be contradictory to what Ralph had in mind when he created the framework. Hopefully, let us know ;-) Gary On Mon, Jun 2, 2014 at 11:23 PM, Matt Sicker <[email protected]> wrote: Yeah, but now I'm wondering which approach to take. Re-use @Plugin, add another annotation, or refactor how categories are handled in @Plugin. Could be a mix of 1 and 3, with 3 coming later. On 2 June 2014 22:00, Gary Gregory <[email protected]> wrote: Welcome back Matt then. Are you putting yourself on deck to redo the type converters a la Log4j? Gary On Mon, Jun 2, 2014 at 10:55 PM, Matt Sicker <[email protected]> wrote: Scratch that idea. It's using ASM. That's definitely not worth it. On 2 June 2014 21:51, Matt Sicker <[email protected]> wrote: I'm looking at how Spring does it, and for pre-1.8 code, it's quite the rabbit hole. I'll report back when I find my way out. On 2 June 2014 21:39, Gary Gregory <[email protected]> wrote: On Mon, Jun 2, 2014 at 10:35 PM, Matt Sicker <[email protected]> wrote: Not for the factory/builder stuff! Unless we cached more data about plugins like that. Ah, I made an incorrect assumption then. Let's keep it simple and require the name then? We can always enhance later. Gary On 2 June 2014 21:32, Gary Gregory <[email protected]> wrote: It would only happen at compile time... so who cares? Gary On Mon, Jun 2, 2014 at 10:29 PM, Matt Sicker <[email protected]> wrote: In regards to the parameter reflection stuff, I can't find anything in 1.6 other than using Introspector.getBeanInfo(Class<?>).getMethodDescriptors() and MethodDescriptor.getParameterDescriptors(). From what I recall, Introspector is rather slow for this sort of situation and is mostly used in GUIs that deal with JavaBeans. On 2 June 2014 21:20, Matt Sicker <[email protected]> wrote: On 2 June 2014 21:14, Gary Gregory <[email protected]> wrote: Well, my point is that you'd just use an annotation. What the annotation is, I do not know. I'm not crazy about the category idea in general because I am one typo away on a late night from getting stuck. If the code does not compile, that's easier to fix. I agree on that. It's terribly frustrating to deal with runtime problems that should have been detectable at compile time. Perhaps instead of categories we had a meta-annotation that describes a plugin category, and then plugins can use a category annotation instead of the parameter? We could really use annotations like this to make things more typed with less typing. -- Matt Sicker <[email protected]> -- Matt Sicker <[email protected]> -- 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]> -- 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]> -- Matt Sicker <[email protected]> -- 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]> -- 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]>
