It looks to me like there is no other way. I'm not so bothered by a single text file that contains a list of classnames.
Why is it called wicket-component-initializers.txt ? I think the .txt extension is a bad idea. Since if I use eclipse to refactor classes - I usually get it to scan for fully quanified class names in .properties files (and .xml files) Would it be a bade idea to use the.properties extension ? Cameron > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:wicket-develop- > [EMAIL PROTECTED] On Behalf Of Johan Compagner > Sent: Friday, 12 August 2005 6:32 AM > To: [email protected] > Subject: Re: [Wicket-develop] feedback refactor and paging navigation > > I don't think there is a standard way. > We could test if the ClassLoader was a URLClassLoader (and then call > getUrls() on it) > But this doesn't have to be the case i think.. > > Also File.list() can't work on a classloader. Because you don't have a > dir (you could have but you could have anything) > > johanm > > Cameron Braid wrote: > > One other issue that comes to mind - where would the classpath list of > > jars/folders come from - since we can't rely on > > System.getProperty("java.class.path") from within servlet containers. > Is > > there a standard way to obtain the servlet context's classpath ? > > > > Cameron > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:wicket- > develop- > >> [EMAIL PROTECTED] On Behalf Of Gili > >> Sent: Friday, 12 August 2005 6:21 AM > >> To: [email protected] > >> Subject: Re: [Wicket-develop] feedback refactor and paging navigation > >> > >> > >> Good point. So going back to the original proposal, it sounds like > >> it'll be very fast if we use File.listFiles(FilenameFilter). > >> > >> Gili > >> > >> Cameron Braid wrote: > >> > >>> This would be worse - you would still need to scan all jars / folders > on > >>> > >> the > >> > >>> class path - then for any filename ending in .class - you would have > to > >>> > >> do > >> > >>> Class.forName() which will load the class - thereby loading EVERY > class > >>> > >> on > >> > >>> the classpath - not a good idea. > >>> > >>> Cameron > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] [mailto:wicket- > develop- > >>>> [EMAIL PROTECTED] On Behalf Of Gili > >>>> Sent: Friday, 12 August 2005 6:06 AM > >>>> To: [email protected] > >>>> Subject: Re: [Wicket-develop] feedback refactor and paging navigation > >>>> > >>>> > >>>> Taking one step further... would it be possible to drop the resource > >>>> file altogether and use pure reflection? Specifically, we search the > >>>> classpath for classes which implement interface IComponentInitializer > >>>> and if so we assume they contribute resources and invoke their > >>>> init(Application) method. > >>>> > >>>> Cameron is right that someone should profile this but I think this > >>>> is > >>>> ideal in that it is truely object oriented and zero-configuration -- > and > >>>> it is a one-time cost at startup. > >>>> > >>>> Gili > >>>> > >>>> Cameron Braid wrote: > >>>> > >>>> > >>>>> This would mean searching every sub-directory of every classpath > entry > >>>>> > >>>> (i.e. > >>>> > >>>> > >>>>> jars and folders) > >>>>> > >>>>> This will have a performance impact on the startup time of wicket - > how > >>>>> large - I dunno - someone cart to implement and profile ? > >>>>> > >>>>> If the performance hit is insignificant - I think this is the better > >>>>> > >> way > >> > >>>> to > >>>> > >>>> > >>>>> do it. Although - why not name the file ComponentClassName.wicket > :) > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Cameron. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: [EMAIL PROTECTED] [mailto:wicket- > >>>>>> > >> develop- > >> > >>>>>> [EMAIL PROTECTED] On Behalf Of Gili > >>>>>> Sent: Friday, 12 August 2005 5:10 AM > >>>>>> To: [email protected] > >>>>>> Subject: Re: [Wicket-develop] feedback refactor and paging > navigation > >>>>>> > >>>>>> > >>>>>> I'm +1 on Igor's proposal (.resource files) because amongst > other > >>>>>> things, it'll allow you to merge multiple JAR files into one easily > >>>>>> (should you wish to do such a thing) and ship a JAR with a whole > bunch > >>>>>> of related components as opposed to having to have a different JAR > for > >>>>>> each component. Right now you'd have to merge the META-INF/ > resource > >>>>>> file by hand. Also, obfuscators such as Proguard will automatically > do > >>>>>> this sort of JAR file merging and "shrinking" but will not be able > to > >>>>>> handle merging these META-INF files. Anyway... just food for > thought. > >>>>>> > >>>>>> Gili > >>>>>> > >>>>>> Jonathan Locke wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> sorry. didn't mean to jump on you, igor. i just wanted to make > sure > >>>>>>> > >>>> we > >>>> > >>>> > >>>>>>> didn't throw > >>>>>>> out something that's worth keeping... because there have been > some > >>>>>>> problems with > >>>>>>> resources, a lot of people have been clamoring to change the whole > >>>>>>> plan. since i've > >>>>>>> been the one behind the current plan and wrote most or all of the > >>>>>>> > >> code > >> > >>>>>>> for it, i have > >>>>>>> been trying to explain why i wrote it that way. it's not perfect > for > >>>>>>> sure (nothing ever is!), > >>>>>>> but i think the basic idea is not only not broken, but it's > actually > >>>>>>> pretty solid... especially > >>>>>>> with the fixes we did last night. > >>>>>>> > >>>>>>> i agree about the init thing, but i think that > >>>>>>> Classloader.getResources() would have to > >>>>>>> be enhanced to do this... not 100% sure though... if there's a > >>>>>>> reasonable way to do this, > >>>>>>> we should look into it. > >>>>>>> > >>>>>>> Igor Vaynberg wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Yes I see Jon. Thank you for a very long and detailed explanation > as > >>>>>>>> to why > >>>>>>>> my idea sucked. I still think there is some room for improvement > in > >>>>>>>> > >>>> the > >>>> > >>>> > >>>>>>>> current situation. Cant we do a saerch through avail packages > >>>>>>>> > >> looking > >> > >>>>>>>> for a > >>>>>>>> .resources file (im not sure how this would be done). > >>>>>>>> > >>>>>>>> It would be nice to simply have DatePicker.resources side by side > >>>>>>>> > >> with > >> > >>>>>>>> DatePicker.java. It would eliminate refactoring headaches at > least > >>>>>>>> > >> as > >> > >>>>>>>> far as > >>>>>>>> the package names go and it wouldn't be sitting in some separate > >>>>>>>> > >>>>>> folder. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> -Igor > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: [EMAIL PROTECTED] > >>>>>>>>> [mailto:[EMAIL PROTECTED] On Behalf Of > >>>>>>>>> Jonathan Locke > >>>>>>>>> Sent: Thursday, August 11, 2005 1:17 AM > >>>>>>>>> To: [email protected] > >>>>>>>>> Subject: Re: [Wicket-develop] feedback refactor and paging > >>>>>>>>> > >> navigation > >> > >>>>>>>>> actually it's not just that the service registration info has to > be > >>>>>>>>> put somewhere, it's that a client component that's using a > service > >>>>>>>>> > >> to > >> > >>>>>>>>> create a dynamic resource like, for example, some kind of panel > >>>>>>>>> > >> that > >> > >>>>>>>>> wants a dynamic button image created... > >>>>>>>>> /that component/ would have to be able to create its images > /when > >>>>>>>>> > >> the > >> > >>>>>>>>> app starts/ (because of clustering and server restarts). and > /only > >>>>>>>>> the panel component itself/ can or should know about this /and/ > it > >>>>>>>>> has to be done on startup. wicket's resource > >>>>>>>>> handling classes are already fully featured, object-oriented > >>>>>>>>> "services" (but less > >>>>>>>>> vague and more OO powerful) by virtue of the fact that they > >>>>>>>>> > >> implement > >> > >>>>>>>>> the IResourceListener interface and respond to requests for > >>>>>>>>> > >> resources > >> > >>>>>>>>> (ANY resource). so i just don't see any value at all in this > >>>>>>>>> > >> service > >> > >>>>>>>>> concept beyond what we've already got. in fact, i think it > would > >>>>>>>>> significantly /subtract/ from wicket's existing support for > dynamic > >>>>>>>>> resources (think "service" if you prefer)... and again, even if > we > >>>>>>>>> did change the world, it wouldn't solve the bootstrapping > problem > >>>>>>>>> > >> we > >> > >>>>>>>>> have for components. > >>>>>>>>> > >>>>>>>>> Johan Compagner wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>> how does a component with a dynamically generated image make > >>>>>>>>>>>> > >> that > >> > >>>>>>>>>>>> image available in your scheme? > >>>>>>>>>>>> the component has to register the image with the service, > >>>>>>>>>>>> > >> doesn't > >> > >>>>>>>>>>>> it? > >>>>>>>>>>>> > >>>>>>>>>>> The component doesn't need to register an image with a > service, > >>>>>>>>>>> > >> it > >> > >>>>>>>>>>> can register the service that creates the images. > >>>>>>>>>>> The images themselves can be created on the first request > >>>>>>>>>>> > >>>>>>>>>>> http://www..../app?service=mydynamicbuttons&button=A > >>>>>>>>>>> > >>>>>>>>>>> Whenever this url is hit wicket forwards the control to the > >>>>>>>>>>> registered mydynamicbuttons service (registered by whatever > >>>>>>>>>>> component) which creates the image A, caches it, and streams > it > >>>>>>>>>>> > >> to > >> > >>>>>>>>>>> response. Or precreate whatever you need when the service > >>>>>>>>>>> > >>>>>>>>> object is > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> created and registered with the application. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> And THIS last part is just the problem > >>>>>>>>>> > >>>>>>>>>> how does it register itself? When? > >>>>>>>>>> Where is it specified that a component does that? > >>>>>>>>>> I think in the end we have exactly the same thing... > >>>>>>>>>> you have a file like: > >>>>>>>>>> mydynamicbuttons=my.class.that.exposes.this.Service > >>>>>>>>>> > >>>>>>>>>> johan > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ------------------------------------------------------- > >>>>>>>>>> SF.Net email is Sponsored by the Better Software Conference & > EXPO > >>>>>>>>>> September 19-22, 2005 * San Francisco, CA * Development > Lifecycle > >>>>>>>>>> Practices Agile & Plan-Driven Development * Managing > >>>>>>>>>> > >>>>>>>>> Projects & Teams > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> * Testing & QA Security * Process Improvement & Measurement * > >>>>>>>>>> http://www.sqe.com/bsce5sf > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Wicket-develop mailing list > >>>>>>>>>> [email protected] > >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> ------------------------------------------------------- > >>>>>>>>> SF.Net email is Sponsored by the Better Software Conference & > EXPO > >>>>>>>>> September 19-22, 2005 * San Francisco, CA * Development > Lifecycle > >>>>>>>>> Practices Agile & Plan-Driven Development * Managing Projects & > >>>>>>>>> > >> Teams > >> > >>>>>>>>> * Testing & QA Security * Process Improvement & Measurement * > >>>>>>>>> http://www.sqe.com/bsce5sf > >>>>>>>>> _______________________________________________ > >>>>>>>>> Wicket-develop mailing list > >>>>>>>>> [email protected] > >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ------------------------------------------------------- > >>>>>>>> SF.Net email is Sponsored by the Better Software Conference & > EXPO > >>>>>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>>>>>>> Practices > >>>>>>>> Agile & Plan-Driven Development * Managing Projects & Teams * > >>>>>>>> > >> Testing > >> > >>>>>>>> & QA > >>>>>>>> Security * Process Improvement & Measurement * > >>>>>>>> > >>>>>> http://www.sqe.com/bsce5sf > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Wicket-develop mailing list > >>>>>>>> [email protected] > >>>>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> ------------------------------------------------------- > >>>>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO > >>>>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>>>>>> > >>>>>> Practices > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > >>>>>>> > >> & > >> > >>>>>> QA > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Security * Process Improvement & Measurement * > >>>>>>> > >>>>>> http://www.sqe.com/bsce5sf > >>>>>> > >>>>>> > >>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Wicket-develop mailing list > >>>>>>> [email protected] > >>>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>>>>>> > >>>>>>> > >>>>>> -- > >>>>>> http://www.desktopbeautifier.com/ > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------- > >>>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO > >>>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>>>>> Practices > >>>>>> Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > >>>>>> > >> & > >> > >>>> QA > >>>> > >>>> > >>>>>> Security * Process Improvement & Measurement * > >>>>>> > >>>> http://www.sqe.com/bsce5sf > >>>> > >>>> > >>>>>> _______________________________________________ > >>>>>> Wicket-develop mailing list > >>>>>> [email protected] > >>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------- > >>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO > >>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>>>> > >>>> Practices > >>>> > >>>> > >>>>> Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & > >>>>> > >>>> QA > >>>> > >>>> > >>>>> Security * Process Improvement & Measurement * > >>>>> > >>>> http://www.sqe.com/bsce5sf > >>>> > >>>> > >>>>> _______________________________________________ > >>>>> Wicket-develop mailing list > >>>>> [email protected] > >>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>>>> > >>>>> > >>>> -- > >>>> http://www.desktopbeautifier.com/ > >>>> > >>>> > >>>> ------------------------------------------------------- > >>>> SF.Net email is Sponsored by the Better Software Conference & EXPO > >>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>>> Practices > >>>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & > >>>> > >> QA > >> > >>>> Security * Process Improvement & Measurement * > >>>> > >> http://www.sqe.com/bsce5sf > >> > >>>> _______________________________________________ > >>>> Wicket-develop mailing list > >>>> [email protected] > >>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>>> > >>> > >>> > >>> ------------------------------------------------------- > >>> SF.Net email is Sponsored by the Better Software Conference & EXPO > >>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>> > >> Practices > >> > >>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & > >>> > >> QA > >> > >>> Security * Process Improvement & Measurement * > >>> > >> http://www.sqe.com/bsce5sf > >> > >>> _______________________________________________ > >>> Wicket-develop mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>> > >>> > >> -- > >> http://www.desktopbeautifier.com/ > >> > >> > >> ------------------------------------------------------- > >> SF.Net email is Sponsored by the Better Software Conference & EXPO > >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices > >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > >> Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > >> _______________________________________________ > >> Wicket-develop mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >> > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Wicket-develop mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
