This sounds like an optimization, not something that requires spending a lot of time on.
Sent from my iPad > On Jun 3, 2014, at 12:15 AM, Gary Gregory <[email protected]> wrote: > > 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 > > > -------- Original message -------- > From: Matt Sicker > Date:06/03/2014 02:48 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Registering converters > > 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]>
