Hi Gurkan! Basically it's a matter of style. Someone likes it others don't.
Imo there are a few 'real' problems which popped up: * you cannot use configuration dependent code in a static methods So basically we cannot easily switch between different SPI implementations (e.g. SimpleSecurityService vs ManagedSecurityService) in a static method. The only way was be always requesting the singleton over and over again - but that happened literally millions of times per second, which just didn't scale. Also since our singleton access is synchronized, this was just a bottleneck from a multithreading perspective. * it's not easily possible to mix static vs non-static calls. Once you have a static method, you cannot easily invoke another function from a non-static part. Thus -> singletonfinder as above. As a result we moved more and more code from public final static to instance members. * you cannot easily prevent someone from calling a public static method Methods like public static ClassUtil#invokeMethod allows _everyone_ to just invoke any container internal method as he likes. Since ClassUtil#invokeMethod used a doPrivileged, this would have been a big fat security issue. Thus rendering all the SecurityManager stuff useless. Btw: As a direct result of switching from static to non-static methods OWB-1.1.0 is now almost TRIPPLE as fast as owb-1.0 ;) (we outperform spring3 4 times and weld twice). If I would not have added the synchronized blocks in our CreationalContextImpl and a few other bugs, the improvement would have been even much higher. LieGrue, strub --- On Fri, 3/25/11, Gurkan Erdogdu <[email protected]> wrote: > From: Gurkan Erdogdu <[email protected]> > Subject: Re: Classpath Scanner proposal > To: [email protected] > Date: Friday, March 25, 2011, 7:27 AM > Why using the static methods are bad > thing? I think, one problem maybe using > static fields in static methods can be problem in > hierarchical class loaders. > Also if using static fields in class, not so much testable. > But from the > perspective of Utility Classi I see no problem. > > > > > ________________________________ > From: David Blevins <[email protected]> > To: [email protected] > Sent: Fri, March 25, 2011 7:54:28 AM > Subject: Re: Classpath Scanner proposal > > > On Mar 24, 2011, at 12:22 PM, Mark Struberg wrote: > > > I'd like to cook up something for a JSR, but need some > more time. > > David wrote xbean-finder and we could easily move this > to commons or extract it > >into a single jar in geronimo. > > It's already a single jar with just the > org.apache.xbean.finder code. But I'm > open to whatever. > > > But first things first: will start with the owb-1.1.0 > release now ;) > > Thanks for that btw! I really like all the recent > work. And I meant to say > "thanks" for cloning that static related jira. > Perfect use of that feature. > > On that static note, I was amazed at how much static code > we still had after > eliminating 95% of what showed up in the tests in the build > and then in the > standalone part of the TCK. I didn't get around to > the Web Profile part of the > TCK. But it seems either we need to write some more > tests or delete some more > code :) I'm sure it will be some of both. > > > -David > > > > --- On Thu, 3/24/11, Sven Linstaedt <[email protected]> > wrote: > > > >> From: Sven Linstaedt <[email protected]> > >> Subject: Re: Classpath Scanner proposal > >> To: "[email protected]" > <[email protected]> > >> Date: Thursday, March 24, 2011, 7:09 PM > >> Hi Mark, > >> > >> that sounds absolutely reasonable. I am just > interested in > >> the state of progress. Afaik xbean-finder is not a > project, > >> but rather a single class of some Apache project, > is not it? > >> So there are no plans any more to introduce this > kind of > >> service via JSR? > >> > >> Regards out of the train > >> > >> Sven > >> > >> -- sent by phone > >> > >> Am 21.03.2011 um 18:42 schrieb Mark Struberg > <[email protected]>: > >> > >>> Hi Sven! > >>> > >>> Yea, I'm aiming for something like that. The > major > >> benefit would be that we do not trash our > ClassLoader with > >> all the reflection stuff only needed for the > initial class > >> scanning. This is currently eating up lots of > PermGenSpace. > >> > >>> > >>> Btw, the reflections project is based on the > original > >> scannotation code from Bill Burke, so we aint that > far away > >> ;) > >>> We are also looking for probably moving it > over to > >> xbean-finder which David wrote for OpenEJB and is > now also > >> being used in geronimo and a few other apache > projects. But > >> we'll do that after 1.1.0 ;) > >>> > >>> txs and LieGrue, > >>> strub > >>> > >>> --- On Mon, 3/21/11, Sven Linstaedt <[email protected]> > >> wrote: > >>> > >>>> From: Sven Linstaedt <[email protected]> > >>>> Subject: Re: Classpath Scanner proposal > >>>> To: [email protected] > >>>> Date: Monday, March 21, 2011, 5:35 PM > >>>> Another interesting use case would > >>>> look like using some kind of > >>>> pre-generated scanning information created > during > >>>> build-time. > >>>> > >>>> Artifacts are in general considered final > after > >> creation, > >>>> so scans done at > >>>> runtime will return the same result. This > result > >> could be > >>>> generated during > >>>> build-time and inlined into the artifact > in a > >> serialized > >>>> form, which in turn > >>>> in used during runtime to further speed up > scan > >> jobs. [1] > >>>> is doing something > >>>> similar by providing a maven plugin. > >>>> > >>>> br, Sven > >>>> > >>>> > >>>> [1] http://code.google.com/p/reflections/ > >>>> > >>>> > >>>> 2011/2/27 Mark Struberg <[email protected]> > >>>> > >>>>> I think it should be enough if the > >> classscanner > >>>> implementation itself > >>>>> shades any such 3rd party jar into a > inner > >>>> dependency. > >>>>> My main focus currently is to design > the API > >> flexible > >>>> enough to allow all > >>>>> necessary use cases to work. > >>>>> > >>>>> LieGrue, > >>>>> strub > >>>>> > >>>>> --- On Sun, 2/27/11, Jan-Kees van > Andel <[email protected]> > >>>> wrote: > >>>>> > >>>>>> From: Jan-Kees van Andel <[email protected]> > >>>>>> Subject: Re: Classpath Scanner > proposal > >>>>>> To: [email protected], > >>>> [email protected] > >>>>>> Date: Sunday, February 27, 2011, > 1:35 PM > >>>>>> +1, although I think Jar hell is > a > >>>>>> real issue. Think about libraries > like > >>>>>> cglib, asm or commons-*** and the > pain > >> they > >>>> sometimes > >>>>>> cause. > >>>>>> > >>>>>> But we can easily work around it, > for > >> example by > >>>> packaging > >>>>>> all > >>>>>> using-frameworks as uber-jars and > >> renaming > >>>>>> the > "org.apache.commons.classscan" > >> packages to > >>>> something > >>>>>> like > >>>> > "org.apache.myfaces.org.apache.commons.classscan" > >>>>>> and > >>>> > >> > "org.apache.webbeans.org.apache.commons.classscan". > >>>>>> This way we prevent > >>>>>> any future versioning issues that > >> libraries like > >>>> cglib and > >>>>>> asm currently > >>>>>> have. > >>>>>> > >>>>>> Regards, > >>>>>> Jan-Kees > >>>>>> > >>>>>> > >>>>>> 2011/2/27 Mark Struberg <[email protected]> > >>>>>> > >>>>>>> Hi Jan-Kees! > >>>>>>> > >>>>>>> Txs for this info! > >>>>>>> > >>>>>>> Of course, I think the > downside of > >> getting > >>>> another > >>>>>> dependency to myfaces > >>>>>>> would highly be outvalued by > the > >> benefit > >>>> we'd gain > >>>>>> from it :) > >>>>>>> > >>>>>>> LieGrue, > >>>>>>> strub > >>>>>>> > >>>>>>> --- On Sun, 2/27/11, Jan-Kees > van > >> Andel > >>>> <[email protected]> > >>>>>> wrote: > >>>>>>> > >>>>>>>> From: Jan-Kees van Andel > <[email protected]> > >>>>>>>> Subject: Re: Classpath > Scanner > >>>> proposal > >>>>>>>> To: [email protected], > >>>>>> [email protected], > >>>>>> "Mark > >>>>>>> Struberg" <[email protected]> > >>>>>>>> Date: Sunday, February 27, > 2011, > >> 12:58 > >>>> PM > >>>>>>>> Hey Mark, > >>>>>>>> > >>>>>>>> About the JSR proposal. > I've > >> actually > >>>> been > >>>>>> talking to some > >>>>>>>> Oracle folks > >>>>>>>> about this idea some (like > 3?) > >> years > >>>> ago. They > >>>>>> didn't > >>>>>>>> really like it, since > >>>>>>>> the classpath is only a > VM > >>>> implementation > >>>>>> detail. > >>>>>>>> I proposed it, because > back then > >> there > >>>> were > >>>>>> already rumours > >>>>>>>> about module > >>>>>>>> systems and writing a > mechanism > >> that > >>>> relies on > >>>>>> the > >>>>>>>> classpath seemed like a > >>>>>>>> bad idea at that time. A > JSR (like > >> 277 > >>>> back then) > >>>>>> could > >>>>>>>> keep annotation > >>>>>>>> scanning in mind while > writing > >> the > >>>> spec. > >>>>>>>> I pinged them again (I > think it > >> was > >>>> last year) > >>>>>> and they > >>>>>>>> responded that they > >>>>>>>> would think about adding > an > >> annotation > >>>> scanner to > >>>>>> Jigsaw, > >>>>>>>> but a JSR was out > >>>>>>>> of the question. > >>>>>>>> > >>>>>>>> I think mentioning their > names > >> here is > >>>>>> inappropriate, but > >>>>>>>> they're influential people > in the > >>>> Java/JCP > >>>>>> world... > >>>>>>>> > >>>>>>>> This is not a reason to > not write > >> a > >>>> framework or > >>>>>> to not > >>>>>>>> submit a JSR, but I > >>>>>>>> thought I'd mention it... > >>>>>>>> > >>>>>>>> Ps. Maybe it's a good idea > to > >> "promote" > >>>> XBean > >>>>>> Finder and > >>>>>>>> use it in > >>>>>>>> MyFaces/OWB/etc...? > >>>>>>>> Ps2. IIRC, we implemented > our own > >>>> scanner for > >>>>>> MyFaces, for > >>>>>>>> the simple reason > >>>>>>>> that it removes an > additional > >>>> dependency. But, > >>>>>> OTOH, using > >>>>>>>> XBean Finder with > >>>>>>>> the Maven Shade Plugin > would also > >>>> work... > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Jan-Kees > >>>>>>>> > >>>>>>>> > >>>>>>>> 2011/2/27 Mark Struberg > <[email protected]> > >>>>>>>> > >>>>>>>>> Hi Ivan! > >>>>>>>>> > >>>>>>>>> Yes, I already > prepared for > >> the > >>>> addition of > >>>>>> a > >>>>>>>> xbean-finder based > >>>>>>>>> ClassScanner > implementation. > >> But > >>>> since I > >>>>>> didn't reach > >>>>>>>> David yesterday and I > >>>>>>>>> personally don't know > >> xbean-finder > >>>> well > >>>>>> enough, I just > >>>>>>>> started hacking on a > >>>>>>>>> scannotation based > one > >> (similar to > >>>> the one > >>>>>> we use in > >>>>>>>> OpenWebBeans). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> LieGrue, > >>>>>>>>> strub > >>>>>>>>> > >>>>>>>>> --- On Sun, 2/27/11, > Ivan > >> <[email protected]> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> From: Ivan <[email protected]> > >>>>>>>>>> Subject: Re: > Classpath > >>>> Scanner > >>>>>> proposal > >>>>>>>>>> To: [email protected], > >>>>>>>> [email protected] > >>>>>>>>>> Date: Sunday, > February > >> 27, > >>>> 2011, 12:01 > >>>>>> PM > >>>>>>>>>> Totally agree the > idea, > >> in > >>>> Geronimo, > >>>>>>>>>> it is definitely > an issue, > >> as > >>>> many > >>>>>>>>>> components need to > scan > >> the > >>>> target > >>>>>> application, > >>>>>>>> and we are > >>>>>>>>>> trying to improve > >>>>>>>>>> this, e,g. In the > >>>> xbean-finder, we use > >>>>>> some > >>>>>>>> filter to limit > >>>>>>>>>> the scanning > >>>>>>>>>> scope. Also, we > hope to > >> have > >>>> a > >>>>>> sharable > >>>>>>>> annotation scanning > >>>>>>>>>> tool, and open a > >>>>>>>>>> JIRA to track > this. > >>>>>>>>>> > >>>>>>>>>> [1] https://issues.apache.org/jira/browse/GERONIMO-5644 > >>>>>>>>>> [2] > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-bundleutils/src/main/java/org/apache/xbean/osgi/bundle/util/ResourceDiscoveryFilter.java > >>>>>a > >>>>>>>>>> > >>>>>>>>>> 2011/2/27 Mark > Struberg > >>>> <[email protected]> > >>>>>>>>>> > >>>>>>>>>>> hi folks! > >>>>>>>>>>> > >>>>>>>>>>> Since I'm > tired of > >>>> waiting for my > >>>>>> EE stack > >>>>>>>> to startup > >>>>>>>>>> because each and > >>>>>>>>>>> every library > >> implements > >>>> it's own > >>>>>> classpath > >>>>>>>> scanner > >>>>>>>>>> over and over > again, I > >>>>>>>>>>> thought about > >>>> introducing a > >>>>>> proposal for a > >>>>>>>> framework > >>>>>>>>>> which allows to > first > >>>>>>>>>>> register > 'ScanJobs' > >> and > >>>> then just > >>>>>> does all > >>>>>>>> the > >>>>>>>>>> necessary > classpath > >> scanning > >>>>>>>>>>> only once. > >>>>>>>>>>> > >>>>>>>>>>> If it turns > out to > >> work > >>>> well, then > >>>>>> I even > >>>>>>>> consider > >>>>>>>>>> this to get > submitted as > >>>>>>>>>>> JSR... > >>>>>>>>>>> > >>>>>>>>>>> But before > this point > >>>> gets > >>>>>> reached, a lot of > >>>>>>>> work is > >>>>>>>>>> still waiting. > >>>>>>>>>>> > >>>>>>>>>>> I hope a few > people > >> are > >>>> interested > >>>>>> in this > >>>>>>>> work and > >>>>>>>>>> help me > >>>>>>>>>>> > specifying/testing > >> the > >>>> needs! > >>>>>>>>>>> > >>>>>>>>>>> The api and a > bit of > >>>> docs can be > >>>>>> found at my > >>>>>>>> github > >>>>>>>>>> repo [1][2]. > >>>>>>>>>>> > >>>>>>>>>>> I'm currently > working > >>>> on > >>>>>> 'scannizing' > >>>>>>>> OpenWebBeans > >>>>>>>>>> (and later > MyFaces) as a > >>>>>>>>>>> real world > example. > >>>>>>>>>>> > >>>>>>>>>>> LieGrue, > >>>>>>>>>>> strub > >>>>>>>>>>> > >>>>>>>>>>> [1] https://github.com/struberg/Apache-commons-classscanner/ > >>>>>>>>>>> [2] > >>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>https://github.com/struberg/Apache-commons-classscanner/wiki/Apache-Commons-ClassScan-proposal > >>>>>l > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Ivan > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > > > > > > > > > >
