how would you handle a situation where commons-proxy-jdk is not a drop in replacement for others because it cannot proxy concrete classes.
-igor On Mon, Jun 8, 2009 at 4:59 AM, James Carman<[email protected]> wrote: > Yeah, I agree. I would like to make ProxyFactory an interface and > split commons-proxy into 4 modules. > > commons-proxy-api - contains the api classes and perhaps some useful > superclasses for folks to use to write their own impls. > commons-proxy-jdk - jdk proxy implementation > commons-proxy-javassist - the javassist implementation > commons-proxy-cglib - the cglib implementation > > Then, at runtime, it'd look for something on the classpath to > determine which implementation to use. > > On Mon, Jun 8, 2009 at 7:33 AM, Johan Compagner<[email protected]> wrote: >> +1 ! >> >> On Mon, Jun 8, 2009 at 13:30, James Carman >> <[email protected]>wrote: >> >>> I've tried pushing through the runtime implementation resolution >>> (similar to slf4j), but nobody seems keen on it. At least, they >>> didn't answer my emails. So, perhaps I'll just refactor it myself and >>> put it out there and see what happens? >>> >>> On Mon, Jun 8, 2009 at 7:27 AM, Johan Compagner<[email protected]> >>> wrote: >>> > this we already kind of have. >>> > >>> > But it uses currently proxies. And is build on commons proxy that wants >>> us >>> > to hard code the proxie implementation >>> > that you should use, thats in my eyes a wrong implementations, the whole >>> > point of a wrapping class around a proxy >>> > is that i dont want to choose at compile time which one i want! >>> > >>> > But our property model can do what you are describing just fine. >>> > >>> > johan >>> > >>> > >>> > >>> > On Tue, May 19, 2009 at 10:09, Martijn Dashorst >>> > <[email protected]>wrote: >>> > >>> >> We've been discussing a typesafe property model before, and I'd like >>> >> to see where the current crop of such APIs and suggestions is. With >>> >> Wicket 1.4 imminent, and our migration to Java 5 this should be much >>> >> more easy to implement than before. >>> >> >>> >> One such library is >>> >> http://code.google.com/p/logicalpractice-collections/ where they make >>> >> selectors available on standard collections. >>> >> >>> >> Using their library one can write the following: >>> >> >>> >> smiths = select(from(people).getLastName(), >>> equalToIgnoringCase("smith")); >>> >> >>> >> >>> >> Putting my Wicket head on, I think something like: >>> >> >>> >> bind(new Label("foo")).to(person).getLastName()); >>> >> >>> >> or >>> >> >>> >> add(new Label("foo").bind(person).getLastName()); >>> >> >>> >> Would be nice. >>> >> >>> >> Not sure how this jives with our desire to remove the default model >>> >> slot. I think having a binding API might nicely coincide with removing >>> >> a default slot. The details of this are left as an exercise to the >>> >> reader ;-) >>> >> >>> >> Martijn >>> >> >>> > >>> >> >
