Alright, sounds good then.
On 3 June 2014 12:05, Ralph Goers <[email protected]> wrote: > Yes. I would imagine that the code that would be calling pluginmanager > would be different and is only interested in the type converters. Likewise, > nothing else is interested in the type converters. > > Sent from my iPhone > > On Jun 3, 2014, at 9:52 AM, Matt Sicker <[email protected]> wrote: > > Alright, so it would make sense to use a different category name for the > type converters? > > > On 3 June 2014 11:43, Ralph Goers <[email protected]> wrote: > >> Use for what? Most main components that are part of the main >> configuration use core. The key to the category is what will be processing >> the plugin. >> >> Sent from my iPhone >> >> On Jun 3, 2014, at 9:12 AM, Matt Sicker <[email protected]> wrote: >> >> It's probably a simple change. In the meantime, should I use the Core >> category, or should I use a new one? >> >> >> On 3 June 2014 08:51, Ralph Goers <[email protected]> wrote: >> >>> 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 >>>>>>>>>>> <http://www.manning.com/bauer3/> >>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>> <http://www.manning.com/tahchiev/> >>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>>>>>>> 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 >>>>>>>>> <http://www.manning.com/bauer3/> >>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>>>>> 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 >>>>>> <http://www.manning.com/bauer3/> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>> 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 >>>> <http://www.manning.com/bauer3/> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>> Spring Batch in Action <http://www.manning.com/templier/> >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> >> > > > -- > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]>
