no i really dont like that then everywhere there code they need to do that, that is not an option. and they have to program themselfs agains the proxy api. I dont want that developers also have the learn/do that This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman <[EMAIL PROTECTED]> wrote: > Couldn't you also do: > > ProxyFactory pf = ...; > new SharedPropertyModel<Customer>(pf, customer); > > So, the client tells you what proxy factory implementation to use. > > On 3/8/08, James Carman <[EMAIL PROTECTED]> wrote: > > I see the JIRA, I'll go ahead and start the discussion on the dev list. > > > > > > On 3/8/08, James Carman <[EMAIL PROTECTED]> wrote: > > > On 3/8/08, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > > > for wicket this is a feature it really should have > > > > now it defeats the purpose i have to make a decission in wicket > which > > > > factory i use > > > > Then i can just as well directly compile against cglib. > > > > I cant make the api that way that the developer has to give that > factory to > > > > use. That would be completely horrible, > > > > > > > > > > > > > You could always implement your own brand of discovery for your > > > project (perhaps by using the service discovery feature built into > the > > > jdk). > > > > > > I like the idea of splitting it (and doing it the slf4j way rather > > > than the JCL way). I have actually suggested that we start an > > > exploratory branch of JCL to make it work more like slf4j (we've > been > > > talking about this since 2005). Anyway, if you file a JIRA issue, > > > I'll make sure we have a discussion with the other devs. For your > > > immediate purposes, commons-discovery is available also. > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
